Comment by jeswin

1 day ago

Lit is amazing. But I don't like template strings for HTML. The IDE doesn't understand it automatically, and lit jsx had a bunch of issues last time I tried to use it.

In my view, JSX will be the true legacy of React. Applications are code. Many frameworks (such as htmx) extend HTML to bring a bit of programmability into it; but I felt they were just framework-specific, non-standard rules to learn. JSX is more standardized, and isn't as framework dependent.

Shameless plug: Magic Loop [1], a Lit alternative (that nobody knows about) which uses WebJSX [2] underneath.

[1]: https://github.com/webjsx/magic-loop

[2]: https://www.webjsx.org

We're in a thread talking about "standards first" things, and JSX just isn't a standard part of the web platform, nor is it in anyway standard within the ecosystem of JSX.

JSX has no semantics, only syntax. What a JSX expression means changes depending on the transform you use and the framework you use with it. Some JSX transforms produce values, some produce side-effects. Values produced with JSX under different transforms have different types and are not compatible with each other.

Maybe one day some form of JSX will be standardized, but until then tagged template literals work great with no tools and their behavior is fully determined by the template tag that you use, not an external transform. They're also more expressive than JSX (In Lit we support explicit attribute, property and event bindings rather than overload a single namespace for all 3).

Support for syntax highlighting, type-checking, and intellisense are available to IDEs via plugins and LSPs.

I think the true legacy of React will be normalizing tight coupling, especially when combined with Tailwind. An entire generation of developers learned to bundle everything into JavaScript - content, styling, behavior, and state all living in the same files. Nue aims to reverse this mindset by showing how proper separation enables more sophisticated systems, particularly once our design systems arrive and you can see the difference. Now it's just words.

  • > React will be normalizing tight coupling, especially when combined with Tailwind.

    You're skipping the history of why it came to be.

    When I started writing HTML, you needed excellently structured CSS because there were no components. So you needed .sidebar, .topbar, .button.ok etc. This was extremely hard to get right. We cannot see the future, and we cannot know what an application will become - figuring out a globally scoped css hierarchy was difficult even for very experienced developers.

    Post 2010 (with frameworks like Backbone.js and Angular), people started splitting apps into components. This meant that the smallest unit of reusable design could be a component, instead of CSS classes and JS functions. Adoption of self-contained styling in components increased gradually after Bootstrap brought in utility classes, CSS-in-JS picked up, and Tailwind made it easier.

    It made total sense of course, because the component is what you want to re-use. To address your point directly, tight coupling within a component is ok - maybe even a good thing. We did not get there without trying other ideas, we tried them for twenty years.

    • BEM naming conventions in CSS and splitting HTML into components at the back end template level existed long before JS frameworks and single page applications.

      I'd say the big mind-shifts with React were the virtual DOM replacing things like progressive enhancement, and later with Next and server side components, the commingling of back-end and front-end, which is mostly a complicated solution to the problem already created by moving away from progressive enhancement.

  • This comment is representative of something like a mass psychogenic illness prevalent in the hacker news community.

    Which could be roughly summarized as: an absurd and distorted perception of application development for the web, the goals people in that domain are trying to achieve and the history of how we got here.

    The real true legacy of react will be bringing functional reactive programming to the masses. Packaging it in a way that a common junior dev could build an intuition around.

Cool, webjsx might be exactly what I was looking for. A simple thing that lets me map state to the DOM to make reactivity easier.