Introduction
In the ever-evolving landscape of web development, new technologies emerge regularly, challenging the status quo and redefining how we build web applications. One such challenger that has been making waves is Web Components, a set of web platform APIs that allows you to create reusable and encapsulated custom HTML elements. With the rise of Web Components, some developers are wondering if this could spell the end of React, one of the most popular JavaScript libraries for building user interfaces. In this article, we'll explore Web Components and their potential impact on React.
Understanding Web Components
Web Components are not a framework or library like React but rather a set of web standards that enable the creation of custom HTML elements with their own encapsulated JavaScript, CSS, and HTML templates. These components can be used just like native HTML elements, making them highly reusable and interoperable with other web technologies.
The Core Features of Web Components:
Custom Elements: You can define your own HTML elements with custom behavior and styling.
Shadow DOM: Encapsulates the component's styling and structure, preventing conflicts with the rest of the page's styles.
HTML Templates: Provides a mechanism for defining client-side templates that are not rendered when the page loads but can be instantiated later via JavaScript.
ES Modules: Allows you to package your components as modules, making it easy to share and import them into different projects.
React vs. Web Components
React has been a game-changer in web development, offering a declarative, component-based approach to building user interfaces. Developers have grown to love its features, such as the Virtual DOM, one-way data flow, and rich ecosystem of libraries and tools.
So, how do Web Components stack up against React, and could they potentially replace it?
Pros of Web Components:
Portability: Web Components are not tied to any specific framework or library. You can use them with React, Angular, Vue, or even plain JavaScript.
Encapsulation: Shadow DOM ensures that styles and structure within a Web Component are isolated from the rest of the page, reducing the chances of style conflicts.
Reusability: Web Components are designed to be reusable across projects and even between different web development ecosystems.
Browser Support: Most modern browsers support Web Components natively, reducing the need for additional dependencies.
Cons of Web Components:
Complexity: Developing complex Web Components can be more challenging than building similar functionality in React, which provides a more extensive framework and ecosystem.
Performance: React's Virtual DOM can offer superior performance optimizations in certain scenarios, although Web Components have made significant improvements in this area.
State Management: React offers robust state management solutions like Redux and Context API, while Web Components require more manual handling of state.
Conclusion
While Web Components offer an intriguing alternative for building web interfaces, they are not necessarily the end of React. The choice between the two depends on your specific project requirements and preferences.
React remains a powerful and popular choice for developing complex web applications with a rich ecosystem of libraries and tools. However, Web Components provide an exciting path to more portable, reusable, and encapsulated UI elements that can be used across different frameworks and platforms.
In practice, many developers are finding ways to leverage both technologies. For instance, you can embed Web Components within React applications or use React components within Web Components. This hybrid approach allows you to enjoy the benefits of both worlds.
In conclusion, the rise of Web Components does not spell the absolute end of React but rather offers developers more options and flexibility when choosing the right tools for their web development projects. As the web development landscape continues to evolve, it's essential to stay open to new technologies and adapt to the changing needs of the industry.
Top comments (19)
Svelte is what has already killed React. It simply is a matter of time before people notice.
The Why's
There is no way ReactJS, Angular or VueJS (the three strongest mainstreams) can compete against this.
I don't think those advantages are enough in the short term when weighed against the huge number of developers and projects in React. Not many people have projects that need them enough for it to be a black and white decision. Time will tell... Probably a lot of time.
You are right: React won't disappear anytime soon. What I mean is: It is impossible for ReactJS, VueJS and Angular to catch up with Svelte at this point in time. Just like jQuery is still found in 64% (as I read somewhere) of all websites worldwide, React will maintain its presence for a long time. What I mean to say is that continue to choose any of these mainstream frameworks for new development makes no sense. Sure, you could justify by the usual "ecosystem is so large", and "you can find qualified labor in React the most" reasons, but those start to feel like excuses now. Can you really say that an Angular/React developer cannot learn Svelte fast enough? I learned Svelte in 1 day. That's how amazing it is.
Then ecosystem? Many times is not needed. Floating UI "for Svelte" is not needed. Same thing for ChartJS. Same for many other libraries.
jQuery is still used because there are tones of libraries that use it behind the scenes and no one wants to re-code them from scratch not using it, plus it's still a heavy load in wordpress instances, no one is using jQuery for new developments, though.
Now, working @ a big company, you may have 800 frontend developers, 650 of them may be proficient in React and near half of these also in Next (or the learning curve may be around 1 to 2 weeks).
You get a fixed price project, what will you do? You just use React/Next.
Same applies for a not-so-big company with activity on high competitive market niches.
What matters is that the job gets done and that the end result is good enough. If you force these devs to work with something they don't have experience with the result won't be that good on the first product/s plus the users will not care about the tech stack used behind the scenes.
Coded very big apps using Next JS and a smart usage of the fine-tuned SSR capabilities along with a good architecture gives pretty good results in terms of performance, DX, UX and SEO.
As I said multiple times, performance is not usually a KPI, if it were the case we all probably might be coding in C++ instead. 🤷🏻♀️ it is what it is
Last but not least, the RAM usage on client side is also not -usually- a KPI because the app runs on the client's device, you're not paying for these resources and unless we're talking about ridiculous numbers it won't be a problem.
All of what you say makes sense. However, it cannot be generalized, as you are trying to imply. I am the living example: Intel employee moving the entire project under my watch from React to Svelte. Was this decision taken based on the novelty factors around Svelte? It was not. It was taken because my predecessor could not maintain code quality. The code base is so damaged that working on it is daunting and discouraging. This lowers my developers' morale and overall happiness score, which is in fact a metric monitored constantly sprint after sprint.
Just like me, there are people out there with similar needs. A need for drastic change. If I had never known Svelte, I would have probably recreated in React, or maybe given VueJS a try. I did come to know Svelte, though. It is fantastic with a minimal learning curve because it is basically JavaScript with a hue of flare.
I did some coding tests and code reduction is very real. In a non-trivial component, I was able to get a 44% code reduction when measured in lines of code, and the final result was evidently superior (animated component, thanks to Svelte's built-in functions).
Surely there will be developers that will underperform in a project or two due to the tech stack change, but I am willing to bet that in the very specific case of Svelte, this is minimal. It is far simpler to achieve the same thing that I find it hard to believe an average React developer can "screw up" to the point where they cannot finish the project with an equivalent (if not superior) quality. We are talking about a 1-day learning curve for Svelte 4, and Svelte 5 will have a simpler learning curve.
Completely agree! And the reason for it is explained in your own comment
Once you set in place KPIs like these it's way easier to switch stacks (if you have the budget of course) or whatever change that needs to happen to ensure a rise on these KPIs, it's not the reality for most companies (hence not for most employees), though.
It's always a good exercise to try and understand why things are the way they are IMHO.
Talking about Svelte it may take a huge leap if Next would publish a version using it as a replacement for React as they hired Rich Harris.
I just wish they could leverage SSR on Svelte to be as flexible and fine-tuned as it is with Next (Pages Directory) where you can choose your strategy at view level and not one strategy for the whole app.
The last paragraph is written from my knowledge of Svelte which may be outdated as I need to revisit it -it's in my list after a couple more-, last time I checked you need to build the app with the
--ssrflag and that was about it, similar to adding Angular-Universal to an Angular App, which applies 1 thing to the whole app.if I said something wrong please correct me so I can avoid the same mistake in the future, tanks 😁
Ha! I think you heard Sveltekit now can do per-page SSR. 😄 At least you felt it in your gut. Indeed, your SSR information is outdated. Sveltekit apps even have page preloading as your mouse comes closer to a link that changes pages.
As for having "budget" to make the switch: I truly believe this is a bugdet-saving move, not the other way around. As stated, code reduction should positively impact sprint speed and therefore budget.
Thanks a lot for the information! Much appreciated, truly!
I should move Svelte forward in my "Revisit" list then 😋
@webjose If you're replacing the technology due to code quality, it is like poorly designing a monolith, then reasoning that by splitting it into micro parts will solve the problem. If the 'code quality' issue is not dealt with, guess what will happen in some months / years?
You can also decouple thingies within a monolith and couple them when coding services.
E.g. you can code an API-first monolith and convert it to microservices right when you really need it and to the extent that your app really needs, which turns to be hugely advantageous in terms of reducing costs.
Cheers!
I really like Svelte, but I am not sure if it will ever overtake React in terms of market share, even for new projects.
Based on the statistics from State of JS and CSS, Svelte's 2x% usage is quite disappointing compared to Tailwind's 4x%.
Short-sighted kid still underrated React :))
Keep hyping and good luck.
Wow, so compelling LOGICAL reasoning. I'm blown away by your mastery of the English language.
wow, I haven't seen about it yet, it seems interesting but I don't think React will die, for now it has a lot of strength, we'll see over time
As react/nextjs developer I also agree the react solution is a littlebit owerweighted at many cases. But in my readings, Web Component is just a new HTML possibilities used by
<template>and<slot>tag. So this is also can created by React or any other framework, which is able to render HTML.By the way my vote is on
qwikorhtmx, if I focused on application speed.Maybe the best way for Web Component to defined by htmx that is lead to create really usefull Web Component without leaving HTML
Web Component, multiselect example:
-- check this react state handling module : react-state-factory , join to develop as opensource module under hacktober --
Very nice! I see something in the middle: including web components in react applications. This is what WebCrumbs aims to achieve (more about it here).
From what I observe on the industry on how Angular was taken over by React as the most popular frontend framework, generally, companies will tend to stick to what's already popular (as they can easily hire and, pick & choose devs with that skill already so less time training them), except that already popular framework mess up or does something not so ideal, then, the shift slowly moves to the next best option that either does almost the exact same thing or does it better.
If something has to replace React, then that something better wait for React to mess up (like what Angular did before) or do something WAY MUCH BETTER (like the jQuery to Angular shift).
AI article be AI
Stop trying to make web components happen.