4 ms·

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; stan

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 https://lit.dev

tipiirai 2y ago
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.
- spankalee 2y ago
  > 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.
  - tipiirai 2y ago
    The issue is the coupling of HTML and CSS into your JavaScript code, which is a step away from the standards first development model.
    - spankalee 2y ago
      Can you explain how it's not standards first? Web components can be written in standard JS modules, loaded by or inlined into standard HTML, instantiated by standard custom element tags, rendered with the help of standard <template> elements, and styled with standard CSS. If you don't use the web platform's native facilities for re-use, then you do have to use some non-web-standard system, like a server framework. Is there some way you see that that's more standard than the web?
      - tipiirai 2y ago
        In Nue you're literally writing standard HTML, CSS and JavaScript. Your Markdown- based content generates semantic HTML. Your styling is pure CSS with modern features like nesting and container queries. JavaScript remains vanilla JavaScript. React and similar frameworks introduce non-standard abstractions like JSX and proprietary component models that deviate from web standards. They couple structure, styling and behavior into JavaScript components. With Nue your codebase becomes primarily CSS-based, with clean separation between content, styling and behavior. You're working directly with CSS rather than through framework abstractions. Hopefully this FAQ answers most of your questions: https://nuejs.org/docs/faq.html https://nuejs.org/docs/faq.html
        boredtofears 2y ago
        Perhaps this is pedantic but for someone who seems principled about strictly using standards, markdown itself has no real standard - you'll find wildly different implementations all over the place.
        tipiirai 2y ago
jeswin 2y 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 https://github.com/webjsx/magic-loop [2]: https://www.webjsx.org https://www.webjsx.org
- tipiirai 2y ago
  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.
  - jeswin 2y ago
    > 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.
skrebbel 2y ago
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!
- spankalee 2y ago
  Thanks so much for the kind words! It means a lot :)
imtringued 2y ago
I was thinking of stencil, but lit is also an option, when I read the title. Meanwhile the creator of nue is apparently working on a static site generator based on markdown?

tipiirai 2y ago

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.

spankalee 2y ago
> 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.
- tipiirai 2y ago
  The issue is the coupling of HTML and CSS into your JavaScript code, which is a step away from the standards first development model.
  - spankalee 2y ago
    Can you explain how it's not standards first? Web components can be written in standard JS modules, loaded by or inlined into standard HTML, instantiated by standard custom element tags, rendered with the help of standard <template> elements, and styled with standard CSS. If you don't use the web platform's native facilities for re-use, then you do have to use some non-web-standard system, like a server framework. Is there some way you see that that's more standard than the web?
    - tipiirai 2y ago
      In Nue you're literally writing standard HTML, CSS and JavaScript. Your Markdown- based content generates semantic HTML. Your styling is pure CSS with modern features like nesting and container queries. JavaScript remains vanilla JavaScript. React and similar frameworks introduce non-standard abstractions like JSX and proprietary component models that deviate from web standards. They couple structure, styling and behavior into JavaScript components. With Nue your codebase becomes primarily CSS-based, with clean separation between content, styling and behavior. You're working directly with CSS rather than through framework abstractions. Hopefully this FAQ answers most of your questions: https://nuejs.org/docs/faq.html https://nuejs.org/docs/faq.html
      - boredtofears 2y ago
        Perhaps this is pedantic but for someone who seems principled about strictly using standards, markdown itself has no real standard - you'll find wildly different implementations all over the place.
        tipiirai 2y ago

jeswin 2y 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 https://github.com/webjsx/magic-loop [2]: https://www.webjsx.org https://www.webjsx.org

tipiirai 2y ago
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.
- jeswin 2y ago
  > 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.

skrebbel 2y ago

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!

spankalee 2y ago
Thanks so much for the kind words! It means a lot :)

imtringued 2y ago

I was thinking of stencil, but lit is also an option, when I read the title. Meanwhile the creator of nue is apparently working on a static site generator based on markdown?