Comment by spankalee
1 day ago
I help maintain Lit[1], which I consider a very standards-first non-framework.
With Lit you can build full apps with standard and plain JS, CSS, and HTML; standard web components; and no build tools.
I don't immediately see how this is any more standards-first, especially when it mentions Markdown, tooling, and a CLI. I don't actually really see what exactly this even is from this landing page. It would help to show something up front.
[1]: https://lit.dev
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.
1 reply →
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.
Fwiw there's a great VS Code extension for lit-html which (for me) fully solves the IDE support issue. https://marketplace.visualstudio.com/items?itemName=runem.li...
Obviously that doesn't solve it for other IDEs, but back when TS and JSX and ES6 were new they had bad IDE support too.
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.
Magic Loop looks very similar to Crank (that nobody knows about either). Was it an inspiration?
I had this 2017 project called Sailboat [1], which was almost the same thing but for React. I am aware of Crank though, and it's quite nice.
[1]: https://medium.com/@jeswin/sailboat-a-modern-router-for-reac...
I just want to do a drive by comment to compliment you and the rest of the Lit team on Lit. I love how using a TS compiler is optional, I'm impressed by how fast and pragmatic lit-html is, and how easy it is to understand how it can be fast (vs, say, React's virtual DOM). Lit has a Redis-like quality of simplicity to it, like good Italian food and very much unlike eg React or Vue. I could study the architecture for an hour and feel like I completely grokked how it worked and why.
I can't say I completely love the OO aspect of it (notably the amount of boilerplate it requires to define props), and personally I think Lit would've been more powerful if it were optional for LitElements to be Web Components (having a million nested shadow DOMs by default is, well.. let's say it makes some common pragmatisms like global CSS overrides needlessly hard. also a single global namespace for tag names gets messy fast, and so on). But given the goals you set yourself, Lit is absolutely amazing. Small, fast, easy. Hats off!
Thanks so much for the kind words! It means a lot :)
Lit has indeed done important work in standards-first development through web components.
But the issue is that Lit still approaches web development through the lens of components. While these components may be "standard" web components that encourages developers to keep bundling markup, styles, and behavior together rather than maintaining proper separation of concerns.
Nue takes a different approach by removing all the unnecessary layers between the developer and web standards. Where Next.js forces content into JavaScript components and requires complex build pipelines, Nue provides a more direct development experience built directly on HTML (layout), Markdown (content), vanilla CSS, and vanilla JavaScript.
With Nue HMR completes in milliseconds rather than seconds. The HMR spans css, content, data, and HTML-based server and client-compnents. CSS updates instantly through the native cascade instead of rebuilding components. The entire development feedback loop stays under 100ms, maintaining perfect flow while preserving document state.
Most importantly, this sort of standards-first architecture enables true systematic design trough vanilla CSS. Instead of coupling design decisions to components through utility classes or CSS-in-JS, with Nue you can build design systems directly with CSS variables, calc() and other modern goodies.
> But the issue is that Lit still approaches web development through the lens of components
Why is this a problem? Reuse is incredibly important for building almost anything on the web, and it's been with us since long before the web platform supported it natively, e.g. with CGI scripts that used Perl functions, to output repeated HTML "components", or PHP, web frameworks, etc.
If you don't have some method of reuse in the platform or framework, developers either have to copy-and-paste (and deal with so many difficulties of updating and maintaining consistency that it's not a realistic option), or push reuse to a non-standard layer of the system like server templating.
Server templating is fine, but it doesn't actually get rid of the implicit concept of components that'll be in the page or app, it just disaggregates it among to non-colocated parts of the system.
The issue is the coupling of HTML and CSS into your JavaScript code, which is a step away from the standards first development model.
12 replies →