It's very thin syntactic sugar over a function call. It has a very simple 1:1 mapping to the output code, as opposed to "magically reactive `foo = bar`.
> I'm sure not many people would be willing to argue that throwing promises (as react suspense supposedly does) is a holy grail of frontend development, even though it is "just javascript".
I'll give you that hooks and suspense are straying further from normal js because they don't behave like normal functions do and have special rules for being called; hooks are a DSL for encoding incremental computations into js, and suspense is just the react team fawning over algebraic effects/delimited continuations and trying to reproduce them in js.
But then again, all of these can be defined in normal JS code as opposed to a DSL which compiles to who knows what, so all the rules applying to normal JS and its tooling apply to them.
You can easily read the compiled Svelte output and see how each piece of template is wired to the state. There is very little cruft in it, and no real runtime library to speak of.
The debugging experience (not that I have needed it much) is light years ahead compared to going through React's internals.
Actually, it's not. It's a set of AST nodes. What they compile to is entirely implementation-specific. Look at Inferno.js or Solid.js compiled code for example; it looks nothing like simple function calls. Although obscure, there are also other spin-off ideas floating around like compiling to math expressions or to file system APIs. Even within the scope of React, the idea of allowing configuration for optionally compiling to `h` instead of `React.createElement` for minification purposes has been brought up (and is doable in React proper in user space, and out of box with Preact).
The idea of adding JSX to JS got brought up before and it got shot down precisely because the compilation semantics of JSX are not formally specified.
> all of these can be defined in normal JS code as opposed to a DSL
Right, but my point is that "just javascript" is not a good guiding light if the goal is implementing a pit of success. The crank.js blog post talks about how its author thinks React has gone off the rails pursuing some notion of purity. DSLs are not automatically bad things. I've mentioned Solid.js before and it has a component-based DSL for control flow, and honestly that looks quite reasonable. At some point if one jumps the shark, so to speak, and starts making uncomfortable contortions to stay within the confines of "just javascript" and avoid DSLs at all costs, that amounts to leaving a useful tool unused at the table, where it could have been effective. "When all you have is a hammer", etc.
Ok, but you could make the same point about plain JS as in Svelte. I haven't looked into it too much, but from the readme Solid.js looks more like a compiler than a library, so whatever it outputs when it sees JSX doesn't have much to do with what JSX is usually used for, imo. I've only ever seen it used as syntactic sugar for function calls, be it `React.createElement` or `h` or `jsx`.
> At some point if one jumps the shark, so to speak, and starts making uncomfortable contortions to stay within the confines of "just javascript" and avoid DSLs at all costs, that amounts to leaving a useful tool unused at the table, where it could have been effective.
Personally I find it much more likely that I'll have to bend over backwards when I'm dealing with a DSL rather than just plain code, because the DSL will be really well optimized for one usecase, but has omitted another usecase that I will need at some point, and then I'll have to find some hack to accomodate the DSL rather than just add that one line of code that I could've used if it was just Plain Code.
The downside is that some other things will look kind of awkward and since you're now dealing with a turing-complete language you'll lose analizability, but IMO for UIs those are worth losing if I can just use plain code.
I think this is cherrypicking at generalities. It's just as easy to run into a wall with "regular code" because some API doesn't provide what you need. Conversely, DSLs often have escape hatches (e.g. https://www.smarty.net/docsv2/en/language.function.php.tpl)
DSLs are useful sometimes. Heck, the entire web is built on top of DSLs: HTML, CSS, SQL, even JSX. I agree that there are valid criticisms to be made about specific implementations of specific DSLs, but I don't agree that those criticisms are generalizable to the concept of DSLs as a tool in a framework designer's arsenal.
That's not the case with Vue, Angular or Svelte. There's framework specific syntax that you need to learn. Eg: '{#each things as thing}' from Svelte's documentation.
Counter in this example is likely a proxy object that knows when it‘s changed and tells svelte to re-render.
It‘s also not immutable, which can cause very confusing interactions in global state.