How long does it take to resume a VM?

I don’t think it is that serious of an issue:

- The API is likely to be simple (JSON in and out, or something similar). Those devs already know they domain well.

- The Rust compiler enforces only valid programs, so you won’t get runtime errors for things you would in dynamic languages.

- This leaves just getting the logic right, which the developers know how to do in general, and Rust is a c-like language so it’s familiar.

How do you manage changing state overtime? Do you re-render the whole template?

Can templates be nested?

You use standard DOM operations to update state, like innerText and classList.add, defined inside the JS class that orchestrates the component.

Nesting works using the same concept. A parent template either picks one of its child nodes using this.fragment.querySelector or using document.createElement to mount a child template to. You then use this.addChild to opt into garbage collection.

I think general programming languages are better for general programs than SQL.

Specifically they have: Type systems, compilers, debuggers, text editors, package managers, C FFI etc.

But I agree that having the data and the program in the same process has benefits.

Writing programs in SQL is one way.

Another way is to move your data to your general program with SQLite.

I like using SQL for ACID, and queries as a first filter to get the data into my program where I may do further processing with the general language.

Another is MS SQL Server, which lets you run .NET on the database server :D "you can author stored procedures, triggers, user-defined functions, user-defined types, and user-defined aggregates in managed code"

I have had nothing but bad experiences trying to run .NET in SSIS packages -- is there another way?

I've never had the pleasure(ha) of using SSIS, but this is the stuff that I was talking about: https://learn.microsoft.com/en-us/dotnet/framework/data/adon...

> Type systems

SQL has types

> compilers

For what specifically do you need a compiler?

> debuggers

Some tasks - like the concurrency SQL enables - are just very difficult to debug with debuggers. It would be the same with any other language. What SQL does here though is to allow you to focus on the logic, not the actual concurrency,

> text editors, package managers

I feel like these two are just for filling up the space.

> C FFI

Many SQL engines have UDFs

> Type systems

Sure SQL has types, but they are checked at runtime, not compile time. Also you cannot define function input and return arguments with types that are checked before you run the program.

> compilers

If you want efficient and/or portable code. They will check your code for type errors before you run them. They give you coding assistance in your editor.

> debuggers

Being able to break a program and see its state and function stack is useful. The quality of the tools for real languages are much better than SQL.

I agree that databases do concurrency better than most languages with their transactions (I mentioned I would use the db for ACID).

> text editors, package managers.

Editor support of real languages is much better than SQL.

Package managers enable code re-use.

> C FFI

Take for example Python. A huge amount of the value comes from re-using C libraries that are wrapped with a nice Python API.

You might be able to do this in SQL, but you'll have to wrap the C library yourself as there is no package manager, and no one else is doing the same thing.

> > text editors, package managers.

> Editor support of real languages is much better than SQL.

So text editors suck at supporting SQL... How is that SQL’s fault?!? Go complain to the text editor authors.

> Package managers enable code re-use.

Yup. Build one for SQL, then you can re-use SQL code. Just like someone had to build one for every other language. What does this prove about SQL being inferior to other languages? A: Nothing at all.

> What does this prove about SQL being inferior to other languages

My point is that I think it is inferior for general application/business logic programs. For queries that filter large datasets to small result sets, SQL is probably better as it has the built in indexes and query planner (plus ACID).

I am pointing out that the current environment (better text editors and package managers) favours general languages, so they are a better current choice (to use in combination with SQL) over just writing everything, including application logic, in SQL.

> I think general programming languages are better for general programs than SQL. Specifically they have: Type systems, compilers, debuggers, text editors, package managers, C FFI etc.

Non sequitur. SQL is typed; SQL can be edited in any text editor; there are lots of SQL IDEs and, arguably, debuggers and package managers. Sure, the package managers are specific to each RDBMS, but so what? Npm is no use in COBOL either. And sure, the “debuggers”, to the extent they can be said to exist, are radically different from those of “conventional” – of other – programming languages. But again, so what? A Smalltalk debugger is no use to fix the output from Intel’s latest C compiler either, or vice versa.

IOW: There is no such “SQL vs programming languages” dichotomy. SQL is just another programming language, with its own strengths and weaknesses, just like all the rest of them. “The rest” are not distinguished from SQL by somehow magically all having the attributes you claim for them: Some have them, some don't; some have this but not that, some others, the other way around. Someone built all those IDEs and debuggers and package managers for (some / many / most of) those other languages; you can build them for SQL too.

Another option is to use an approach like Prevayler: https://prevayler.org/

The basic notion is you keep your data hot in RAM and manage it directly. You make every change an object (or a command), and write that out serially to a log before you execute it. That gets you the ACID guarantees but with no I/O but linear writes, so it can be extremely fast.

It only makes sense when your data fits conveniently in RAM, but that's a lot of things.

I don't consider querying a relational database, transforming its data, or validating its state transitions to be general programs. I consider those to be special purpose programs, which benefit from special purpose tools tailored for writing them. SQL is one such tool.

I sometimes simplify social interactions by dividing them into two sets: friendly-social and engineering.

In friendly-social environments, it is all about avoiding overly negative topics. It is not lying, but just keeping the conversation track on things that are positive and interesting.

In engineering environments, logic is king. You need to be able to tell an engineer that their rocket designs will not fly and put ego's aside.

> In engineering environments, logic is king. You need to be able to tell an engineer that their rocket designs will not fly and put ego's aside.

In software(!) engineering opinions are important though.

Of course. This is just a simplification that I find useful.

Software is less like traditional engineering as there are no "right" ways to do things.

I think it is more to do with the so called "Object–relational impedance mismatch", which I guess is related to schema migrations.

NoSQL would still have migration issues as the types change over time, much like the table schemas. You would need to be able to read/write older objects stored, or transform them all to the newer object schema in one go.

I remember when Mongo DB first came out, it seemed the most liked feature was that you could just JSON.stringify and JSON.parse things into and out of the db.

I personally prefer SQL tables, as the act of designing the tables and their relations seems to half way solve a problem, and removes the issue of "which tree structure should this value live in, how do I copy it to both of these types?".

Under "Everything is an Expression":

        items = (() => {
          const results = [];
          for (const item of items) {
            if (item.length) {
              results.push(item.toUpperCase());
            } else {
              results.push("<empty>");
            }
          }
          return results;
        })();

Seems like they are purposely making the JS version extra long. It could be:

        items = items.map(x => x.length > 0 ? x.toUpperCase() : `<empty>`)

Edit: Just realised the code on the right is the compiled code, not the "equivalent hand written JS".

My kingdom for "everything is an expression" in JS/TS, but that would likely require an entirely new language.

If you’re willing to accept a little bit of extra syntax/ceremony, the `do` expressions proposal[1] is pretty much this (but it’s only stage 1 so who knows when/if it’ll land).

1: https://github.com/tc39/proposal-do-expressions

We often add promising TC39 proposals into Civet so people can experiment without waiting.

We've added https://github.com/tc39/proposal-pipeline-operator, a variant of https://github.com/tc39/proposal-pattern-matching, a variant of https://github.com/tc39/proposal-string-dedent and others.

Since our goal is to be 99% compatible with ES we'll need to accommodate any proposals that become standard and pick up anything TC39 leaves on the table (rest parameters in any position, etc.)

Nice! Wasn't aware of that at all.

At some point you might as well just use lisp, right? :D

I love me some lisp, but I definitely prefer my JS-hosted code to be as close to JS language and semantics as possible (and that’s after a few years working in ClojureScript). Then again I’m commenting in a thread about an article with CoffeeScript in the title so I’m probably the weird one here.

Have you considered https://github.com/squint-cljs/squint ?

Personally I couldn't let go of Clojure's other advantages but at least using the syntax would let you step off the syntax churn bus

No, unfortunately the greener pastures I found have type annotations. I miss the parentheses like hell, and I miss the actual state semantics of Clojure even more. But I wouldn’t give up static types for any of that. If I explore lisps again I’m going to start with Typed Racket.

Given than in JS an empty string is a falsy value you can go even shorter:

     items = items.map(x => x.toUpperCase() || `<empty>`)

The original ternary "fixes" the cases where `x` is "wrong" (e.g., is not a string - `x.length` does not fail, but evaluates to false, and thus you still get `<empty>`).

This even more terser code will fail if `x.toUpperCase()` fails with an exception (such as when x is not a string).

Given the example I think it is reasonable to assume it is always an string; otherwise if there is any possibility that x is not a string you can just use optional chaining:

     items = items.map(x => x?.toUpperCase() || `<empty>`)

See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Good point. I often forget that there's option chaining in javascript (now-a-days).

Your version doesn't correspond to the code written on the left side.

You are right, I did not realise it was the compiled code.

I thought it was the comparable hand written JS.

I think CSS and the domain of laying out things in 2d (and responding to state changes) with code is actually inherently complex, so which ever layout system you use is going to have a steep learning curve.

Many of the newer CSS features prevent you using JavaScript to achieve the same thing, which is better as it results in better performance and easier to understand code.

I would rather have newer standardised selectors than see the same pattern re-implemented with JS differently in every codebase.

I like the way you use a combination of <textarea> for editing and <pre> for DOM elements.

I actually have come to the same solution for a transcription web app.

I have found that <textarea> manipulation from JS is not really possible without `Document.execCommand` which is deprecated. Some edits will clear the undo history.

Do you have any notes you can share?

Yeah definitely seeing how far I can push textarea! Not sure it’s smart and the one issue I haven’t solved is the block indents on editing. But it’s ok. Still have the occasional or semi frequent rendering error when tags interfere. Hoping to stay away from content editable and any complicated editors. I use js to measure the width of spaces to set up pre so the two layers line up.

My notes on this:

- <dialog>.showModal() is an indirect API to `top-layer`.

- `top-layer` is kind of like a sibling to the root <html>, elements can be placed into the top-layer from any position in the existing DOM (it is like they have two positions). This allows co-locating your <dialog> next to the relevant elements in the tree.

- There is only one `top-layer` but it can have many children. Last opened === current element on top.

- Z-index has no effect in the top-layer. No need to compete for a higher z-index.

- ::backdrop is a pseudo element that you can style behind the <dialog>. It is always below the last <dialog> opened.

- Not supported in Safari <= 15.3

> - Z-index has no effect in the top-layer. No need to compete for a higher z-index.

This is the kind of boring feature that can end up saving huge amounts of developer time. Z-indexing in CSS is kind of annoying and I've seen projects just detach dialogs from their normal position in the DOM entirely to get around stacking errors before. That obviously comes with its own set of problems...

There are scenarios where you're still going to have to build custom controls, but a lot of my experience making dialogs has been frustration over these kinds of boring features -- "how do I get this to display on top and lock the page without writing a bunch of extra code and worrying about of edge cases?"

----

Minor question:

> - There is only one `top-layer` but it can have many children. Last opened === current element on top.

Is this true? The spec says:

> The top layer is an ordered set of elements, rendered in the order they appear in the set. The last element in the set is rendered last, and thus appears on top.

I'm still playing around with `dialog` elements, so you may well be right, I'm just having trouble finding the actual spec rules about what happens when there are multiple dialogs and they're being simultaneously manipulated.

----

> - Not supported in Safari <= 15.3

Worth noting that there is a polyfill (https://github.com/GoogleChrome/dialog-polyfill), but that the polyfill comes with some fairly large limitations, specifically that they don't advise dialogs be used as children of elements with their own stacking context.

This is reasonable, but also... my first thought when I originally ran into `dialog` was "finally I can stop worrying about which of my elements create new stacking contexts!" -- so it does decrease the usefulness quite a bit.