| ▲ | spankalee 18 hours 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. 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. |
|
| ▲ | TehShrike 12 hours ago | parent | next [-] |
| 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 9 hours ago | parent | next [-] | | 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 7 hours ago | parent [-] | | 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 2 hours ago | parent [-] | | No, React sets properties by default now. It was one of the last holdouts, but they finally fixed this in 19. | | |
| ▲ | chrismorgan an hour ago | parent [-] | | Ah, didn’t know that, thanks for the info. From the release announcement <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/ 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. |
|
|
| |
| ▲ | WickyNilliams 7 hours ago | parent | prev | next [-] | | If you are consuming web components in any other framework, they will be setting properties, not attributes, by default Attributes are the default for html | |
| ▲ | spankalee 9 hours ago | parent | prev [-] | | I don't understand thinking that properties had to be strings. Did you just refuse to use property bindings or what? |
|
|
| ▲ | indolering 12 hours ago | parent | prev | next [-] |
| 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 11 hours ago | parent | next [-] | | 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. | | |
| ▲ | indolering 5 hours ago | parent | next [-] | | 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. | | |
| ▲ | IgorPartola 3 hours ago | parent [-] | | Isn’t that just a tooling problem? We use C/Rust/Java and compile to a completely different representation and it works just fine. When was the last time you had to write C or Rust and then debug stuff in assembly? |
| |
| ▲ | WickyNilliams 7 hours ago | parent | prev [-] | | Do you not end up with duplicate code when rendering `<SomeReactComponent />` multiple times? |
| |
| ▲ | notpushkin 11 hours ago | parent | prev | next [-] | | Do you have any benchmarks to back this up? | |
| ▲ | teg4n_ 10 hours ago | parent | prev [-] | | This isn’t really true with React Native, Hermes as a JS engine is just drastically slower than JIT-enabled web view . Sure the “native” parts will theoretically be faster but your app code will be a lot slower. Just test how long a rerender takes in react native on a device than react on a browser for the same device. |
|
|
| ▲ | cowsandmilk 17 hours ago | parent | prev | next [-] |
| 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 12 hours ago | parent | next [-] | | 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 5 hours ago | parent | prev [-] | | 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 |
|
|
| ▲ | lelanthran 11 hours ago | parent | prev | next [-] |
| >
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. |
| |
| ▲ | brazukadev 3 hours ago | parent [-] | | 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 |
|
|
| ▲ | zelphirkalt 8 hours ago | parent | prev | next [-] |
| 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. |
|
| ▲ | squidsoup 17 hours ago | parent | prev | next [-] |
| 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. |
| |
|
| ▲ | WA 6 hours ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | nikitaga 6 hours ago | parent | next [-] | | > 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. | | |
| ▲ | MrJohz 2 hours ago | parent | next [-] | | Except the problem with compatibility is almost always the reactivity element, right? Getting, say, Vue's reactivity system to compose properly with Svelte's, or React's with Angular's. And that's not going to work well when Vue is using signals to decide when to rerender a component, React is using its props and state, and Svelte isn't even rerendering components in the first place. This is especially difficult when you start running into complicated issues like render props in JSX-based frameworks, context for passing state deeply into a component, or slots/children that mean reactivity needs to be threaded through different frameworks. | |
| ▲ | WA 6 hours ago | parent | prev [-] | | I get your point. I'm fully with you that it makes no sense to use React and write React apps if you can achieve the same without React. I hate the fact that many great frontend components only work with React, especially considering that React didn't properly support Web components for ages, whereas almost every other framework had no problems with them. However, out of the box, Web components don't come with almost anything. Comparing React to Web components is comparing apples to oranges. Lit is great, but Lit is a framework. Now you're comparing React with Lit. Different story than React vs. vanilla Web components. | | |
| ▲ | spankalee 2 hours ago | parent [-] | | Lit is not a framework. Lit only helps you make standard web components that you can use anywhere *because they are web components*. You could take a Lit-based web components a rip Lit out and you would still have the same component that you can still use anywhere. Lit is just an implementation detail. | | |
| ▲ | MrJohz 2 hours ago | parent [-] | | Lit is a framework, that's the whole point of it. Lit is a framework that happens to generate web components, but the goal of Lit is to provide the rendering and state management necessary to actually write those components. That's the framework bit. If you take a Lit-based web component and rip Lit out, you have dead code that won't work because it's dependent on a framework that you have removed. You could take a Lit-based web component and replace it with a non-Lit-based web component and that would be fine, because Lit uses web components as its core interface, but Lit itself is still a framework. |
|
|
| |
| ▲ | spankalee 2 hours ago | parent | prev | next [-] | | Web components are the opposite of what you say: they are the component interface and specifically not the implementation. You can implement them however you want. What they offer is interoperability and the ability to use components outside of a framework or with a framework. And that's why they help solve the ecosystem trap. | |
| ▲ | degun 6 hours ago | parent | prev [-] | | 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. |
|
|
| ▲ | austin-cheney 14 hours ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | onion2k 12 hours ago | parent | next [-] | | 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. | | |
| ▲ | austin-cheney 8 hours ago | parent [-] | | This has never been true for me. I never end up writing any kind of internal framework. Instead I write libraries that solve specific problems and achieve code reuse, which are really either functions or data storage objects restricted to their own files. At least, that’s how I think about code universally, libraries, but specifically in the browser this comes up less because the problem space is much smaller. Really in the browser it’s all about organizing code around event handling and putting text on screen. Let’s not over think this. Anyways this idea of internal frameworks has always been weird to me. Nobody says this of code outside the browser, so why would they say this inside the browser? When I think about in those terms this clearly becomes a simple organizational problem and I don’t need a framework telling me how to organize things like a parent telling me to do chores. | | |
| ▲ | WA 6 hours ago | parent [-] | | What code are you using to reactively render state? Or do you write all DOM manipulations manually and just accept the problem of state explosion? | | |
| ▲ | austin-cheney 5 hours ago | parent [-] | | Here is an example: /lib/dashboard/dashboard_script.ts https://github.com/prettydiff/webserver When you aren’t using framework like components state restoration is a single function that runs only on page load. There is no state explosion and on localhost the SPA fully renders and finishes state restoration in about 105ms from http request. | | |
| ▲ | WA 3 hours ago | parent | next [-] | | Thanks, but this is a server-side thing and has nothing to do with client-side DOM manipulation?! Sure, you can put stuff on the server and do HTTP over the wire. It's oftentimes the better solution. But there are apps/tools that are rightfully an SPA (like tldraw or excalidraw for example) and can run local-first and offline in a browser. You build the entire app in JS and you'd need a bit more than vanilla Web components for that if you want to avoid client-side state explosion. | | | |
| ▲ | brazukadev 3 hours ago | parent | prev [-] | | Mate, if you are proud and happy to code this way, congratulations. That code is an absolute nightmare tho. Your eyes are trained on it so you think this is as good as an ergonomic framework. | | |
|
|
|
| |
| ▲ | WA 11 hours ago | parent | prev | next [-] | | 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. | | |
| ▲ | spankalee 2 hours ago | parent [-] | | There are plenty of web component helper libraries that give you reactivity. Reactivity is an implementation detail. |
| |
| ▲ | daveidol 14 hours ago | parent | prev | next [-] | | 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. | | |
| ▲ | zelphirkalt 7 hours ago | parent | next [-] | | Compare how many "complex applications" on the browser there are, with how many cargo culting blogs that employ react to render client side what could be static pages with text. | |
| ▲ | austin-cheney 13 hours ago | parent | prev | next [-] | | I disagree. It’s actually the same effort either way, but one of those costs substantially more to maintain and performs far slower. | | |
| ▲ | adastra22 12 hours ago | parent [-] | | It is not obvious to me which one you are talking about. | | |
| ▲ | austin-cheney 8 hours ago | parent [-] | | The framework solution will end up costing more over the life of your application due to artificial restrictions, leaky abstractions, extra dependencies, performance decreases, and more code to maintain. In most cases all of those are acceptable if the developers are less comfortable making original architectural decisions. For me that comfort is achieved through reuse and audits around data structure types through use of TypeScript. Now that ThpeScript is natively supported in Node it’s even faster still because there is no need for a build or compile step. The code just runs as is. This is also even true for code that executes only in the browser so long as it’s imported into a node module, which I do anyway to reduce the number of file requests into the browser. |
|
| |
| ▲ | netbioserror 13 hours ago | parent | prev [-] | | 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 12 hours ago | parent | next [-] | | 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 13 hours ago | parent | prev | next [-] | | Accessibility suffers with that approach. | | |
| ▲ | extra88 12 hours ago | parent [-] | | It doesn't just suffer it's impossible unless you recreate the whole thing with actual HTML behind the <canvas> rendered version. |
| |
| ▲ | zelphirkalt 7 hours ago | parent | prev [-] | | Don't forget about the privacy cost associated with the canvas. If this ever becomes widespread, we will have many many sites extract browser fingerprinting information from the canvas. It would then move the game one more step towards dystopia, where we have to analyze and block certain ways of code interacting with the canvas and it might even prove impossible. And then incapable web devs will offer you no solution but canvas buttons for the login to your bank account. No, I don't think this is the way forward. |
|
| |
| ▲ | afavour 12 hours ago | parent | prev | next [-] | | > 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. | | |
| ▲ | austin-cheney 8 hours ago | parent [-] | | Modern frameworks, really components and an API, solve only two business problems: division of labor and training. Knowing that you can address these problems with continuous integration around a common set of rules and requirements. With regard to application size we fortunately now have TypeScript. All you really need to scale any application is types, functions, and code reuse. |
| |
| ▲ | ahdanggit 13 hours ago | parent | prev [-] | | 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.) |
|
|
| ▲ | IceDane 10 hours ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | spankalee 9 hours ago | parent | next [-] | | 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? | |
| ▲ | JimDabell 9 hours ago | parent | prev | next [-] | | 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. | |
| ▲ | WickyNilliams 7 hours ago | parent | prev | next [-] | | I've worked in complex projects with web components. Works fine. Have you? | |
| ▲ | guappa 6 hours ago | parent | prev [-] | | Calling someone else boring because they disagree with you instantly makes me think they are right. |
|
|
| ▲ | FpUser 14 hours ago | parent | prev | next [-] |
| >"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 |
|
| ▲ | andrewmcwatters 17 hours ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | Xenoamorphous 10 hours ago | parent | next [-] | | Apart from classes -> hooks what big changes have happened? | |
| ▲ | rhet0rica 14 hours ago | parent | prev | next [-] | | https://i.imgur.com/7ITZb7d.jpeg Aren't web components a pain in the ass to use? | | |
| ▲ | prisenco 11 hours ago | parent | next [-] | | 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 13 hours ago | parent | prev [-] | | Nope Lit.dev | | |
| ▲ | brenainn 13 hours ago | parent [-] | | 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 11 hours ago | parent [-] | | >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. |
|
|
| |
| ▲ | echelon 13 hours ago | parent | prev [-] | | 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. | | |
| ▲ | komali2 7 hours ago | parent [-] | | Maybe they are, I can't speak for them but I've noticed that React hasn't been "reinvited every year" since maybe, 2019 or so, whenever we changed from functional components to class components and then back to functional with hooks. My feeling is that people who have been devving in react post-all-that-nonsense are living in the new world of a much more stable framework that does have new things coming in (Server Components or whatever) that you can just ignore, whereas there's those of us that had to learn this Hot New Framework, and then like a year later relearn how to use this Hot New Framework, and then a year later have to relearn AGAIN this Hot New Framework. It was the last time but for me at least I'm still scarred, and it reminds me of the way people talk about the move from Python 2 to Python 3: I existed well into Python 3 world so I was like, what is everyone complaining about? Upgrade and move on. But there was a time when the whole world was Python 2 and for a period of time half that world was broken. I imagine people get scarred from that kind of thing and carry that experience and distrust through the rest of their career. | | |
| ▲ | brazukadev 3 hours ago | parent [-] | | Are you saying that the recent changes wasn't a reinvention? React now looks like PHP ffs. |
|
|
|
|
| ▲ | jongjong 17 hours ago | parent | prev [-] |
| 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 17 hours ago | parent [-] | | > 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 14 hours ago | parent | next [-] | | 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 13 hours ago | parent | next [-] | | Neither can react | | | |
| ▲ | moron4hire 11 hours ago | parent | prev [-] | | 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. |
| |
| ▲ | sporritt 11 hours ago | parent | prev [-] | | 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 hours ago | parent [-] | | 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. |
|
|
|
