Hacker News Reader

Comment by steinuil | Hacker News Reader

> JSX is not "Just Javascript"

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.

View on HN

I should also explain what I mean by "thin syntactic sugar": JSX is a local transformation which doesn't need any external context to be translated to plain JS. `<div className="greeting">Hello</div>` will always compile to `React.createElement('div', { greeting: "hello" }, "Hello")` no matter what; in Svelte, `count += 1` will output different code based on its context because it will compile the whole component as a single unit.

> compiles to who knows what

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.

Yeah, but it's still a DSL and that means that I can't be sure that everything I can normally do in JS is valid there, and external tooling won't be able to make sense of it without additional work.

Those sounds like very abstract concerns - I haven't had any issues on those lines using Svelte for years now. The $: syntax is actually valid JS (labels) so standard JS tooling should always be able to parse it.

> It's very thin syntactic sugar over a function call

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.

> It's a set of AST nodes.

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.

> 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

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.

I wasn't criticizing DSLs in general, they're great, but in the specific case of web development I prefer React's approach over using a DSL like most other frameworks.

Reply on news.ycombinator.com