More accurately, I’m over everyone treating it like the only answer.
I'm a devout supporter of Web Components and have been preaching the gospel of web standards for decades. That guy you always hear muttering "Why use a library when the browser gives you everything you need?"
I have lived through five versions of HTML (2,3,4,XHTML,5) and watched as libraries like jQuery and frameworks like Angular have come and gone from the spotlight. And I'm here now to tell you that you never NEEDED any of them and this has never been more true than it is today.
Custom Elements, Shadow DOM, HTML Templates. These tools provide everything we need to build robust, modern components without relying on heavy abstractions. But still, in 2025, the web development world clings tightly to libraries like React.
The Standard Approach
I'll admit that React played a huge role in shaping modern front-end development. Its component model, reactive updates, and rich ecosystem were groundbreaking when they emerged. But React’s reliance on third-party extensions like JSX, its synthetic event system, performance overhead, and tendency to blur styling and logic inside components all fall short of the standards set for the web.
Web Components — by contrast — are a core part of the web standards, embrace the browser’s strengths, benefit from baked in optimizations, and promote separation of concerns. All without the need for build pipelines or runtime libraries. You’re working with the platform, not against it.
Universal by Design
Perhaps the most underappreciated strength of Web Components is their inherent interoperability. Build a standards-compliant component, and you can drop it into any toolkit. Whether you’re using Vue, Svelte, whatever the flavor-of-the-year framework is, or just static HTML, Web Components fit right in.
With React, moving components between frameworks often means rewrites, dependency tangles, and awkward integration. Why lock your work into a single ecosystem when the browser already provides a universal language? And don't even get me started on stateful rendering in an environment that was intentionally designed to be stateless.
Well designed Custom Elements can be used completely declaratively, blend seamlessly into Server Side Rendering, can be styled through standard CSS, are naturally encapsulated, and the list of capabilities goes on and on and on...
The State of Things
I’m not here to say React is evil or useless. It’s a mature, powerful tool with plenty of successful projects under its belt. But in 2025, when developers continue to reach for it by default, that seems more like a bad habit — a reflex that hasn’t caught up to the evolution of the platform.
For those of us who’ve been building with Web Components for years, the continued use of vendor-specific solutions feels increasingly out of sync with the realities of the web platform. Most of the problems that React once solved have been addressed at the platform level long ago. Web Components have been mature for years. It's time to stop solving today's problems with yesterday’s tools. Imagine if we never stopped using tables for layout just because "That's how we've always done it".
Building for The Future
Obviously we all use the tools we know and trust. But sometimes we need to challenge ourselves to re-examine whether those tools are still the best fit for today’s (and tomorrow’s) needs. That's exactly why the standards exist and continue to evolve. And exactly why I will stick with them as I always have. Because one day, React will fade into obscurity just like jQuery while Web Components will live on as long as the web itself.
Top comments (122)
Not sure about this homie... you might, for example, add an example. Here is a data table component with back and frontend pagination/filter/sorting/search built in web components vs. React. Then you could prove your thesis rather than just stating opinion. One should remain objective when analyzing architectures. I built all this stuff 100 times before react existed, and 100 times after, I still use react ATM but open to be convinced that another is better.
It's not better, it's something completely different. Web components are isolated units that are not designed to be managed by some app wide state manager like in React, although you can certainly do that and there are frameworks out there who make it easier, like atomicojs for example. Web components are all about isolation and reusability. Consider them as independently published building blocks, that you can use inside a bigger application where you'd use them the same way you're using
divorinputright now.Exactly. Or just build your own component library. The point is that they can be used just like native HTML Elements. They blend seamlessly into the fabric of the web.
That is basically the point of React, reactive components. Same with angular really. I do agree though, generally if you 'need' a framework to program than your language sucks... and JS and HTML has sucked. Problem with react, its strict on component composition and most devs get it entirely wrong so they fall back on global states and useMemo, which becomes unmaintainable fast. But if you focus on component composition and 'lifting state' to the lowest needed level, it basically guarantees optimized renders if you do it correct. TS helps to achieve it in react. Angular is more open and less strict, easier to achieve but harder to enforce. Web components does sound like a potential replacement, like silverlight vs. HTML5 canvas, which would be ideal... but if it can't replace a framework we all find critical, I don't know if I'll use it or for what.
The only optimized rendering is that which is done by the browser itself through compositing. Every DOM update is expensive. React components are notorious for causing unnecessary re-renders of the entire component for a small change in state. Add to that the Virtual DOM and now you have added significant performance overhead.
By contrast, an efficiently designed custom element would update only the single part of itself that needs to be changed. If positional changes are handled via transforms only then there are no modifications made to the DOM at all and you enter the realm of true rendering optimization.
Not sure what you guys are building, maybe video games, but I've never had any issues with render speed in react unless the architecture is horrendous. A component will only rerender in react when it's props change, or it's parent changes. What often happens is devs fail to use proper component composition (I.e. children prop) so that the component hierarchy actually matches the intended rendering tree. Some devs rely entirely on global state, they've already lost usually when they do that. Often apps aren't built asynchronous properly, that also hurts in react. Generally only the user object and constants should be global in my react apps, I.e. when the user changes, that's the only time everything should rerender generally. When you do that, no reason you can't make a react component with zero props, so it only rerenders itself... the challenge for the architect is finding which layer in which to use each strategy. But when done right, man react just purrs.
Yes games, that is one good example where rendering performance is crucial. But really, any animation heavy UI elements. Here is one example that animates an SVG image, and another which manipulates a clip-path, or if you would like to see a more complete example, here's a full app demo built completely from web components.
But anything like that I would traditionally use the canvas and math, which has zero to do with react which could onky be a wrapper at most. I can't see the code for your demo site, or I'm missing it, but I'm getting the impression your doing that without the canvas. Css animation I think is cheap in react, but yeah I could see js based animations in a component, constantly resetting state, would be costly. I've used three.js I'm angular and react before no issues I recall, but its all canvas. Basically was a parts drill down gui, ordering, maintenance procures, etc. Funny though I tell you, I have seen some pretty basic react apps that should be fast, hose to hell, more often than not. Angular and most other frameworks are harder to screw up. And react and libs have responded in ways that discourage proper react. In the end, you need components... can call it a producer, provider, factory whatever... the rest is really just the vendors implementation preferences.
view-source:https://bes.works/bits/or Ctrl+uThat's right, there is no canvas involved. Here's a much more advanced example. This app was built entirely from custom elements and involves a significant amount of complex state handling and rendering optimizations in tandem.
erm apologie @gunslingor but React isn't reactive... at least out the box.
You would need to use something like MobX
Really? A state manager that follows mutability pattern suddenly changes something about the reactivity of React? I think what you mean to say is React follows a different rendering strategy with the vdom, instead of the signals based fine-grained dom updates that something like SolidJS uses. The effect is the same though, you only update the dom nodes that actually changed. React just has an extra step to calculate what changed.
Btw mutability (mobx/valtio) is an anti-pattern in functional programming.
Yeah interesting views... maybe explain them to the React team?
legacy.reactjs.org/docs/design-pri...
and they only exposes a mutable interface to the developer...
yikes.
Reactive Programming is just an esoteric term that attempts to redefine something that doesn't need to be redefined. JS is event-driven by nature and always has been. When using React you actually reduce reactivity by inverting this model. Not only this but you break the promise of asynchronicity and have to jump through hoops to get it back. Why even bother?
Every DOM Node and many other objects derive from EventTarget which means that they can receive and emit events. You can also easily create your own objects that extend EventTarget, and with EventSource or Web Sockets you can even listen for server generated events. All the reactivity you should ever need is baked right into the language.
I don't need to explain anything to the React team, however you could benefit greatly from understanding what mutability is, so in the future you might understand that it doesn't change anything about the rendering strategy of React.
Ah ok I went and learnt mutability is it something like this?
immerjs.github.io/immer/
the rendering strategy or react? it only has one strategy ever internally.
Good thing JS isn't a rigid functional language. It's a dynamic, multi-paradigm language, just like the web itself. Mutability is a core feature not something to shy away from. It's essential to creating a rich, interactive user experience.
If you need immutability you absolutely can accomplish that in various ways. The most obvious being the
constkeyword but also through use of private properties or getters without setters orObject.freeze.Having the power to dynamically change almost anything comes with the responsibility to understand how the browser handles reflow and repaint. React's Virtual DOM is their way of batching updates. The standard way to accomplish this is by using a DocumentFragment.
Don't worry, I will be writing more articles on this subject. However, in this one I linked to a page with dozens of examples of components that I have built. Feel free to view the source of any one of them to see how a well designed custom element should be structured.
Took a look. Need that intro and code 🙃. I would love it if these frameworks vanished overnight for native language features... I really kinda miss the days before even git was a thing, lol, I'm old.
I'm not a react expert, but I've used it. I don't think it's worth new coders learning, because there are much better solutions to the problems it solves now, and a lot of it appears to be baggage solving problems that no longer exist.
I agree. The problems React once solved are no longer problems. At this stage it just adds complexity that is not necessary.
I think you're wrong, why wouldn't every new developer learn it? is the most used framework and can open many more doors than any other one. Not using it is not easier, in my opinion.
New web developers should be learning JavaScript fundamentals not filling their head with ideas that do not align with the web standards. One should choose a library or framework based on experience and need. Otherwise it's like trying to build a pyramid upside down, eventually the weight of language will topple their fragile framework-based understanding. Better to start with a strong foundation.
I agree, and then, learn React because it will open a lot of doors for them.
Are there really opportunities for inexperienced devs in the React ecosystem? Why would a company hire a brand new dev who just learned React when the market is already saturated with those who have been using it for years? Better to learn something new and fresh and be poised to take advantage of the inevitable shift in the landscape.
inevitable shift? React has been the go to library for a long time and since the beginning people have been saying that it won't last long. People WILL hire a junior dev that knows React over one that doesn't, React teams will hire junior devs and someone that already knows react will have a door open, what are you talking about?
React's popularity has been in steady decline for several years.
It still holds a significant market share but... people also still use jQuery in 2025.
So will React ever disappear completely? No.
Is it worth learning today? That's debatable.
Is it the only option? Absolutely not!
To be fair, that crop is a little misleading. The full graph shows it better, but even so it's a terrible graphic in terms of conveying information to the user!
The thing it ends up showing is that React has an overall more positive opinion from actual users than any other framework it's competing with. The site you link to also states in the accompanying blurb that this is the common pattern for frameworks, so it's not really behaving any differently to others, it was just more popular to start with.
That being said, I'll work on legacy React projects but I will not start any new ones by choice.
Yes, a common pattern that was exactly the point. All the graph shows is that a lot of people have used React and that its popularity took a nosedive right around when web components started stabilizing. The other links further illustrate this pattern as predictable.
React did to web dev the exact same thing that Facebook itself did to the web. It attracted the average person. But just because a few billion jump on a bandwagon doesn't mean they have any idea where that wagon has been or where it is going.
The majority of Facebook users don't know anything about the nature of the web as a whole, and an alarming number of React users don't know anything about the platform it's built on. They simply accept their narrow spoon-fed viewpoint as axiomatic.
Zuck recently admitted that Facebook no longer really serves its original purpose. Many of its original users abandoned it long ago. React seems to be heading in the same direction. For anyone who has been watching the trends since the beginning, this is entirely expected.
you're living in the clouds mate, ANY developer should know React, and any dev should learn it first.
And I have an excellent aerial view of the landscape from up here. The fact of the matter is that many React users don't want to use it, they do so because they have to.
I don't expect to sway any of that segment who do want to use it. Just as I don't expect die-hard Windows fans to jump ship for Linux. If you're happy with React, then by all means continue using it. But don't try and pretend that it is the best simply because it has the highest body count.
Telling beginners to learn React first is like pointing them at a forklift when they don’t even know how to drive a car. Sure there’s some overlap, but it’s heavy, specialized, and won’t teach them the everyday skills they need to maneuver in traffic.
React is required in 80% of the positions I'm applying to when I look for a job, period.
I know. And I'm sick of it. Especially when some hiring manager with no clue about how the web actually works tries to imply that I am somehow less knowledgeable about web development for not wanting to use React.
The thing is though, the vast majority of jobs that insist on using it are not ones that I would even want to get involved with anyway. But the real problem is that companies just assume that the most popular option always equates to the best option. So it ends up being a requirement even for jobs where it completely over-complicates the scope.
And because of this mentality, experts on web standards are being squeezed out of our own industry in favor of juniors straight out of code bootcamps. Where will that leave the web in 10 years? And what will all these React only devs do when the bubble pops? 🤷
The only way I can see to fix this is to keep building a better web, one component and changed mind at a time. We as developers need to stand up for the standards and show companies how they can enable us to build better apps faster and easier without all the extra baggage.
However, we can't do it with rhetoric, we need real results. I'm doing my part, but I'm only one guy and I'm sure that I'm not the only one struggling in this economy. If I had the backing I could train an army of standards-first developers. I have the skills, knowledge and voice to do so. But instead, as a standards-only freelancer, I'm stuck competing with my peers over scraps. So, if anyone would like to collaborate on changing the world, please let me know.
I have been using web components since 2018 and since 2022 currently working on a high profile project at work using web components. I was told by other developers I should use react. Turns out using web components was the best decision I made. Someone tried to poach my project by building it in react but nobody can match the speed, loading time and the low file size of the whole project. There is no updating npm dependencies, updating frameworks and migrations etc. We have established design patterns and have not needed to do anything different. We use all kinds of web components libraries and we can mix them no problem. It's so easy to work with, super easy to debug. It stinks because there aren't many or any companies using it, but there also isn't a lot of proper documentation to solve and offer corporate solutions. The downside is the learning curve for web components, you really need to understand JavaScript. Hiring becomes hard because there are just a bunch of react developers and not JavaScript developers. As this trend continues we have no choice but to know react to get jobs with the majority. At least I can say from experience of having done both, web components was amazing and a missed opportunity for blazing fast development.
Thank you for sharing your experience! This is the kind of thing I want to draw attention to.
This is a crucial point. Many framework-centric developers simply do not fully understand the underlying platform. My goal here is to share deep understanding of these misunderstood tools.
y'know what I wanna know? How to write profiles to hire devs that know web components (and I don't mean "has written a lit hello world app"). Like, with react I can write "5y exp. with react, react hooks, etc". What do I write for CEs? "5y HTML exp"? Then I'll get someone who still recreates the <details> element and such...
As much as I hate it, I think the web platform needs some sort of bullshit bingo :/
I think there are two key phrases that would be ideal to use:
This will likely scare away the average framework-centric dev. You could quiz the rest to be sure. And I don't mean a written or multiple choice test. Just a simple live conversation about the standards. If they don't have even a rough idea off the top of their head then they definitely don't have the deep experience you are looking for.
Or you could just reach out to me and we can discuss your project. I am available for work right now if you need help.
Dude I wanna learn more on how you do it. I'm a react user but web components impress me so much. How do I convert?
Stay tuned for more articles on this subject including tutorials. I intend to write about everything from the basics of how to get started, to advanced techniques that I have both learned and invented, to building fully functional web applications entirely from web components.
Web components solve a few of react's issues while introducing a lot of their own. However, any of those issues only arise if it matters in the context of your usage.
If your use case fits web components perfectly, congratulations! But what is great in your case might not work for everyone else (the same is true about frameworks, too).
React is overused because a lot of developers can use it, so HR can select from a larger pool and hires can more easily be replaced.
Indeed, and it's a self-perpetuating problem. Because after years of this behavior breaking out of the React ecosystem becomes a business crippling problem. Companies are heavily invested and locked into the React stack for existing implementations. Obviously I don't expect every existing React based app to be replaced. But any opportunity to get away from it should be seized and new projects started now should adhere to the standards. Doing so will eliminate this issue from future endeavors. It's simply a better business decision in the log run.
Of course Web Components alone are not a panacea. Switching to them will certainly require architectural changes. But most of those changes lead to simpler, more maintainable systems. There is nothing truly new or exotic about their use. They just extend the old ways to be more flexible. All the problems that will arise from ditching React have well accepted best practices for dealing with them. There is no need to re-invent the wheel. And adhering to standards does not mean avoiding frameworks, there are already players in this space and surely more to come.
There is lit, which fixes a few of TFW issues with WC. Whether the other issues become a show stopper depends on the use case. WC are certainly not a silver bullet.
I would like to see web components being used more for design systems, but I understand why most companies don't. They have a bunch of "x framework devs" employed, so it's just easier to do everything in "x framework".
Hopefully it'll get better now that React has support for web components 🥳
This is a really great point. Often I've seen people do hiring without even talking to the team about needed skills. "We're hiring a front-end developer". Nothing more specific, and entirely vague. Sure, if the project uses a specific framework, anyone can learn it, but there's a lot of ramp up time there, let alone learning the application logic itself. Sometimes someone with skill in only a different framework has been brought on board, and it was a nightmare as they tried to import all sorts of patterns and practices that didn't even make sense in the current framework. But frameworks aside, I like your idea about hiring people just to make custom web components - in the past I've even taken it a step further. I'm far better at programming than I am with design, and I'd be totally on board with a CSS wizard being hired, even if the person doesn't have strong programming skills.
But it seems that there's a disconnect between what skills a team needs, and project managers' desire to throw more developers at a project, regardless of skill set.
This is something that always bothered me. Non-technical policy makers controlling the technical landscape through anti-progressive decisions whether intentionally or not. One cannot measure a product's true worth by market share alone.
React and web components answer slightly different questions. There certainly has been some blurring of lines over the years.
I'd agree that there is merit in creating reusable gui elements as web components to allow them to work everywhere but I struggle to see any real benefit beyond that.
I really liked web components when they were new and even built a few polymer apps but I just found myself using them less and less and they weren't that useful in practice.
👎 You still need JS to load the components
🎯 DSD - Declaractive shadowDOM creates Components without JS
👎Encapsulation of app logic is a nono, leading to more complex pages (and more prop drilling).
🎯 Its just POJ (plain old javascript) add any state management library you need
👎With the shadow dom you can't, easily, style from outside leading to multiple variants of the same component.
🎯 RTFM:
Thanks for your response but none of these really answer my concerns.
Declaractive shadowDOM is no better than just using HTML, you can't have any interactivity, why add the complexity?
The just use JS argument is a little odd, as you can just use React, Preact, Angular or whatever you like, why add the complexity?
Your response to the styling from outside is complex is here are the complex methods you can use to style it from outside.
Whilst I don't have an issue with web components they rarely seem worth the effort (even if they effort really isn't that great).
Encapsulation.
Shadow DOM is not at all required but solves a litany of issues that have plagued the web for years. Personally I think div soup is disgusting and CSS frameworks like bootstrap and it's derivatives were a step backwards.
External styling does not need to be complicated. When designed properly, a Custom Element is just as easy to style as any native element. With CSS you can target the custom element and it's slotted descendants just like any built in element.
And within your Shadow DOM you can modify internal styles based on the state of the
:host.It's simple, elegant and effective.
Actually, that is not entirely true. You can create custom elements through markup and css alone. They will not have any complex logic but JS is not technically required.
Then don't encapsulate your app logic. The point of components is to abstract and encapsulate the parts of your app that should be kept separate. You are building your app on top of the components—using them. Each component should only be responsible for it's specific behavior.
A properly designed app built from web components is actually less complex. The extra complexity generally associated with web components is almost always a byproduct of using them wrong.
But this is exactly the point of Shadow DOM. To encapsulate your styles away from the host page so that they don't get clobbered by page's CSS or that of another library or component. A properly designed custom element has only bare-bones structure and styling similar to that of a native element that can overridden by standard CSS.
I jest I truly didn't know how far creating components without JS had come but I still don't think it's good enough, I'd much rather just have raw HTML/CSS.
You could imagine having a component that loads in some data, having a loading state until the data is loaded, show the data and then allows you to modify the data again with a loading state as it saves.
This component doesn't need separating as it's all one concern, the form data (or whatever), but to make this work with web components I'd have to jump through some hoops, again not the end of the world but it feels like an extra layer of complexity.
OK, that feels like the answer of someone that doesn't have to work in teams of varying skill very often but perhaps it really is that simple 😊
A properly designed app built with CSS in mind doesn't need styles encap.... 😀
I personally use CSS modules to prevent clashes but I know that means a build step which you might want to avoid
I should probably say I'm not again web components and think everything has its place and every dev has their preferred way of working. For me the simplicity of react handling state and handling render based on that state allows me to work quicker without having to worry about all that. Sure there are foot gun and misuses of the platform but I'm sure that's true with all app building methodology.
Using Custom Elements in your project actually helps in a team of varying skill. Because someone with the knowledge to solve a particular problem can do so and share that with the team in the form of an easy to use component. The user of the component only needs to know basic HTML and CSS.
Encapsulation is important because not all apps are built in a homogeneous ecosystem. Polluting the global scope has long since been considered a bad practice in the JS world. Shadow DOM further enforces this and extends the ability to CSS to ensure that third-party libraries or even the work of your own team don't clash. Sure this can be mitigated with careful CSS scoping but you can never be guaranteed that your nicely designed widget won't break some day because of careless changes outside of your control. Why risk it when this problem can be completely avoided?
As for your bullet about prop drilling, I was thinking that you could still make web components that use some sort of state management - just not a State Management library tied to a specific framework like Angular's NgRx. However, at that point you have undermined the portability promise. I suppose you could make plenty of reusable components not tied to such a library (like your own input component or color picker, etc), but if you're using web components to make pages, those would have to be tied to app logic and would not be reusable across other apps and even frameworks. Basically the primitive components would be reusable, but the app specific ones would not.
Point being, you could probably avoid using a framework and use popular patterns found in various frameworks such as dependency, injection, State Management, services, etc - but you would have to be careful to separate your portable web components from the project-specific ones.
Exactly, state management is a job for the app itself not the components it's built from. You don't expect a form field to manage it's own state beyond the specific features that it provides. You wrap extra logic around it to suit your specific use case then you wrap an app around that. Simple separation of concerns.
React is a state management library that happens to be able to supply dom elements (with react dom) I think you're more fight against bad react usage rather than react as a whole.
Actually, I would argue against any bad usage of web technologies regardless of the library or framework involved. The core Web APIs provide a finely-tuned, meticulously-documented, consensus-based framework without the need for any additional libraries.
Browsers are perfectly capable of maintaining state through Session Storage, Local Storage, IndexedDB, cookies, bfcache, and service workers (anything I missed?) each with their own specific use cases. And because of the open nature of the web you can NEVER trust the client anyway, so the one and only true state should be that held by the server itself. With Web Sockets this can be synced in real time to the client. I don't see why a third-party state management solution would ever be necessary.
100% you can use what ever you want to handle state but it raises the question what wins do the effort of using web components (as opposed to just straight up HTML) get you.
Custom Elements === HTML Elements
That is the true benefit. They are not opposed to straight up HTML they are a direct extension of it.
I got into a week long fight with a guy on another team over this. He really wanted me to adopt angular but it was not even 1.0 yet. (Imho it didn't even get usable until 3, and even then just barely.) I told him
a. my team knew what they were doing,
b. We could do anything angular could do with just standard web tech (and proved it often).
c. It was adding a layer of complexity that was just too confusing for my team.
I trialed it on a simple project and it failed miserably. It took us less time to rip it out and do it "manually" than it did to get angular up with basic functionality. Even when it was working, we had to shim a bunch of stuff to fix the bugs in angular.
I've always been a proponent of KISS and I enjoy using the raw web to get shit done. (I do use vue and svelte from time to time because they are setup like web components. Also cuz of my job.)
I remember web components from the old ie6 days, Firefox had them as well, but not standardised, nothing like they are now, time for a revisit, I’ve been sick of react for a long time. This seems like a good way to go, what’s your thoughts on Lit?
I mentioned Lit in another reply. For me it's an an abstraction layer that I don't need, but it definitely would be a good place to take your first steps into the world of Custom Elements if you're coming from React. You'll find similar syntax and concepts as well as excellent tutorials.
There's also a solid library of components called Shoelace that's based on Lit which you can load via CDN. This would give you a good set of starter elements to work with if you don't feel like building your own toolkit from scratch.
You seems to be an old school developer, with rich experience which is rare nowadays, same here!
But let's agree that writing codes in declarative way is much better than imperative way.
The idea is everyday we see a new libraries doing magical things in the front stack, for example form validation, scroll behavior, even library for pagination here I would say 🛑 STOP it's too much abstractions go native even if you will spend some more time writing codes, not every problem need npm install.
I agree. As a component creator I aim to design interfaces that can easily be used in a declarative way. Both for my own benefit and for anyone maintaining my work later.
I do not agree. Abstractions are good. All code is abstraction. Web Components are great because you only ever need to solve a problem once. Then you can re-use that component any time you need it.
The content becomes decoupled from it's components. You describe the parts of the page in pure HTML and implement the logic in an abstracted way. If you want to populate the content server-side, that's no problem. If you want to change the behavior, all the code is encapsulated into modules. You can drop a component into a simple test page with no framework or build steps required to work on it.
You still need back-end validation but additional front-end form validation makes for a better user experience, especially when added to a custom form field.
Modifying scroll behavior is certainly not something you would want to do on a typical informational website but it can create a much more immersive app-like experience. Check out the source of that page to see how abstracting this behavior can be done in a clean and elegant way.
Pagination is actually a unique scenario. It's definitely easier to implement server-side, but you could absolutely package the behavior into a re-usable component. Something like this:
In this example, you would populate the initial content and attributes in a server-side render. The page navigation would be part of the Shadow DOM just like how a
<video>element adds it's own controls that are not part of your markup. This would allow you to declare your content and the component handles the heavy lifting. If you ever want to improve or even replace your component, it becomes a simple drop-in, plug-and-play change that automatically affects all instances.I'm no expert, but experts like Ryan Carniato (creator of SolidJS) disagrees with your conclusion.
Web Components Are Not the Future
Ryan Carniato ・ Sep 26 '24
Furthermore, it is the general consensus that declarative programming is better than imperative programming, and this is why frameworks and libraries like React, SolidJS, Svelte, Vue, etc. spring to life.
I am aware of the opinions of framework creators on this subject and I have not seen a single argument that has swayed my own opinion. Nothing about Web Components precludes you from using a framework. The choice to use one is completely a matter of preference and suitability for the current project. Most examples of "why Web Components are bad" usually boil down to not using them to their full potential or using them to solve problems they were never intended to solve.
I don't get your point about declarative vs imperative. As I mentioned in the article, Custom Elements can be used completely declaratively. Furthermore, there is nothing imperative about their use at all. They are not required in any way but are simply a tool to make Web Development easier.
The real problem I was trying to point out is that companies treat React as imperative. Like nothing else could do the job. Which is simply not true. The same kind of sentiments existed about jQuery. It was almost impossible to convince an execubot that a web app could be built without it, even though plenty of developers did so every day. And look how that went in the long run.
We must look to the past to design the future. And the past has shown us the same patterns over and over again. It would be crazy to dismiss this knowledge. The Web Components standard wasn't haphazardly designed. It was carefully forged to provide maximum benefit with minimal disruption. No one is forcing you or anyone to change their habits, but true growth requires stepping out of your comfort zone to explore alternatives.
Many truths indeed. Product owners at companies are obsessed with React or Angular, and while they usually pull "popularity", they always shield behind "they are backed by Meta and Google". Like throwing money is all that is ever needed.
So Yes!, I fully agree that people need to see that money and popularity are not the fundamental base conditions for frameworks/libraries to achieve, and instead they should be the consequences of the really important features.
As for web components, like I said, I'm no expert. I wanted to share the fact that people that I regard as "experts" contrary the conclusion of this article. More than that, I cannot debate. I have never done web components myself.
I do agree, though, that web components can use frameworks, merely because I know Svelte can produce web components. Still, as much as I LOVE Svelte, I have never done a web component, not even for "fun". So once, more, I defer to the experts here.
Cheers.
Thank you for engaging on this topic. You are exactly the kind of audience I am trying to reach. Experienced developers who may not have given Web Components a chance due to negative opinions about them. I would encourage you to give them a try, see what all the fuss is all about, and draw your own conclusions.
No opinion here, but I think you misunderstood what declarative vs imperative programming means, judging by this comment:
Imperative programming means you write the specific instructions and hope that the code produces the expected outcome.
Declarative programming means you declare the desired result and the code interpreter takes the required steps to achieve that result.
This guy explains it really well:
stackoverflow.com/questions/178466...
Most frameworks including web components are considered mostly declarative. That is, they allow you to stick very close to the language/words that make sense for your business logic, which is one of the advantages of declarative vs imperative.
I think he just meant "imperative" by itself - not "imperative programming".
imperative:
adjective: of vital importance; crucial.
noun: an essential or urgent thing.
That's exactly what I meant. Companies treat React as an essential tool with no alternatives.
But to address the programming styles. A properly designed web component is coded imperatively and used declaratively. The core functionality is abstracted away. You can modify the behavior or even replace the component entirely without altering the implementation.
It is not general consensus that declarative is better than imperative. At best, you have a vocal subset that FEEL that declarative is better than imperative. That nuanced distinction is why there are always escape hatches in any of the "declarative" frameworks. At some point you have to stop describing the work and actually DO the work. That's either in YOUR code, or it's in the framework code, and often times it's strewn throughout both.
React started by Declaring the UI given your state. Today it's more common to Declare your data management given your actions (UI being a derivative of both with cross cutting concerns)
Frameworks implement some functionality meant to set up a particular mental model, ease some tasks, and produce things of value. They do this at the cost of overhead, abstraction, and impedance mismatch when you need to do something that doesn't neatly fit into the provided abstractions.
React in particular has a history of slowing teams down compared to using native JS and HTML. I die a little inside every time I see a basic crud application loading a large js-bundle just to have to reimplement the browser's navigation on order to avoid a page load. The performance ends up measurably worse and business logic leaks into the frontend. I've made a reputation for coming into projects that are wildly off track in terms of time and budget, and getting them back on schedule by ditching react and having the team reimplement the UI from scratch in a basic server-side rendered library. I've done it several times and every time it has resulted in significant time savings and simpler implementations. KISS applies to the WHOLE stack
Ryan creates Solid, Rich creates Svelte
All Cool-Framework-Authors dislike what the WHATWG (Apple, Google, Microsoft, Mozilla) comes up with.
And they are absolutely free to do so. That's the best part of the web! It just bothers me when a third-party's idea of what's best takes precedence over the consensus of those who built and maintain the platform.
Solid, Svelte and all the other cool frameworks each have their following. If a dev or team chooses to use one of them you can be pretty sure they at least did some research and made a decision based on perceived value. But when there's mass adoption of a framework like React simply because it's the biggest name on the list, that creates a snowball effect that hurts everybody.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.