12 ms·

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 h

• jongjong 1y 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 1y 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.
    • _heimdall 1y 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.
      • bythreads 1y ago
        Neither can react
        • _heimdall 1y ago
          I didn't say it can, I never actually mentioned react at all here.
      • moron4hire 1y ago
        I generally think the reflex to try to pass an object to an attribute on an element is a code-smell that the element hasn't been properly decomposed into sub-components. In those cases, I look more to adding child elements to represent those objects as an HTML serialization of the object.
        • jongjong 1y ago
          Wow. Yes. Great comment. So glad to come across someone else who fully gets it. Components should 'communicate' with each other. If you start passing elaborate structures, this is getting into the realm of micromanagement, not 'communication'. It means your concerns aren't properly separated. This is not a new theory. Alan Kay, who invented OOP has been saying such things for decades. People got totally the wrong idea about OOP by focusing on mechanisms to allow passing complex structures to each other. That was never the point. Imagine if you worked with other people towards some goal and instead of talking to each other and separating responsibilities, ready-made, complex parts would just come out of people's mouths and everyone tried to make each others' parts fit together as an afterthought... Or imagine trying to catch a taxi and you bring a steering wheel and a tank of petrol with you to give to the taxi driver. It's absurd, obviously so, but that's what a lot of people have been doing with code.
• andrewmcwatters 1y 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 1y ago
    https://i.imgur.com/7ITZb7d.jpeg https://i.imgur.com/7ITZb7d.jpeg Aren't web components a pain in the ass to use?
    • bythreads 1y ago
      Nope Lit.dev
      • brenainn 1y 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 1y ago
          >building, bundling, ES modules, the whole NPM ecosystem. That's evolved hand in hand with the React monoculture over the past 10-15 years, maybe by way of a project called Babel. Babel set out to provide progressive enhancement for the original ES5 to ES6 migration, and then in classic POSIWID fashion began to thrive on a suite of a la carte incompatibilities. That experience is as much a contributor to the current automatism to to reach for (non-configurable) Prettier and Eslint, or more, than any rogue devs imposing fell coding styles. So yeah, plenty of things in JS infra that look like they've been designed to be a pain in the ass (a.k.a. "behavioral nudge", towards TS, what else) and very much seem like the result of more inept moat-building in the then-newly ballooning field of frontend dev. Readers might look up whan an import map is sometime, as well as where it is and isn't supported. How TS handled ES modules at the time Node16 changed their ESM support. Does ESM `default` correspond to CJS `module` or `module.exports`? Room for vendors to fuck up in innovative ways all round, this whole rotten ecosystem. Readers are also advised to try Deno if they haven't yet. On Node, try Vite instead of Webpack. Most importantly, try Lit with JS, import map, no builder/bundler, and test suite with coverage. Work out what is most comfortable for you, work out exactly how much toolchain makes you the most productive, and afterwards don't forget to ask yourself why the React cultists want to stick everyone in a hairshirt if not a straitjacket.
• cowsandmilk 1y 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 1y 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.
  • exesiv 1y ago
    copilot can help with translation "This folder contains React components. Create a new folder `components-vue`, and translate every component from React to Vue/Solid/Vanilla" ymmv
• squidsoup 1y 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.
  • bythreads 1y ago
    Did duetds.com
    • WickyNilliams 1y ago
      Hey I worked on that! And nordhealth.design. Both were used with React. And Vue, and angular, and classic server rendered apps like django
      • rick1290 1y ago
        Which pages are django?
        • WickyNilliams 1y ago
          Nothing on those docs. But the components were consumed in a Django app
• FpUser 1y 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
• austin-cheney 1y 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.
  • daveidol 1y 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.
    • netbioserror 1y 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.
      • christophilus 1y ago
        Accessibility suffers with that approach.
        • extra88 1y ago
          It doesn't just suffer it's impossible unless you recreate the whole thing with actual HTML behind the <canvas> rendered version.
      • ioseph 1y 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.
        • 1y ago
• TehShrike 1y 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.
  • jdkoeck 1y ago
    Alas, that’s a common misconception! You’re confusing properties with attributes. Attributes are set through HTML and are stringly typed, but litjs properties can be any js value. For instance, I have a project with a small web component that displays data from a duckdb wasm connection. The connection object is passed as a property and it works flawlessly.
    • chrismorgan 1y ago
      If you’re using it with something like React, passing attributes is easy, but setting properties is much harder, requiring using the escape hatches—I believe you’ll need useRef and useEffect, and a bit of care because it’s frightfully easy to do the wrong thing.
      • spankalee 1y ago
        No, React sets properties by default now. It was one of the last holdouts, but they finally fixed this in 19.
        • chrismorgan 1y ago
          Ah, didn’t know that, thanks for the info. From the release announcement <https://react.dev/blog/2024/12/05/react-19#support-for-custom-elements https://react.dev/blog/2024/12/05/react-19#support-for-custo...>: > Server Side Rendering: props passed to a custom element will render as attributes if their type is a primitive value like string, number, or the value is true. Props with non-primitive types like object, symbol, function, or value false will be omitted. > Client Side Rendering: props that match a property on the Custom Element instance will be assigned as properties, otherwise they will be assigned as attributes. And as https://custom-elements-everywhere.com/ https://custom-elements-everywhere.com/ puts it: > As of v19, React now uses a runtime heuristic to determine if it should pass data to Custom Elements as either properties or attributes. If a property is already defined on the element instance, it will use properties, otherwise it will fallback to attributes. All up it sounds fragile, and I’m not fond of how JSX syntax makes properties look like attribute, and I hate the way you lose the sometimes-crucial distinction of whether something is a property or an attribute (<input value> is the most obvious example of this), but I guess it’ll be fine in practice. I’m a little curious how they handle some of the event stuff, since React’s synthetic event system is such a legacy mess. And I never did like the way several popular libraries/frameworks (definitely not just React) special-case /^on.*/ attributes, so stupid how you now can’t safely use an attribute or property named “once”, “one” or “online”, all of which would be the most sensible name in certain situations.
• indolering 1y 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.
  • notpushkin 1y ago
    Do you have any benchmarks to back this up?
  • diiiimaaaa 1y 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.
    • WickyNilliams 1y ago
      Do you not end up with duplicate code when rendering `<SomeReactComponent />` multiple times?
    • indolering 1y ago
      Because that was around the time they stopped developing high level APIs to focus on lower level constructs. They wanted to build the primordial ooze from which you would build ui frameworks. But it turns out that those layers of indirection have made the web platform just another build target. It's just like how they never added optional types to JavaScript and now TypeScript is the de-facto standard. And now I'm stuck managing layers of indirection and compiler settings and debugging in nearly the same but /slightly/ different code than what I programmed in. Their logic is that if it can be done using a compiler or on the server side, then why bother doing it in the platform? Which is partially true: I want a compile step to optimize everything. But there is room in-between and this is often just an excuse to ignore dev UX entirely.
• lelanthran 1y 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 https://github.com/lelanthran/ZjsComponent Discussed on HN previously: https://news.ycombinator.com/item?id=44290315 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.
  • brazukadev 1y ago
    I use webcomponents the same way (with a big of help from lit-html) and there's no better way to create web apps. Knowing all the paths of a framework is absurdly productive
• IceDane 1y ago
  I'm wholly convinced that only people who have never tried to use web components for anything serious, and/or have basically no experience with web dev, are the only ones will make this argument. For example, a guy I know online who is an argumentative, boring backend dev that regularly has really bad and uninformed takes on things he has very limited experience with, he recently said he prefers web components. For all intents and purposes, he had ~0 web development experience.
  • WickyNilliams 1y ago
    I've worked in complex projects with web components. Works fine. Have you?
  • JimDabell 1y ago
    I think the same thing. In theory I would love to use the platform-native approach instead of a framework. In practice it’s an exercise in frustration. About once a year I give web components another shot and rediscover all the things I hate about them. They are not designed for what web developers consider components and they are full of footguns and bizarre limitations. Sometimes you will hear this subtly acknowledged as “web components excel at leaf nodes”. What this means in practice is that you shouldn’t use them for things that have contents. They are fine for their original use case, form elements where you don’t want page styles to affect things like the drop-down arrow in the control. But they are a massive disappointment for the typical use case.
  • spankalee 1y ago
    I have worked on several serious projects with web components, and I work closely with the teams building projects like Photoshop for the web, Reddit, Chrome UI, and Internet Archive. Are those serious enough?
  • guappa 1y ago
    Calling someone else boring because they disagree with you instantly makes me think they are right.
• zelphirkalt 1y ago
  But then I want web components that are not react web components, but cross browser standard web components, because if I use a js framework, I don't wanna be loading react as a dependency in the background and carry the same amount of bloat in my dependencies. And then we are not actually far from what we were always able to do with traditional templating engines, which already allow us to define separate reusable components. It is what they were made for. Full circle back, throw out all the JS frameworks.
• WA 1y ago
  Web components are an implementation detail. They don't bring anything framework-like to the table. The most important being: reactivity. You have to write DOM manipulations imperatively like you did 15 years ago with jQuery. If you don't want that, you gotta bring a wrapper or another reactivity library/framework. For many use cases, there's not much difference between writing a Web component or an IIFE (Immediately Invoked Function Expression) that attaches your JS functionality to a div somewhere like we wrote JS without jQuery 15 years ago, although Web components are more elegant. But still, they are mostly packaging. I say this as someone who likes Web components and who created several ones that are used in production. But just yesterday, when I added a new attribute to one of my Web components and wondered for a moment why the new attribute wouldn't get rendered, I realized that I forgot to add the code that imperatively tells the DOM how to update itself. Which is okay, because this is just a small component and it's pretty lightweight. I'd never use a framework for stuff that can be achieved without much effort in vanilla JS. My point is: selling Web components as a way out of this trap is disingenuous. They don't offer anything at all that is important for modern frontend dev.
  • degun 1y ago
    The offer a way to build custom components that you can use everywhere, on every frontend framework, or plain html page. That's something that can't be achieved with any other tool. Also, if you use the Lit framework to build web components, @property and @state are reactive. The DOM part that uses those variables updates by itself.
  • nikitaga 1y ago
    > If you don't want that, you gotta bring a wrapper or another reactivity library/framework. Being able to use a different library with a component, instead of the component being tied to React, is the whole point. React isn't 100x more popular because its reactivity system or any other feature is 100x better. Half the reason it's popular is network effects – too many frontend components / libraries are made React-only even though they don't need to be React-specific. Those network effects are the trap, not the reactivity system that's as good as any other for the purpose of writing a Web Component. If you don't want to use simple and small tools like Lit.js, that's fine, but that's your choice, not a limitation of Web Components. The point of Web Components is not to provide a blessed state management or virtual DOM implementation that will have to stay in JS stdlib forever, it's to make the components you author compatible with most / all UI libraries. For that goal, I don't know of a better solution.