Comment by spankalee

Comment by spankalee a day ago

27 replies

View on Hacker News

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

jeswin a 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

Reply View 9 replies
  • spankalee 17 hours ago

    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.

    Reply View 0 replies
  • tipiirai a day 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.

    Reply View 3 replies
    • jeswin a day 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.

      Reply View 1 reply
      • threetonesun 17 hours ago

        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.

        Reply View 0 replies
    • potsandpans 3 hours ago

      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.

      Reply View 0 replies
  • WA a day ago

    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.

    Reply View 0 replies
skrebbel 16 hours 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!

Reply View 1 reply
  • spankalee an hour ago

    Thanks so much for the kind words! It means a lot :)

    Reply View 0 replies
tipiirai a day 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.

Reply View 14 replies
  • spankalee a day 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.

    Reply View 13 replies
    • tipiirai a day 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.

      Reply View 12 replies
      • spankalee a day 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?

        Reply View 11 replies