Comment by spankalee

Comment by spankalee 7 hours ago

36 replies

Web components are the way out of this trap. Every single framework that isn't React should be wholeheartedly supporting web components to make sure that they have access to a viable ecosystem of components and utilities without having to bootstrap an entire competitor to React and it's ecosystem.

While a lot of people view web components as competitors to frameworks, they don't really have to be. The just define an interface between component implementations and browsers so enable interop and reliable composition.

On top of the low-level APIs frameworks have a lot of room to innovate and customize:

- There is a huge range of possibilities an opinions on how to author components. Buildless, JSX, template literals, custom syntaxes and compilers, class-based, functional, etc.

- There is a lot room for gluing components together in different ways: custom component loaders, context protocols, SSR, suspense-like utilities, styling and theming frameworks, etc.

- State management cuts across the UI independently from components and has a lot of room for innovation.

Being able to say "Use our new Flugle framework, it works great with all the other frameworks and adds awesome scaffolding" should be a nice selling point and buffer against React monoculture, as opposed to building a different and much smaller silo.

indolering an hour ago

Not unless you can develop an equivalent to React Native. That's the rub here: browser tech is just way slower than what can be achieved with native code. React's primary value (now) is deduping GUI development across platforms.

  • diiiimaaaa 36 minutes ago

    Not only that.

    My main problem with web components that you end up with a build step anyway.

    Not every component is interactive and relies on JS, some are just static elements (say avatar image) that you wanna render right away (but at the same time keep styles and logic scoped). Declarative shadow DOM helps, but you end up with a bunch of duplicate code in your final output, which begs the question - why am I using web components at all.

TehShrike 2 hours ago

I worked on a business app made with lit web components and all properties being stringly typed was a real drag. It didn't compare to a realtime-first component library.

lelanthran 40 minutes ago

> Web components are the way out of this trap. Every single framework that isn't React should be wholeheartedly supporting web components to make sure that they have access to a viable ecosystem of components and utilities without having to bootstrap an entire competitor to React and it's ecosystem.

I've been using web components using a wrapper to avoid all boilerplate. It gets me 80% of web component functionality with very little effort: https://github.com/lelanthran/ZjsComponent

Discussed on HN previously: https://news.ycombinator.com/item?id=44290315

Now this is not perfect, but there is, for me, no easier way to create and use new html components.

cowsandmilk 6 hours ago

At my large corporation, we are required to use a centralized React library for internal apps. So it is not “react by default”, but instead “React is the only choice”. 100% agree that our path out is for the central library to be reimplemented as web components to open us up to using whatever framework we choose.

  • tptacek 2 hours ago

    That's a very normal thing for a big shop --- if it wasn't React it would be something else --- so kind of tough to pin that constraint on React.

austin-cheney 3 hours ago

Strong disagree. Web Components are react in different clothing. You don’t need this component-based framework style architecture to write applications for the browser.

I promise writing applications for the browsers is not challenging. You don’t need big frameworks or component madness that’s more of the same.

  • WA 3 minutes ago

    React made reactivity popular. Web components don’t give you reactivity. You still tell the UI how to update based on state changes imperatively and that is annoying as hell.

    If you want reactivity in web components, you need a wrapper or another framework/small library.

  • onion2k 2 hours ago

    You don’t need big frameworks or component madness that’s more of the same.

    You don't, but in any sufficiently complex app you'll end up writing a sort of 'mini framework' of your own as you abstract all the things that crop up more than a few times. That framework might be really nice at the start but it'll get more and more hacky as the project continues, especially if you're constrained by resources. Eventually you'll regret not using something standard.

    If there are more than a couple of developers on the project it'll be something no one really likes after a year or two.

    If there are more junior developers it'll be a reason for them to want to get off the team because they won't want to be a part of the 'old legacy code'. Then it'll be hard to find people who want to join.

    Eventually, as it gets harder to recruit people to the team because it's on a weird, legacy framework that no one knows, there'll be a big project to refactor it on to something more standard. That'll probably be React. At the same time most of the senior developers will be calling to scrap the codebase entirely and rebuild it (wrongly in almost every case, but they don't care and want a greenfield project to play with new things on.)

    This is a story that has played out at every large org that builds apps internally, and probably a lot of startups as they mature and need to hire more devs. You might as well skip all of it and use a standard framework from the start.

  • daveidol 3 hours ago

    Sure you can make a blog without a framework. But for complex applications it’s far better/easier than raw DOM manipulation or rolling your own thing.

    • austin-cheney 2 hours ago

      I disagree. It’s actually the same effort either way, but one of those costs substantially more to maintain and performs far slower.

      • adastra22 2 hours ago

        It is not obvious to me which one you are talking about.

    • netbioserror 3 hours ago

      We should probably be making widget toolkits for the Canvas and using WebSockets for communication. DOM manipulation is a total hack-job. It's somewhat flexible, but the performance and dark-pattern cost is just too great. If you're making an interactive application, then treat it like an application and draw widgets to a canvas.

      • ioseph 2 hours ago

        This is an insane take, show me a responsive button with hover state and a tooltip implemented in the canvas that outperforms a button rendered with React.

      • christophilus 3 hours ago

        Accessibility suffers with that approach.

        • extra88 2 hours ago

          It doesn't just suffer it's impossible unless you recreate the whole thing with actual HTML behind the <canvas> rendered version.

  • afavour an hour ago

    > I promise writing applications for the browsers is not challenging.

    Yeah it is. I don’t like React but I’ve been doing this since the days of MooTools all the way through Backbone to the libraries we have today. Once your app reaches a certain size and/or reaches a critical mass of contributors it does get challenging and modern frameworks reduce that challenge.

    That can be taken way too far. Almost every time I’ve worked with Redux I’ve found it infuriatingly unnecessary. And React is far from the best framework out there. But it is a huge benefit all the same.

  • ahdanggit 3 hours ago

    HARD AGREE!

    It just takes the minimal amount of discipline, and some conventions. I know it can be done because I did it, lots of people did it just a few years ago (some of those apps are STILL running today.)

squidsoup 6 hours ago

Curious if has anyone had much success using web components within a react UI library? When building a component library on a bespoke design system, I'm quite pleased that I can rely on a headless library like RAC to ensure that the base component implementation is accessible and works well on touch devices. I can see theoretically that web components could be a complimentary tool, but in practice I'm not certain where they're best used.

jongjong 7 hours ago

Agreed, Web Components don't require any framework and you can achieve everything you can achieve with React (including reactivity via attributeChangedCallback), the learning curve for Web Components is actually much less steep than React when you consider from the perspective of someone starting from scratch.

Furthermore, Web Components enforce good patterns; like the fact that you can only pass strings as attributes (by-value) is actually genius as it encourages simple, minimalist component interfaces and avoids pass-by-reference issues for which React community had to invent an entirely new paradigm to protect against (I.e. Redux state management with functional programming approach).

And the great irony is that a lot of the top people who are still pushing React are basically rich from Facebook shares and don't have to work anymore. In effect many of them are forcing this technology onto young people who have no choice in the matter whilst they themselves don't need to use it or do any coding anymore. Meanwhile I know a lot of developers who want to leave (or have left) the industry because of how bad it is and how few decisions they're allowed to make.

It's demoralizing to work with inferior tools when you know better tools exist because you use them in side projects... When you see this, you think to yourself "If the company forces me to be inefficient with my choice of tooling, this gives me a license to be inefficient in other ways."

Personally, I don't even code anymore (only on my side projects). It's a shame because one of my main talents is writing clean, minimalist code. In my day job, I'm using drag-and-drop UI platforms like n8n and Flowise (for AI). It's refreshing to be able to use vanilla JS inside the nodes, without a compile step and on a real-world project that actually pays. These UI platforms are actually much more predictable to work with than React. When I was using React (for almost a decade), I was constantly debugging weird glitches and state management issues; I never encountered those with Web Components or with platforms like n8n.

  • spankalee 6 hours ago

    > the fact that you can only pass strings as attributes

    This isn't true at all though. It's a lie started in the early days by React engineers that just won't die, unfortunately.

    Web components are objects and they can have properties and accessors like any object. The vast majority of declarative template systems like React, Lit, Vue, Angular, Svelte, Solid, etc., will declaratively set properties - which can carry any type of JavaScript value, including complex objects and function - on web components which can then be used to update the component's DOM.

    • sporritt 41 minutes ago

      It is true that web components can have properties and accessors like any object. But what you cant do is pass anything other than a string to a web component's attributes in the markup. I wrote a short article about this when I was investigating web components with JsPlumb a while ago:

      https://jsplumbtoolkit.com/blog/2024/07/18/wrapping-data-in-...

      TL;DR I ended up creating a context object and a BaseComponent that can access the context. Subclasses of the base component prefix their attributes with a colon to instruct the code to look in the context:

      <date-label :value="now"></date-label>

      • moron4hire 11 minutes ago

        I think you might be missing out on the standard Time element in HTML5. In use, you set its datetime attribute to a machine-readable format and set its body to the user-readable format.

        Also, I tend to think of HTML not as my application view, but as a document that represents a serialization of your view. The actual, live view itself is the DOM. Once that document is parsed and rendered, the HTML source from whence it came doesn't matter anymore. Stringly attributes should no longer be a concern.

        Though, admittedly, the HTMLTimeElement's dateTime property is still a string value. I imagine that is more of a legacy issue. The Date class in JavaScript is a mess as well.

    • _heimdall 3 hours ago

      That approach passes values in JS rather than the DOM, right? I read the go comment as talking specifically about DOM attributes which can only be strings (well, you can have boolean attributes as well).

      Web components can be passed objects in JS, but its news to me if that is available in HTML.

andrewmcwatters 7 hours ago

I moved my entire business off React and now I don’t have to worry about tinkerers at Meta deciding to reinvent React every 2 years and tricking everyone by keeping the name again and again.

Web components are fantastic. They are the real future.

  • rhet0rica 3 hours ago

    https://i.imgur.com/7ITZb7d.jpeg

    Aren't web components a pain in the ass to use?

    • prisenco 36 minutes ago

      They could be better, but they're not nearly as difficult as people like to make them out to be.

      And they come with extra benefits like no build tool required and native browser support.

    • bythreads 3 hours ago

      Nope

      Lit.dev

      • brenainn 3 hours ago

        I like lit. I'm not primarily a web developer and I've found it intuitive and easy to read and write. What I find more confusing than frameworks is building, bundling, ES modules, the whole NPM ecosystem.

        • balamatom 2 minutes ago

          >building, bundling, ES modules, the whole NPM ecosystem.

          That's evolved hand in hand with the React monoculture. Just like it, there are things about it that feel designed to be a pain in the ass. Probably as a result of more inept moat-building in the then-newly ballooning field of frontend.

          Readers might look up whan an import map is sometime, as well as where it is and isn't supported.

  • echelon 2 hours ago

    React gets reinvented every year?

    Are you talking about functional components instead of class components? What big changes am I missing here? It seems pretty static to me.

FpUser 3 hours ago

>"While a lot of people view web components as competitors to frameworks, they don't really have to be. The just define an interface between component implementations and browsers so enable interop and reliable composition."

I avoid frameworks like a plague. Plain JS, web components and some good domain specific libs are more than enough to cover all my needs