3 ms·

The great part about JSX is some random new framework doesn't need a VS Code plugin to get syntax highlighting, and type checking Just Works. I can accept a te

The great part about JSX is some random new framework doesn't need a VS Code plugin to get syntax highlighting, and type checking Just Works. I can accept a template language for a major framework where I can count on decent developer tooling, but it's a hard turn-off when evaluating niche frameworks.

Semaphor 4y ago
Huh, that’s a pretty good point I never thought about. It’s not relevant to me personally, but having such a standard is certainly helpful.
robertlagrant 4y ago
JSX semantics are tied to React, aren't they?
- sph 4y ago
  Maybe I haven't tried hard enough, but it was a pain doing JSX/Typescript with mithril. All the TSX tooling expects a React API and if you use something else you get a ton of annoying type errors.
  - WorldMaker 4y ago
    I used TSX with Cycle.js for a while and didn't experience too much trouble. Typescript has some simple compiler options to change how it generates JSX or JS and doesn't bundle any types out of the box for TSX: all of the React API types come from React's type library. Sometimes that was more of detriment than if there were base types in TSX because reimplementing mostly the same set of standard HTML elements and HTML-like attributes a third time in a different .d.ts file when switching VirtualDOM implementations was a chore. (It was fine, but it was a chore.) If you are seeing errors that are React specific, most likely means you just need a subtle tweak in your tsconfig.json.
- spiffytech 4y ago
  Not necessarily - bunch of languages have adopted JSX with slightly or substantially different component semantics from React (for example Vue, Solid, Forgo, Crank). A Crank component (which is an async generator) feels very different from a React component. Likewise for a Forgo component, which uses closures for state and doesn't have automatic rerenders. Solid doesn't have components in the traditional sense at all. Although the syntax they use for representing HTML is the same, the rest of the framework can have arbitrary design.
- eyelidlessness 4y ago
  Definitely not. They’ve always been explicitly implementation-agnostic (literally specified as not having any semantics). An increasingly popular JSX transform (used by Solid) has very different semantics. JSX semantics are more like an s-expression than anything else. Code as data, you can do anything with it you like. I use it to make art and render that to meta links on my personal site. You can use it to render CLIs, or even JSON responses on a server.

Semaphor 4y ago

Huh, that’s a pretty good point I never thought about. It’s not relevant to me personally, but having such a standard is certainly helpful.

robertlagrant 4y ago

JSX semantics are tied to React, aren't they?

sph 4y ago
Maybe I haven't tried hard enough, but it was a pain doing JSX/Typescript with mithril. All the TSX tooling expects a React API and if you use something else you get a ton of annoying type errors.
- WorldMaker 4y ago
  I used TSX with Cycle.js for a while and didn't experience too much trouble. Typescript has some simple compiler options to change how it generates JSX or JS and doesn't bundle any types out of the box for TSX: all of the React API types come from React's type library. Sometimes that was more of detriment than if there were base types in TSX because reimplementing mostly the same set of standard HTML elements and HTML-like attributes a third time in a different .d.ts file when switching VirtualDOM implementations was a chore. (It was fine, but it was a chore.) If you are seeing errors that are React specific, most likely means you just need a subtle tweak in your tsconfig.json.
spiffytech 4y ago
Not necessarily - bunch of languages have adopted JSX with slightly or substantially different component semantics from React (for example Vue, Solid, Forgo, Crank). A Crank component (which is an async generator) feels very different from a React component. Likewise for a Forgo component, which uses closures for state and doesn't have automatic rerenders. Solid doesn't have components in the traditional sense at all. Although the syntax they use for representing HTML is the same, the rest of the framework can have arbitrary design.
eyelidlessness 4y ago
Definitely not. They’ve always been explicitly implementation-agnostic (literally specified as not having any semantics). An increasingly popular JSX transform (used by Solid) has very different semantics. JSX semantics are more like an s-expression than anything else. Code as data, you can do anything with it you like. I use it to make art and render that to meta links on my personal site. You can use it to render CLIs, or even JSON responses on a server.