Cover image for It is ⌚time to ditch ReactJS or Angular and use better web standards like web components😍 part 1

It is ⌚time to ditch ReactJS or Angular and use better web standards like web components😍 part 1

lampewebdev profile image Michael "lampe" Lazarski ・5 min read

By 2019 we all agree that components are the way to build fast, elegant and maintainable UI's. The problem is that every framework, like ReactJs, Angular(JS), VueJs, or some other smaller UI framework, uses its own patterns and solutions to common issues. These frameworks promote reusability and that they are easy to use. Also, one point I hear often is that they are mostly backed by big companies, like Google or Facebook. Let's have a discussion if this is really true, if maybe the community could do better and if there perhaps is a better alternative.

Web development is in a unique position. Web site, Web Applications, PWA's or whatever you want to call them are running in a browser, and in the end, it is all HTML, CSS, and Javascript ( and maybe Web Assembly). The goal then should be to use these tools most proficiently possible. I don't mean by that to use all of them without any kind of library or framework. You should use them, but what happens if we have too many to choose from? Overchoice happens! You are paralyzed because you have too much to chose from. Instead of being fast, you are slow because you don't know what frontend UI library to go with.

Alt Text

Okay, you now think: "I will go with reactjs every time.". This can be one solution. It can be a perfectly fine solution but still Angular, and the other UI frameworks still exist. This means that instead of working together as a community, we are fragmenting ourselves into these small communities. It gets even worse when you look that most of these tools are lacking features that we use daily. Routing in ReactJS is not fun at all. Form validation is also not fun and something nobody wants to do. So people need to create libs again for these UI frameworks, and there are most of the time like 2 or 3 libs to do these things. Not only we split our efforts into these groups of UI frameworks in these groups, but we also cut our efforts again to reinvent the wheel. Just think about the working hours we as a community have wasted here?

I can see people now think, but this is a good thing! Is it really? Please google: "Year of the Linux desktop.". Desktop Linux has the same problem. Gnome, KDE, XFCE, Cinnamon, Mate, LXDE, and man more. They all try to solve one thing: Make Linux better on the Desktop. Are they succeeding? You tell me down below in the comments.

Alt Text

Next point is reusability. Does someone remember the jump from Angular 1 to Angular 2? Yeah, it was like a completely different framework. Now we have Angular, and AngularJS which is not confusing at all. You now think, "but wait! Reactjs does not have breaking changes". You are right; they had no implicit changes like react v1 and react v2! I dare you to try to post react code where you are not using hooks! Half of the comments will be about "why are you not using hooks???". The same happened when you had to rewrite your react code from class-based components to function based components. Now I ask you a question where you have to be honest to your self and take down the "I'm a developer hat and want to use the new fancy shit" and put on the "I want to solve real problems and give people solutions they really need.". Did any of these changes really give any value to your customers? To your users? To your business? Is your code really now more comfortable to read? If you are really honest to yourself, then you would probably still be happy with class-based components. I think we can now say that maybe we have been tricked by marketing?

Wait, what? What has marketing to do with this? See people tend to forget. Who created ReactJS? Facebook, and who created AngularJS? Google. What are these companies known for? If you now say a social network and internet search then again you have the wrong hat on! They are known for advertising and marketing! If you want to know what a company is really doing is not to look at there products but how they make money.

The tail of "It is backed by a big company, so it has to be good.". I hear this so often without the person even having thought about it for longer than 1 second. This sentence promises that just because a company with a lot of money is behind the framework you are using will not go away one day. Google is famous for killing projects. There is even a website for this: https://killedbygoogle.com/. Still, want to use Angular? Okay but what about facebook? Facebook uses reactjs for a lot of projects. They are also looking for new enginers all the time and wouldn't it be efficient if the person joining your team would already know the framework lib you are using? This is something you have to decide for yourself.

I hope you now see some of the problems that we are having right now in the web development community.

How can we fix this? I personally think we already have the right way of fixing all of these problems. Standards! Yes, correct standards! The W3C is an excellent consortium, and more people from the community should be involved there. But this is a topic for another blog post.

Why do standards help us with all the issues?
When a technology becomes a standard, all major browser already have it implemented and ready to use. So this means that I, as a developer, don't need an extra library and I don't need to think about edge cases in a different browser. If there are bugs or problems, then it is in the responsibility to fix this bug for all its users. So it is in one hand to fix it not in thousands of developers hands. It would also help with the fragmentation of the community. What if you could write one component and use it in VueJS, Angular and ReactJS? Wouldn't that be fantastic? So more developer could work on one Calendar component and make it an excellent component instead of having 20 half bakes calendar components? What if all of this would happen without one big company backing this up? Instead, we as a community and all browser vendors?

What if all of this happened and we forgot?

Yes, we! The technology is called "Web Components v1".

Back in 2014, there was a big discussion if we as a community should go with web components or ReactJS. As you now know, we decided to got with ReactJS. At that point in time, it was maybe the right choice because web components were too young and the spec was not ready. That's why we call them web components v0 and we now have v1 since 2018. Now, all big players accepted this spec and have implemented it except edge (of course). Also, there are polyfills for older browsers.

So how do you use them, and how do you integrate them into your current projects?

We will discuss this next week since this blog post is already very long. See this one more as discussion and feel free to comment down below!

👋Say Hallo! Instagram | Twitter | LinkedIn | Medium | Twitch | YouTube

Posted on by:

lampewebdev profile

Michael "lampe" Lazarski


I'm a full-stack web developer. I love to help people.


Editor guide

I'll be interested to see how you build apps with web components and no frameworks next week.

We've tried this at my company and its a total mess. We've found that using a framework with web components is a more sane solution. Otherwise you end up with this Frankenstein patchwork of libraries and proprietary code that zero devs of your hiring pool have experience with.


Okay maybe this is not clear from the post:

I'm not against frameworks! I'm against everybody doing its own thing!

Use frameworks like Polymer, stencil, and LitElement.

The goal should be to don't have these frameworks at all at some point.

The best framework is these that you don't feel you are using it.


I don't know if I'd put lit element in the same category as React. But I do see how they overlap.

We decided against Stencil because it doesn't allow you to extend other components. Lit element has obviously superseded Polymer. So the only real choice at this point is LitElement.

Writing an app only using LitElement presents a number of problems. How do you do routing? How do you do forms? To give two examples you gave in your article. We found ourselves rolling our own code or pulling in libraries. I mentioned this above... I'll wait for your next article to see how you solve these I guess.

I don't have this series planed very far.

The point I wanted to make there was:

Instead of having like 20 implementations of forms it would be nice to have 1 but a really good one! Maybe it does not exists now but if we would use web components for that at least i think that we would have a way better product at the end.

I get what you're saying. Part of the problem I think is that there is never one golden solution. There are always pros and cons. And even worse everyone has their own opinion about how things should work. Still I agree that web components are going to help cull the field of tech currently out there.

There are webcomponents that handle routing,you actually don't need a framework to build SPAs.

Web components that are widely adopted, have a strong community, and are production ready?

I never said it couldn't be done. I have an app in production that proves it can. But I'm not proud of what we did. I think there are better solutions.

There is not one gold solution and I'm not saying to ditch frameworks in general.

My point was that there should be one target.

Yes, this target right now is HTML but still, I can not easily take my reactjs component and put it into vue for example.


it's like jquery back in the day. everyone used it until it was just as easy to do it in vanilla JS. maybe this will be the case with frameworks as ES progresses.

I hope so :)

This would be amazing and great!


React is a library not a framework. vue too, if we're being real. Also web components aren't viable or reasonable at scale on their own. To say they are is a little stubborn. They're better with libraries, but then you're back at square 1

True, but at some point, we were at square 1 with these other libs too.

But with web components at least in the end we could target web components and use them everywhere without the need of having an extra framework.


Idk about routing in LitElement, but there's a library especially for doing routing in a micro front end environment github.com/kriasoft/universal-router


You mean to say only using standard HTML markup and OOJs

Sloan, the sloth mascot Comment marked as low quality/non-constructive by the community View code of conduct

work_status: I'm looking for work!

I suggest you ACTUALLY learn React, Angular or even Vue

BTW give Chris Hawkes (Youtube) some credit.

Way to get some attention. Ditch React, then go on to create another library/framework.

I don't think his point was not to create another library/framework. Rather it is to develop the web components API present in the browser and making it rich enough so that no longer there needs to be 223452345 java-script frameworks and another one popping out as we are typing this. Please think selflessly, this is not twitter fight.

imho the point is not to reinvent the wheel.
what if i would need a widget such as a date picker or a rich data table, for example? should I write it myself? each home made solution may be worst than a proven well engineered one, and its charge for implementation and maintenance could be too much great.
if you need a car, you go to buy a modern one, I imagine. how many models of cars there have been? it's a natural evolution, or isn't it?
so, if you have to develop a new project, you take some modern tool (better if open source).
imho the only solution to the framework changing is to keep the design well separated from the coding, in order to easily reuse the former in the case the implementation would be rewritten to use a new fw.
My proposal is then: spend your time in developing something that may help you to generate the implementation from the design. too daring?


Yeah, before the whole industry swings too far in one direction (again) and goes all in on Web Components, consider the balanced approach:

Shared UI components built with standards (custom HTML tags with CSS or Custom Elements, full-blown Web Components are a pain) composed together and managed by a framework like Angular, React, Vue, or Riot. We have found this to be an ideal situation where teams are free to use any framework for the application structure, but get all their UI from a shared library of standards-based components. It’s the right balance for any team imo.


You've nailed it.


Exact same experience here. Tried porting a huge react code base (over 22kloc) to WC/litelement, and it wasn't easy finding a 1-1 replacement (even with libraries) for stuff like multi-layer conditional validation etc.
Will wait for part2 to see the solution because I do agree with some of this ranting. Hopefully this doesn't stop with part1.


I don't have this series planed out but I never wanted to say that they are an easy replacement.

What I wanted to say is that it would benefit the community because everybody would have on target and one common pattern on writing them.


Ditching frameworks for web components implies that frameworks only provide with a view layer, but is it true? If I had to build a scalable, big enterprise level application with web components alone, how am I to justify to the business the amount of time needed to go framework-less? By saying that FB will drop React at any time? In truth they're investing pretty heavily in it. And so is Google with Angular.

I totally appreciate the underlying meaning of the post, but looking at reality, and most importantly at real world business, I don't see completely ditching a framework, today, as a viable choice.


So how does reactjs help with big scalable apps?

You need a bunch of extra stuff starting from a router to some state management.

You can still use frameworks but they should be interchangeable. If you think about microservices then it would be the same issue if you would need to throw away the whole system just because you changed one microservice. This would be not a good pattern right?

FB will not drop ReactJS but google does throw away a lot of stuff if they think they don't need it.


With its ecosystem, tooling, 3rd parties, let alone how much people love using it. Do Web Components, today, offer the same? No. Will they? Who knows, maybe?

At AngularConnect 2019 it was said Google uses Angular internally for thousands of projects (source). I am not sure they'd be happy to replace them all over again any time soon :)

Google also invests a lot in polymer

Google was the main force behind web components

So why should they now ditch it?

Yeah, no such changes happen overnight but at some point, we have to start. At some point reactjs was only used by facebook now it is everywhere ;)

I think angular has an option to use web components for a lot of its functionality. I would guess google will push more towards using that in the future.

Yes, they will!

They started that web component thing in the first place with version v0.


The React core team has literally no plan if Facebook stops that investment or moves on to something else. And, unlike some other open source projects, React's staff and destiny are entirely employed and controlled by Facebook.


Web components can be used in another way: as a standardized glue between different frameworks developed as microservices.

I developed in the 3 big frameworks (Angular, Vue, React) and the best thing is they promote best practices: component-based architecture, one-way binding, handling application state separately. Yes they change, but I think in a good direction. Just look at AngularJS -> Angular...they introduced one-way binding. They might be not the best possible, but are aiming in a good direction...and it involves change. Change can be good ;)


I hear you, that web components can be a glue between the big 3, Angular, Vue and React. But truthfully, when you see the power, simplicity and flexibility within the "standards-body way" of doing things, you'll realize you are just gluing heavy ass bricks together with elmer, it's just baggage and lots of it.

I love this meme, it brings it into focus:



There's no simplicity in a production implementation of native web components at scale. It's very complex and inefficient

That's what you think. What do you mean?

managing renders, lifecycles, attributes/data-props, data and event binding, and usage of node_modules -all becomes a bit of a nightmare when you do everything manual in a web component.

Going vanilla -you won't have builds and bundling.

If you don't want to use libraries you'll just end up writing your own and basically implementing your own framework by the time you're done, and it will take a long time and you'll be debugging forever.

If you use libraries you will make some of these pain points easier, but you won't have proper bundling or node_module handling unless you do a webpack-type config yourself. If you use libraries for rendering, data-binding, routing, etc -then you're practically using a small "framework" like React/preact.

Don't get me wrong, I'm all about progress for the bare-metal specs. I even wrote a web-components boilerplate that solved a lot of my problems and am still working on a native SPA router. However, I found that as I kept working on a long term plan -I found myself just re-implementing SencilJS, so now I just use that.

Hmm, where have you been? I'll contact you from your resume site.

Actually this is ironic, i worked at the same place as you and got fired for using a native Web Component-style implementation because the lead was confused, made a fit about it, we had meetings to discuss the repercussions, risks to the team, and why it looked so different compared to his million jquery scripts vs my single-class files. I was told that i was high risk to the team and immediately fired, no pay.

Besides folks there are completely closed minded f*cks. Peace bro.

Feel free to reach out. You sad we worked together, where was that? Feel free to DM

Where was this?


Implementing the same functionality with libraries using webcomponents will also result in big node_modules. Luckily not everything is included in the bundled application thanks to intelligent bundlers.


Reasons to use Angular:

  • separation of concerns
  • built in directives and template syntax
  • forms, router - easy and intuitive
  • standard code and design patterns
  • testable code
  • typescript (double edged sword)
  • its an actual framework as opposed to react and vue and it gives you solutions to common stuff out of the box - no need to sweat over 3rd party libs
  • continuously maintained

All of the above makes it easy to work on legacy code or to collaborate with colleagues.
Its not the components that make me want to use it.

  1. I never understand the comparison between the two. React feels like a toy to me when compared to AngularJs or Angular.

  2. Everyone is talking about components like it's a new thing. Web Forms had this idea 15 years? ago. Actually I liked Angular because it reminds me a lot of Web Forms and I could use the same flow. Razor pages? Can't see how it's not Web Forms in a disguise

  3. AngularJs and Angular are not so far apart like everyone likes to say. Actually I converted a big application and it was mainly syntax rewrite.

  4. I'm dying to get rid of javascript :) It's amazing that we are still required to bundle files in 2019 instead of having an engine that can run anything inside the browser...


There is an actual engine inside de browser parsing and compiling code! Its called V8, SpiderMonkey and many others. The thing here is about your personal preferences; looks like you don't like JavaScript very much when it is the only programming language the browser directly understands.

I said that I don't like Javascript :) It's outrageous that we have to settle for it even with TypeScript which improved the situation drastically. It's still an inferior language (and this is not a personal preference). Anyway, I complained about bundling. It may look natural that you have to do it, but this is merely a compromise. There should have been a better more elegant solution by now, And I work very hard every time to hide this burden from my developers, bundling is not something I want them to waist their time on.


Sometimes all you need is to render some elements inside one or more isolated containers, handle events and state, and nothing more.

I rarely have to do something else. What does this have to do with how to write the actual code? When I hear such a statement from a developer in my team, it means they are going to cut corners and they are going make a hard time for the others.

The fact that it is a lean library that does events, rendering and state (and that's about it) is what I like about React.


Maybe they are we will see :)


I'm not disputing that at all.

But we as a community of web developers are working on frameworks/libs that have been already solved several times.

My point was maybe we should rethink that and try to come to a common design pattern for components?

In the end what I have seen that Standards will survive libs/frameworks will not.

  • separation of concerns - wrong. HTML and JS/TS are not your concerns. Your app features are.

  • built in directives and template syntax - oh you mean the ones that don't really work well with typescript?

  • forms, router - nope, forms are hard everywhere. at least with react libs like Formik makes at somewhat bearable

  • standard code and design patterns - oh you mean those patterns that make the code look like a bad corporate JAVA where you need write 10 keywords, 5 decorators just to define a property? No thanks.

  • testable code - who are you kidding? angular can't even render a component into a string. Do you expect me to only test in full DOM? Shame on you.

  • typescript - how dare you attribute this as to angular. You can use typescript with any other framework.

  • its an actual framework - bad framework. For example they recommend rxjs for state handling which is total overkill for 99 percent of web apps

  • continuously maintained - with already 7 breaking versions? Where they often change arbitrary syntax for little benefit? No thanks. I'd rather react

"All of the above makes it easy to work on legacy code or to collaborate with colleagues."- lol I just finished on a corporate contract where we used angular 6 and 7 and it was a total shit show. Total opposite of what you paint here.


There are many types of concerns. The separation of concerns along which HTML, CSS, and JS were designed are real. They reflect the persistent concerns of user interfaces across most projects: what is this information, how should it look, and how should it behave? And they served those concerns well when we were making simpler content oriented documents that weren't bursting at the seams with a single scope. What the platform has failed to give us is a way to separate by project specific concerns, business-centered concerns, suitable for increasingly complex applications. Frameworks concentrate on the latter and very few, perhaps none, have reached the same bar as the web platform for meeting the needs of diverse devices and empowering copywriters and designers to contribute. Web component features like Shadow DOM are critical in enabling business concern separation while also maintaining the web's unique value propositions for audiences wider than engineers.


Your ultimate argument is you hating the framework. You also might be confusing Angular with AngularJS as well. You got the right to your own opinion though. Cheers.


Been programming for 20+ years, I've seen frameworks just die and you're left with a pile of out dated and poorly supported code.

1 thing has not vanished, and it is w3c/web standards.In just a few more years react and angular will be bad legacy ideas


@Joey D. - Not a good example, but i think i see your point, you can say that http header spec went through some kind of change, but that change is still confined to a "path" in a well-defined and stable HTTP Architecture. An Open-Closed design allowed the evolution of http headers without breaking the overall architecture.

What we have today in UI are companies partitioning the once simple idea of making a page into proprietary ways to make a webpage, ignoring the spec body and producing their own, which is not all necessary (VDOM) and is actually quite profitable for companies like [name here and here] to increase revenue along just another venue by way of "talks" and shows, and events, video, training and popularity.

Hey, you have all the right to innovate.



And if we build frameworks let build them so that they are built around w3c standards!


Yeah and there are more frameworks :)


Plenty of web standards are abandoned and lost to time. Just look at the history of http headers.


Yes and sadly so many god ones :(


You couldn't be further from the truth my friend


Sorry, who?

and what truth?


Web Components actually work well to compliment frameworks. They aren't mutually exclusive technologies.

I use frameworks to manage the state of a view or an application. Web Components allows me to re-use elements across multiple frameworks, or none if the site or app is basic enough.


Good luck trying to use webcomponents with react.


Done it. It works. With TypeScript, no less.

Maybe I'll put together an article to show how it's done. 🤔

I would love to see that blog post :)

Look into direflow.io. They make it super easy to bundle a React component as a native custom tag Web Component.


I know what you're getting at, it would be very nice to have a standardised way of doing something, and only ever use that one way.

However, I whole heartedly disagree.

My first point on why I disagree: if we all work inside the box, where's the space to innovate and create something better?

Next up. Your attack on frameworks and libraries and how overchoice leaves you paralysed.

Firstly, frameworks and libraries are different. Frameworks are an out-of-the-box solution for most of the problems that a developer will run into when developing their app. Routing, forms (to give your examples), state management, XHR, debugging, testing, performance optimizations etc. The framework will also usually come with a set of best practices, and guard rails to ensure you are working within a set of constraints that will empower your and your colleagues and allow for more maintainable codebases.

Libraries on the other hand are generally focused on solving one problem and solving it well.

React can be composed with many different libraries and solutions meaning every react project could have a different architecture, but one that could fit the business problem more efficiently than a set in stone standard provided by a framework.

By having different options out there, it gives every frontend architect the chance to look at each option and analyse which option will suit their team better, and will solve the problem that they are trying to solve best.

Who is to say by choosing one you can't use any of the others? With tools such as Nrwl's Nx Workspaces you can have React, Vue and Angular projects live side by side and share code between each other.

Next up, web components. Amazing, truly standardised way of creating reusable pieces of code that can be shared across projects and dropped in. But does it out of the box solve your state management issues? Provide a maintainable approach to structuring your app? To guide developers on how they should be internationalising their small reusable component?

Frameworks and libraries aid development as they provide a starting point and guide on how to wire together all the components that make up the full application.

Out of the box, web components, and correct me if I am wrong, do not support server-side rendering which could lead to performance and potentially SEO issues for customers down the line right?

There can never be a one size fits all in software development, otherwise we would all only be writing in one language, Assembly, and we wouldn't have libraries and frameworks, and we would absolutely hate being a programmer and we would never be able to innovate or prototype or scale out applications to the global scale we can now.


Web component do support SSR. You just need to extend existing html components instead of just creating new ones. Some libraries facilitate this. Take a look at heresy and heresy-ssr (there are other).


If you are unsure where to start with Web Components, this is probably the best resource I have been able to find, that is friendly enough for anyone to understand. If you are a React Developer, this new technology will be a breeze.\



Thanks, I will have a look at it


So, while I look forward to your next installment where you will hopefully prove me wrong, I disagree with your premise. I've worked with web components, react, angular, and Vue. Based on this experience, I would never willingly choose to build an app purely with web components. The spec is still immature, the code required is extremely verbose, the style of writing is imperative and reminiscent of the old jQuery days of manually constructing HTML with JS... I could go on, but that's my opinion. It would be great if we had a native solution that didn't require the frameworks, but that is not reality yet.


Exactly not yet!

So we have to work to get there and it would be nice if more people could work together to get there right?


I'm looking forward to your next post on this topic. It's interesting but I'm not sure I fully share your view. But I'm not going to comment on the technical parts of the whole Web Components VS Framework debate as I believe others have done it better (Rich Harris for example, in dev.to/richharris/why-i-don-t-use-... and in the surrounding discussions on Twitter).

Though I believe that some parts of your reasoning feels a bit fragile. Like "[...] if you are really honest to yourself, then you would probably still be happy with class-based components". I think this is a naive and potentially hurtful way of reasoning that limits progress and technological advancement. Imagine someone saying "if we didn't invent the wheel we'd still probably be happy to carry all the stuff around on our own". Yes, if we are not aware of, or chose to ignore, alternative ways then sure, we'll be happy with what we currently have. Because we don't know of any other alternatives and we don't aim to improve the current process. I don't see how this argument adds any value to the debate.

Concerning hooks specifically, the marketing (from actual React maintainers) has never been "Hooks are extremely superior, you should rewrite all your class components NOW". Some members of the community have maybe tried to convey that message, but I really don't think that "we have been tricked by marketing". Can you point me toward some of the marketing you're thinking if? If it's mainly community created posts and opinions I instead wonder how you classify marketing in this case? Reading the official adoptation strategy FAQ (reactjs.org/docs/hooks-faq.html#ad...) I think it makes it pretty clear that they don't expect anyone to rewrite or scrap all their old class based components. Sure, they encourage us to try the hooks API, but I don't consider the marketing very problematic, authoritative or controlling. I think the difference between official marketing and community opinions from individual users should be made clear.

You're also discussing the risk of having too many front end frameworks to choose between and how it paralyzes people. Is that really the case when it comes to general UI frameworks though? React has been around for 6 years with very few breaking changes. Vue.js has been around for 5 years with very few breaking changes. Angular has been around for a very long time, unfortunately can't say the same about few breaking changes here though.. :P

Do you find this enough to impose "overchoice" and paralysis? I don't personally think so. Sure, there are lots of other frameworks and libraries in the JS ecosystem, but you seem to be mainly talking about more general UI frameworks here. If we're talking about JS libs in general the reasoning also applies to a development process focusing on Web Components. And if you think we need to consider all smaller frameworks as well, than I'd say that the situation in the JS ecosystem isn't very different from other languages. If wide adoptation is of no importance then you'll be able to find quite many obscure little libraries and frameworks in the .NET or Java landscape as well. That could impose paralysis if you choose to not only consider the main, widely adopted, alternatives.

UPDATE: I see you've clarified that you're "not against frameworks! I'm against everybody doing its own thing!". I partially agree with you about that, but with some of the thecnical inconveniences of Web Components I'm not sure I believe it's the best option. And if you're fine with using a Framework on top of WCs, than I believe everybody will still be able to "do their own things"? :)


I don't have anything against frameworks.

What I want from these frameworks is to target web components.

Everybody is still free to do what they want!


Ah okay, I think I got a little misguided by the post's title them. So you're meaning kind of like Svelte 3 is already doing? (although with an optional compiler flag) My understanding is that the current WC spec is challenging to work with to achieve some patterns and features that are considered needed or very useful in frameworks. Which is why it might make more sense from a framework perspective to only optionally target WCs in order to fully support some features without a lot of extra hassle and workarounds.

One problem area that comes to my mind is the Web Components total inability to handle SVG content conveniently due to elements needing to exist in the html namespace

The moment I can turn my reactjs component into a web component I would be happy!

SVG in general are kind of challenging but that's IT in general

Check out direflow.io/. It packages a React component in a Web Component 📦 and it provides the glue between attributes and props.


I don't think web components will ever be more than a fruitless idea. What did they think would happen, they created an imperative, dom-bound, vendor-controlled view layer that yields a naked dom node. And it shows, usage stats are in steady decline.

React, at least in numbers, has won. And it hasn't just won the web. It is surely better than embedded browsers, waiting out vendor in-fights and shady policies for features, or getting served questionable features without merit. This is what the web was always about, things develop and progress when they're actually good. Technologies aren't served, they evolve in accordance with how the community responds to them.

Btw, you keep mentioning Polymer. They have broken every promise they ever made. They had more hard reboots than any other framework including Angular, forcing people to rewrite their code from scratch. They had absolutely no vision other than "standards", which curiously were ever changing and still can't answer for a fraction of what frameworks solve today. It was clueless as to what people actually need, they thought npm as a fad basing on ... bower, they actually believed people wanted to import html's. And like always, the people that are going on about "framework fatigue" are the ones that are actually experiencing fatigue - through so called standards - but no one else seems to have these problems.


Right now reactjs is maybe in the top but like every framework in the history of programming will go down but we will still have standards. Yes, these standards will evolve and that's a good thing.

I would rather contribute to a standard then a framework that will be gone in 3 4 years the standard will still be there.

Maybe not in version 1 but 2 or 3.


view=function(state) is a paradigm, which is what matters. Paradigms don't change often, controller based mvc just had a decade.

Standards don't fall out of the blue sky. React was initially a great idea that has practically brought about a paradigm shift. It has been influenced by millions of developers world wide putting it to use. And it has proven to be flexible enough to adapt and renew itself, which is the hardest feat.

Since browser vendors are implementing these specs and you don't longer trust these standards.

The only conclusion I see right now and please correct me if I'm wrong. You will work against these standards? Or what is the conclusion here?

Or should we fragment more and we will be the next "year of the Linux desktop"?

Browser vendors have implemented scores of useless features that were later abandoned (object observe, etc). That is why they have made the extensible web manifesto, which was supposed to prevent this from happening by explicitly focussing on the low level. WC, once again, break that ideal. It isn't about trust, it is about merit, no one is foolish enough any longer to just blindly go along with features that have no merit. The web is mature enough to let certain things develop outside of the spec body's grasp - the high level, component abstracts etc is something that should never be set in stone as it needs to adapt to the ever increasing requirements. If web components can't even fulfil requirements we had 10 years ago, not to mention todays, how are they going to adapt to the future?

Or should we fragment more and we will be the next "year of the Linux desktop"?

Do you realize that you are talking about web components? I've seen such articles for 10 years now with nothing to show for. Yet all the spec would cause, if it were adopted, is fragmentation since it relies on frameworks to drive the exposed root node. But since the proposed component definition is inherently flawed (imperative, mvc controlled, templates, embedded browsers on mobile and iot, all the things that we have finally put to rest), the fragmentation would be devastating. The spec simply does not solve our problems, and that's the reason it is withering away.

V=F(S) is a single, cross platform standard that actually works and has been accepted by the community at large. It is the first time that we can serve multiple platforms with the same components. It is also the first time that platform differences flatten out, web, mobile, native, ar, vr, everything can be targeted. It has done in a couple of years what the web couldn't do in 20. Yes, React, or rather the paradigm it has created, is more of a standard than the specs body could ever dream of, so what are we complaining about?

Except Web Components are paving the cowpaths in a way a lot of abandoned standards don't. They also have a viable opportunities for allowing script-free extension of HTML. Since JavaScript is fragile and expensive, this is pretty critical. You'll notice that the standards the React team is collaborating on don't feature this paradigm. There's a reason for that.


So framework X comes along. Devs try it and rave about it. More devs sign on and soon there's large wave of devotees. Lots of software gets written. Business rules get encoded. Bottom lines begin to depend on the framework.

And then another wave comes through. Its actually not that easy to rewrite everything. Nor is it financially viable. What do you live on while everyone scrambles to re-tool and re-write? And since when has a rewrite not injected idiosyncratic language- or framework-specific bugs into a previously stable, mostly-debugged system?

This is why there are still multiple millions of lines of COBOL out there running on mainframes -- the cost of change becomes prohibitive. And what do you run while you wait for the new stuff to arrive? And why bother waiting for new stuff to arrive if the old stuff works? And what do you rewrite it in if the sea keeps changing? There was a while there when folk actually talked of replacing Fortran with Forth and COBOL with Java.

What's missing from the meme at the top of this article is the sprightly octogenerian grandmother (labelled COBOL) who rolls her eyes at the immaturity of the young man's wandering gaze. She still riding her wave.


The problem is that banks for example now how problems of finding these grandmother's 😄


Yes. Which is why I was on comp.lang.cobol recently trying to convince folk to get a COBOL course running on exercism.io. They didn't exactly jump with excitement over the idea. Yeah, setting up a course isn't a simple process but even so there's money to be made knowing COBOL.

That's true!

If you know COBOL you can make a lot of money!

Because banks, for example, want to solve everything with money ;)


Check again web components specification and all the resources around the web from google, stencil, and open web components. React and web components can't be swapped because they do a different thing. Web components are made to extend HTML and to make new leaf elements, not applications or big components. They should be simple, add functionalities to HTML elements and use composition (one of the core concept of HTML).


Sounds to me like what reactjs wanted to be an ui framework to for creating components.

ReactJS has no data layer that's why we need things like Redux etc.

Maybe it now has something with hooks but I think it is still to early to say.


React can't create custom elements or extend the built in ones. React, as an abstraction layer can of course handle their components, but they're just logical containers that render html elements. Web components are THE html elements you should render inside react, as for the built in ones.

So I could argue both ways.

Why then not use react fully? Or why not use web components fully?

You can use react fully, but you will have the react dependency. Wc are framework agnostic with no dependencies if you use vanilla js. With react you can't create or extend native html elements, (this is the point of web components) you can just use then the html elements you have and combine them to build a new widget. While with web components you can't build apps or complex things because you work directly with the platform api. They are on a different abstraction layer, as I said here:


Okay, thanks for the link!

I will read it!

I think that's a very good point; the abstraction layer. The link above puts it well:

We are told web components are basically new HTML elements, so we should consider them as part of the HTML specifications and, consequently, we should follow its paradigms, core concepts, and utilization. If we assume all of these points, we will figure out that our components will live among the lowest levels of the web platform stack, alongside HTML, CSS, and JavaScript.

Web Components seem to be at the leaf level of HTML documents. I don't feel comfortable when folks say that an entire SPA should be enclosed in a single Web Component.


Couldn't agree more with the fact that the Web Development environment is convoluted and that we are just reinventing the wheel, in cooler ways, to do the same thing, and not getting anywhere. Web Components are a low level api and not for direct use, both a good and a bad thing. LitHTML and LitElement are probably the most commonly used tools for Web Components right now, but these are obviously in their young stages (Lit HTML is backed by google and we all know the fate of most google projects).
This is one of those points where Web Development takes a turn, one bubble pops and we focus our energies onto another, more promising one. One thing however is for sure that the Web Components API is here to stay, and to replace the Framework mess, whether everyone wishes to accept this or not.


Yes! and Yes! 🤣👍

Web Components are kind of low level but I don't think that this is a bad thing.

Right now we producing web developers that don't even know basic HTML or the don't know the difference between git and GitHub.

So some kind of understanding the low level would be a good thing at least in my opinion.


I don't think it's fair to say that frameworks are producing web devs that don't know basic HTML, most of the UI libraries and Frameworks still involve the dev writing some form of templating code.
NativeScript with Angular is the one that pops to my mind that doesn't use HTML itself.

Also, with the development of web components comes the introduction of more libraries, frameworks and tools to create them.
StencilJS, Angular Elements, Polymer etc.

Will the market be flooded with too many libraries and frameworks to develop web components 2-4 years down the line?

I work/teach juniors.

Some of them can't write a static website without reactjs or some other framework.

I think this is a problem because they don't understand the basics.

The thing with having stencil or polymer as that I don't care if they are written in whatever framework I just import the web component. This should be the goal.

Of course, all of this has its own challenges

I go to school with many of the same kids. I think the problem with young devs not knowing how to write basic static sites is due to the lack of structured courses in higher education around web development. Young devs usually like to go for whatever's new and flashy because that's where the jobs are (or so we're told). Few people understand that the fundamentals are more practical to learn in the long run.

The fundamentals are of extreme importance. Sir James Galway, the world famous flautist, said as much in this posting regarding the value of learning scales.

  1. Choice is good. Whether that's my desktop environment or framework (and honestly, choice of DE is one of the greatest features of a Linux box) reducing choice reduces competition, which results in a de facto ho-hum implementation
  2. Web components aren't a standard. Google would like them to be. Clever people are pushing back, mostly because we have sufficient tooling and frameworks to achieve the myriad components we need
  3. After working with polymer for a year, in addition, having a few years experience with angularjs, some more with angular, and over a year with vue (sorry, my react experience doesn't count), I can unequivocally state that polymer is pure shyte. It's slow in anything except chrome (remember, Google wants this to be a standard, so they support all the stuff that's in the fallback libraries out the box), it's difficult to test components with lots of subcomponents, it's ridiculously slow to run large test suites because polymer teardown is slow (I wrote my own test runner that would split tests up and run batches in parallel. A year later, I see Jest doing something similar...)

Long story short: use the framework that works for you. Even if it's polymer, say on a small project, though I advise, from experience, to steer clear of polymer for larger projects - it gets frustratingly slow frustratingly quickly.


@Davyd, did you try the latest Polymer releases (LitElement, Lit-html...) is it the same as Polymer? I wanted to try them.


I haven't. Give them a go if you have the time and let us know.

It's been about 1.5 years since I used polymer, and I haven't missed it one bit. But there's always room for an improvement 🙂

I still need to learn some stuff before doing that. I'm trying to check by myself if I can get rid of frameworks and use only html CSS JS for my little personal projects. I still need to know how to make a router and spa without framework, how is it to do a loop like ng-for/v-for in pure JS and if it's worth it, and check the compilation with npm babel etc without the great vue cli 3.
PS: I'm a UI developer, not that much of a front end engineer

I've heard some really good things about svelte too, and it might be easier to get into, considering that, like vue, you can integrate it piecemeal with your existing html. It's definitely something to keep on the radar.

Isn't it another framework or library we could avoid?

my opinion is that we shouldn't be simply looking to avoid frameworks (:

if you just need the smallest amount of logic (or none at all) in your web page, then sure, vanilla js, or nothing, is good.

but if you're looking for some kind of updating component which does stuff, I don't want to (personally) do the heavy-lifting that a lot of other talented people have done before me -- in this case, I want to use a framework so that I can concentrate on my application logic, not re-inventing the wheel (and dealing with cross-browser issues)

I'm advocating that people use the tooling which works for them -- don't use a framework just because it's "cool" or someone said you should. Don't ditch your framework because someone else said theirs is better, unless theirs actually does work better for you. Best of all (coming back to the OP), don't propagate the FUD that web components are a "standard", when they are just another framework, unratified by the W3C, pushed by Google. Do you remember the debacle last year when Mozilla complained about anti-competitive behavior where YouTube was signifigcantly slower in Firefox? That wasn't Google outright throttling YouTube for Firefox users -- that was Google assuming that they're too big to fail, baking their framework into Chrome and releasing a new YouTube using their framework, probably hoping that it would drive up the desire to make web components a standard.

Anyways, like I say, I don't have appreciable react experience, but if you're getting stuff done with AngularJS/Angular, Vue, Polymer, Svelte, whatever (I've also used a couple others, including CanJS for a prod site and a few others I've dabbled in, including Knockout and Ember), then carry on getting stuff done. If your framework is working for you -- use it (:
My suggestions are based on my experience:

  • Polymer gets unwieldy on larger projects
  • AngularJS is good, but not for monstrous forms (ie, think spreadsheets)
  • Angular is good, but requires full buy-in and some deep knowlege out the gate
  • React seems to work well for others, but requires a large mindshift, which may be worth it -- I don't have enough xp to tell
  • Ember rubbed me up the wrong way with opinions like "AMD is WRONG"
  • CanJS -- not sure if it's even maintained any more?
  • JQueryUI -- good in a quick-fix situation (also, check out Chosen for drop-downs)
  • Knockout has never been a positive experience for me
  • Vue -- easy to pick up, can be brought in as needed or as a complete framework, with vanilla JS or TypeScript, lots of freedom, and we've built a white-labelled online application with it, with > 2000 tests, so it's quite capable for large things, but easy to shim in for small uses
  • Svelte -- apparently has much of the same wins as Vue (after listening to a podcast by the creator), though I haven't used it, so again, YMMV
  • Vanilla JS: good for smaller things, but you have to do all the heavy-lifting yourself, including dealing with cross-browser issues

/2c (:

Thanks for your answer.
OK so I'm going to check out the web components world and see if I can switch to something different or continue with Vue (I love Vue, it reminds me of the JQuery days, lots of freedom)

Good idea -- that's the only way to form solid, useful opinions about frameworks: build with them, see what works and what doesn't, what's easy and what's hard, what's a pleasure and what's a real pain.

Personally, if I were about to build something new, I'd pick Vue if the project Really Mattered or if I didn't have time to experiment, otherwise I'd like to give svelte a crack (:


Thank you for writing this and reminding me that being a good developer means using technology where it adds value. I realize that I let myself get caught up in the hype of these frameworks that are really providing my project with no value beyond "bragging rights" that our app is using React. The fragmentation and interdependence of these new frameworks bring to mind the old DLL hell of the fat client.


I don't like that the community is running around like sheep.

This week this framework next week that framework but they solve the same problem just in a different way without adding value to the product.

I have seen teams that did a rewrite in reactjs/angularjs/vuejs and the user experience was worse than before.


I'm not sure why this argument about frameworks sucking continues all over blogs and YouTube. I mean c'mon guys, as developers we have to stop resisting change. Every industry continues to grow no matter what industry you are a part of. If this logic was correct we'd all still be coding in Pascal. We have to deal with it. Nothing lasts forever. And we have to continue upping our skills. This would be the same in the education field, marketing, accounting, etc. There will always be new research, and new ways to do things. And when you continue learning it's called professional development. I'm sorry that the web is not some static unchanging thing, but it is and technology continues to evolve. And with evolving technology comes new tools and evolving tools at the least. I mean if anyone wants to write your app in vanilla JavaScript everyone is completely welcome to and skip a framework. But frameworks will continue to grow and evolve. I think part of the problem is perhaps people not picking. Just choose one and continue to follow it on its path. If you're angular be angular and follow the community. If you're react be react and just follow it. So then you're not as shocked when changes and upgrades happen. But we cannot continue this argument that code should never evolve and continue complaining about frameworks evolving.


Mhh I don't fully understand how you came to the conclusion that code should never change?

I was saying that we should now jump to the new thing: Web Components v1.

They were released way way after react,vue or angular.

Maybe this was my fault but I'm not against frameworks I'm just against splitting up a small community of developers who actually contribute to these frameworks and then make them even smaller.


One of these days I'll have the guts to explain why I don't use any frameworks, but do use consistent coding patterns that sometimes look framework-y.

Might partly be because I tire of the constant debates over frameworks instead of getting work done.


I'd also be interested in a post on this! We recently started using VueJS, but now SvelteJS is also starting to look very appetizing, and I'm sure in a few months there's another way building web apps and that will start to look really nice. I find it hard to make a choice and stick to it when it all moves so fast.


Looking forward to that! Please post this online!


I've to say, I don't appreciate these clickbaity titles...


What would have been a none clickbaity title for you for this blog post?


If it would have to be catchy and just a little bit misleading you could have used "You might not need Angular/React, WebComponents FTW!" or something like that. But the part about ditching angular and react is just plain stupid, as you kind of admit yourself in another comment here. They are tools for a very different kind of task. You would not build a complex app with just web components (you will at least need some other layer for all the business logic) while they are probably the best choice for the job if you want to build a UI library of some sort.

I don't know why it is miss leading or why I'm stupid but okay.

Your opinion and I respect that!

I chose the title because I felt it was the right one.

If you just want to build any UI to get the job done probably jquery is good enough for 90% of the webssite out there.

But my point was not to get the job done. It was to work towards one goal not seperate into a lot of goals.

But again thats just my opinion and point of view.

History will tell if I was wrong or not.

I don't know why it is miss leading or why I'm stupid but okay.

Here's the thing: your opinions aren't you, and the comments aren't about you either.


Not meant to be offensive

What is this some kind of web development socialism? The reason frameworks exist because they serve a purpose and they are good at solving certain kinds of problems.

How can you tell that some way of doing things is better than other, before applying that abstract idea to real world problems. Think of frameworks are kind of lab rats to test ideas. why are you so hung upon them after all they are based same old ideas and new shiny syntax. There is no holy grail, one size fits all programming language/paradigm/framework.

coming to linux example, i use i3wm, and it solves my workflow problems very well. Does that mean everybody has to use it? or somebody using xfce/gnome/kde is wasting their time?

Let us see, when web components become popular, we will then have people talking about why they are a poor way of solving problems just like they are complaining about jquery (it was awesome when it was released).

If everybody works according to your or my wishes, then our ideas are absolutely correct. If we are absolutely correct, that mean we know everything and can predict everything which will never happen. so everybody will work according their own wishes and will produce a new framework(next update react anchors!! to be released on fall of 2020!)


I'm not against frameworks.

We are already building for one target it is called web. The web does support only html css and js.


People always forget the "and js" part uh


Really really hoping part 2 is where you explain how much farther along and well defined the web components standards and cross-browser adoption in the past year or so is now surprisingly mature. Otherwise I would say your arguments are invalid sir


If we leave out the web components part and just look at the first part what would you think about this blog post?


Then it would be a mixed bag for me: while you're showing the kind of genuine dedication to finding the simplest and most elegant ways to build UIs, it also contains the kind of minor/medium flaws that come along with idealism. There are genuine obstacles in the way of reaching the most elegant and ideal ways of building the kind of front end applications we'd like to build.

For me, working on large JavaScript applications prior to jQuery, Bootstrap, and Angular 1.0 gives me an appreciation for the improvements those frameworks brought to help me get my work done. The sunsetting of those frameworks and making way for ones that offer more simplification and improvements to new problems (or ones the older frameworks couldn't solve very well) are worth celebrating. Throughout the article here I ran across sections that hint that you might not have as much of that history under your belt to notice ways you've come full circle or are suggesting solutions that re-introduce old problems.

So far Polymer seems to be one of the better ways to work with web components in a scalable way, but it has limits and (hopefully you'll shed some light on this in part 2) I'm curious if browser support is far enough along to base a front end architecture on it that can scale to large teams for companies with heavy public facing traffic.


I agree that standards are important and should be developed for the web. I also think that libraries and frameworks like React and Angular were developed to solve the problem caused by lack of standards, but also because to generally took too long to do a few basic tasks.

The differences in how we approach solving problems represents our unique ways of thinking about them, so there was definitely going to be variations as seen by the existing libraries/frameworks. I also think that some people (probably like me) didnt really get into the band wagon because one library was backed by one "big company" but because it offered a way to solve a problem and I could either go with it or not. This kind of diversity is what I find liberating for me. (I might be alone on this). So standards are great, are welcome but should solve the problems without taking away the ability for people to express themselves, afterall that could be why some of us started coding.


I see it a little bit different

With web components I can express myself not only to the reactjs community but to the whole web community so I have a bigger audience


What's so hard about routing with react-router-dom? It only takes an import, and one line per route.


oh, react-router...

Updating the codebase from v1 to v2 to v3 to v4... no, thank you!

I'm a burned child here


You should take a look at what the Angular Team are doing with their CLI tool and how they're writing migrations to automatically fix any breaking changes within your codebase as they progress from version to version by simply running ng update.
And they do it using an AST rather than a RegEx to maintain the correctness of your program.

Yeah they maybe do it now

and these code mods have their limitations.

the react team has them too.


Dude, framework aren't only about writing components, like let's say react, having declarative helps so much, how about states and redux, you just update your state and everything else takes care of itself.

You can't seriously think non-declarative is better do you?

There's also routing, doing stuff in client side to reduce load on server, etc,


Have you tried sveltejs?

I think you will like it :)

For me, it is better react :)

Build-in router and state management and no need for things like react-router or redux!


Your title suggests to ditch framework and go with web components, I doubt sveltejs is a webstandard and not a framework.

I'm not saying to ditch frameworks. Just that the once we have should target web components instead of making up there open things 😊


Sorry if this response is all over the place, it kind of got ahead of me and I was trying to bang out at least a somewhat thoughtful response before I had to go to work.

As a million people in this thread have already said, I feel like web components and frameworks solve different problems. I do think frameworks should work to target WCs where it makes sense (isn't Vue working towards this?). Extending built-in HTML elements is very cool and currently underappreciated, but to me it seems hard to justify building an entire application around it, in the same way the argument a few years ago could have been "yeah we could use frameworks, but we could just as easily write document.createElement('div'); ... ourselves!

There's been a lot of talk about "frameworkless JavaScript" but to me it misses a couple of points.

  • No one is asking Java or Python, for example, to standardize, again, for example, their server frameworks. "We need to stop writing Django or Flask and use the standard library instead!". It's always JavaScript that lacks the Official™ solution.
  • By adopting a "standard" solution to building web applications we also risk "standardizing" their shortcomings too. This would be true with WCs as much as it is with large-scale adoption of React. One of the benefits of having so many web frameworks, it seems to me, is that we at least get to weigh the pros and cons of all of them. I know that if, say, in five years, WCs managed to replace all the popular front-end frameworks now, that just as many people would complain about how awful web development is due to whatever shortcomings WCs introduced (and enough people do that already!).

(there's probably other things but these come to mind)

I don't entirely disagree with you but I'm certainly reluctant to buy into any "one size fits all" kind of solution.


I'm on the cusp of this and couldn't agree more. I've recently switched all of my projects back to the simple html, css, and js. The only library I'm using is VueJS (but not the CLI). For development I literally just serve the ./app/ folder. Then for production I use rollup to bundle everything and output to a ./dist/ folder.

JavaScript has come a long way since all of these MVC frameworks started making waves and honestly it makes a lot of their functionality redundant. I only use VueJS over the others because it doesn't require a CLI.

There are even some added benefits of not having a watch/build step. For example you can utilize the built-in tools of Chrome/FF that allow you to directly change the CSS/JS in the browser and save it back to the folder. Or if you prefer the other way around, you can use VS Code's debugger to get breakpoints right in there. (Sourcemaps frequently break for me.)

I initially had some fears and do kinda miss things like nesting in SCSS but the general reaction while working with others in this environment is extremely positive. And we keep it clean just as well, if not better, than with a full framework/setup.


You should write a blog post about your work flow.

Drop me then a link to it


What you're suggesting is basically a monopoly. Monopolies are bad for innovation. If we all use one thing then progress will be very slow and evolutionary as opposed to revolutionary


Mhhh calling a standard a monopoly hmm

I think we have two different understandings of the word monopoly.

Where is the company here? 🤔


Monopoly doesn't describe a company - it describes exclusive control of a supply. If everyone is using a single standard and nothing else then the standards committee are those that have control and use it. In this case the supply is actually options/ideas/ways of solving a problem.

Let's not forget that most things that go in to a standard were being used before they became a standard and they became a standard because they were popular. Using things like React/Angular don't always a standard they extend what people do beyond it - but even if they do - then they do so bringing new ideas that may themselves become a standard. There is a reason why they're popular.

So HTML, CSS, and Javascript are also Monopolies?

I'm pretty sure we have pre-processors that allow other languages. So if we take it to that level what you're saying is everyone should use JS and not use any other language such as Typescript. What I'm saying is that even Coffeescript had good ideas that have now been taken in to JavaScript making everything better. Web Components are basically a library built on HTML, so if we go back we could say "Time to ditch web components and use better standards such as HTML!". Remember - web components came from the Polymer project.

I'm all for usunig and learning html before usunig reactjs or Angular!


Posts like this tend to promote an unrealistic view of Web Components. Or atleast Web Components in the current state. As I'm sure re-iterated many times in the comments a Framework replacement they are not. I've been using them in production (polyfilled to be sure) since 2014 and I think generally the wrong comparison is being made. People still generally need tools to make working with them easier a library/framework of sorts. In fact, I would say Web Components are some of the biggest culprits of Library fracturing. They provide just enough that every would-be library author now has a framework. I can't help but feel it starts from the sentiment presented in this article.

Admittedly I'm guilty as charged of being one of those. But I think it's more interesting where popular libraries have tried to align with Web Components (I'm looking at Vue, Svelte) and now have diverged or would not recommend using them.The reason is simple. Beyond not being wholely up to the task they are primarily DOM oriented. It makes sense but it means silly small things like eager versus lazy evaluation of slots, or lack of declarative Shadow Root, or event retargetting interfering with event delegation gets in the way just enough. I mean libraries have been developing techniques to better interact with the DOM that aren't quite compatible with Web Components. Now obviously we can say "React your synthetic event system should no longer be necessary so get rid of implicit event delegation to be compatible." Or maybe we shouldn't. There are solutions to resolving composed paths for that specific example. And there are lots of different ways to solve similar problems. But it is still something.

I think another thing we don't talk about is their natural overhead. There is a difference between components and Components(TM). What I mean is that components as containers Web Components are adequate. Defined contract of API, encapsulation, modularity. However in a library like React that isn't how or why you use Components. The patterns being used by libraries have just as much to do with performance or mechanical reasons as they do for containerization. Web Components are a much heavier construct than those. Thinking you can use them interchangeably is a big mistake on scaling performance.

All that being said I think Web Components are important and have the potential for a lot of great things. I just think that this sort of argument is so easy to poke holes in that it will never get consensus. Web Components are not the same as those libraries. They can cause just as much fracturing of solutions. And they come with just as many specific tradeoffs. Accepting that is where the real conversation starts.


To say it in a shorter way:

"IT is hard" and yes it is!

But I rather work together with the people on one goal then everybody supporting just there team.

But that's just my opinion :)


I'm doing routing and form validation using Angular and I have absolutely no problems in doing that. Very satisfied with Angular, as well as it "small splitted community" and I like the way it is. Easy also to find developers who knows a common framework, so it does the work perfectly. I am for "Standards", but I disagree with most of the things you've said here.


You can disagree that's totally okay!

Just please don't bet on one framework. In my region (Europe) when looking at job postings angular is going down and more vuejs is asked.

Every framework/lib has its time and in the end will die.


I 100% agree, I've been waiting for web components for far too long. I was hyping these up at work for years, then they seemed to have faded and finally came back again gaining traction. Web components are the next big game changer...


Yes! They are!

The problem is they are not baked by one big company!

So the community has to push them!


I don't really know what to do with that comment 🤣😅


I wrote a reply . . . then mistakenly erased it 🙄
Bold because the evergrowing garden of coding bootcamps and fast-paced web-dev schools (my dear Lambda School included) spends an inordinate amount of time creating projects and tutorials to master the hottest & latest JS frameworks with a half-life shorter than Francium. I agree completely, and it feels like we're all going our own paths with web technologies which may let beginners explore COUGH|anDjOiNtHeCLOjUREdaRKSiDE|COUGH languages and paradigms more creatively.



I agree with the sentiment, but it's less practical than React, etc.

Some problems with vanilla custom elements: You can't pass around objects, you have to handle DOM updates manually and elements must be uniquely named.


All false statements. Of course you can pass around objects. It's plain JavaScript. You write modules using design patterns that allow you to do this. DOM updates, don't have to be manual. See Observer Pattern.


I think a lot of this is addressing problems that aren't really relevant anymore. Yes, it'd be nice if we could all come together and hold hands and agree on better standards for fundamental parts of front-end...but there's never going to be full agreement on what those standards are. And that's fine!

The modern front-end landscape benefits tremendously from the plethora of options available. It's not a one-size-fits-all world. Some developers may click with the "we are building serious apps here" approach of Angular, some maybe like the flexibility-with-first-party-support of Vue, and some people like me love how React gives you a start and says "go figure the rest out." And that's just the three big ones.

If you or your team is having issues choosing with the technology stack, and feeling overwhelmed, that's certainly valid - but it's also a fundamental part of software development, not something new or unique to front-end. Having all of these choices means having to need to be familiar with the pros and cons of each, and making an informed decision from there - this is an excellent skill to have as a developer. A necessary one, even. Note that this does not mean you have to be an expert in 50 different frameworks, that's a strawman that isn't remotely realistic.

Framework churn hasn't really been a thing for...years, now? Which is eternity in web dev time. The only notable framework that I've seen people thinking about jumping ship to is Svelte, and that's because it 1) does the technical bits differently and 2) offers a brilliant API. Long gone are the days of "ha ha JavaScript has a new framework every week."

This isn't even touching on how the browser itself is a problematic platform...because Google, and Apple on iOS, basically dictates everything. See Edge moving to Chromium. Until that elephant is addressed, the room isn't remotely equipped to deal with implementing agreed-upon standards that can be "free" of inordinate influence from one particular company.

All said - this is a great perspective on the importance of standards in general. We of course need them, and as mentioned we have some amazing ones via WC3, WCAG, and TC39. But I just don't think web components, as they exist today, are the solution, nor is the current framework landscape really much of a problem.


Standards come from standards bodies and are actual when implemented to a certain extent by multiple engine vendors... There's not much ambiguity in what the standards are. Try again.


Although I am a fresher in here, but this blog confused me in a good way, I am practicing Javascript to learn react for the same reason as you explained above, should I still go for react or is there any other programming language should I pursue??


1) ReactJS is not a programming language
2) Learn the basics of javascript
3) Learn the basics of html
4) Learn the basics of css

People will tell you no its okay to learn reactjs first. You can do that but in the history of coding frameworks would die after some time but the basics of HTML/CSS/JS are still the same as they were 20 years ago. Yes, they evolved and changed a little bit but still, they are the basis for every framework. It will also be easier for you to learn a new framework because they will build on the same fundaments


I feel nunjucks or other templating languages (like pug) are better. We can do what react and angular does and also we can dynamically include images/files from a folder with straight forward code which just pre-compiles with nodejs. Now, I am using react because of scss + css modules. Hopefully will try to come up with nodejs+nunjucks+webpack+scss+css modules soon.


I need to checkout nunjucks.

This is the first time I hear about it.


It is just a template engine library available to compile htmls with nodejs and on runtime. IMO, a huge advantage on react. This is not what web components does but can be combined with it to have full control of web development.


Obviously written by someone who has never worked on 100k+ line of code projects where everybody needs a beacon to rally around. In a perfect world there is one solution, in our world people like different things and different teams get along better with different frameworks.


Why do you assume I have never worked on a project that big?


Isn't this how languages and tools have come about? Multiple developers come up with their solutions, which inspire other, "better" ones. They take features from one another and eventually a winner emerges. Why rush a transition now? Maybe the solution should be you build your own framework designed to take the best features of these and address their weaknesses. Maybe that becomes the new standard.

A lot of good (useful?) options isn't a bad thing.


I'm not against having multiple opinions even with web components you would still have them.

It is more like today you could take the react-router and use it with vuejs and vice versa!

Maybe I'm also dreaming to much :)


You've started an interesting article. I look forward to the next one.
I get your point about the standards being a better way to develop for the web.
When I first started learning react, I got this feeling of absurdity.

I started with html in '99.

It was like most of this is meaningless after you build the project!
It compiled into minified code completely unreadable.
I also got concerned with the future of these frameworks and quit learning react. I chose Vue instead. Mostly because I don't trust fb and Angular showed me what any of these frameworks could become.

I'm not completely convinced of Vue either, I like how it's not owned by one of the big three. These frameworks essentially do the same thing, just slightly differently.


I don't know where I go with this series

I did not think that it will get this much attention.

I'm now developing web things since 2006 and I have seen this cycle several times now.

But in the end, what has been always there were the standards.

Even if Javascript now is not what it was 10 years ago it is still mostly the same just with more features.


That's interesting point of view. After working for over three years in the javascript ecosystem i feel the fatigue myself. Honestly, what i feel is that most developers get distracted due to the shiny object syndrome. We tend to choose a technology primarily due to hype created around it and then spend a lot of time on things that don't matter (for the business).

For example, with ReactJs i've had a lot of problems with routing and middlewares. Using frameworks like redux also doesn't make things easier. Now i spend most of my time debugging frontend bugs rather than working on the critical business requirements.

It works fantastically when you're doing simple apps, but when it comes to building complex applications like ecommerce, or crm, i've been struggling with these frontend technologies. For me as an entrepreneur, spending more time on the frontend than on the backend is worthless.

I'm not sure about web components either, because as soon as it starts becoming popular, a lot of big players are going to jump into it and there'll be multiple (and most probably broken) implementations of the same components.

I'm not against these frontend frameworks and libraries, but again i'm not going to suggest these to my clients just because of their shiny appeal or hype. I personally only use python and flask to develop web apps and stick to simple templating engines. It's made my life easier. But that's just me.


Maybe web components are not the perfect solution right now.

But looking back at the history most of the time standards in the long run won over frameworks.

And yes using reactjs for a static website is a bad choice just to give one example.


I'm using yii framework with controllers, web components and modules. It's much safer, more stable and performs better than wordpress. Nevertheless I still feel bootstrap, jquery and a myriad of other libraries are necessary


Very interesting setup


I think the issue comes in to ways:
A company wants people in the same page, so they settle on one approach. This can be ok since most companies probably need one solution.

But a tech company should know many frameworks.

Then there's personal. I think it would take most devs a few years before having the experience required to differentiate and use the right framework for the right tools. And programming moves so fast, some options might no longer be relevant once you're ready


I agree fully with you.

I also think we as a community are following the hype to much.

dev.to itself is written in ruby on rails.

It does not need react hooks or agular X to work good.

It works fine with ruby on rails even if ruby on rails is not the newest hype!


Your article perfectly sums up what I believe the goal of the Aurelia JavaScript framework is. To abide by emerging and pre-existing browser standards, not invent new ones or ways of writing code (I am looking at you React and your JSX).

All frameworks and libraries should share the same goal: to eventually be replaceable by native API'S. But, let's be honest. React and Vue are so far removed from real JavaScript and HTML, that will never happen.

Concepts like the Virtual DOM (a glorified dirty checker), sound cool from a marketing perspective but are not as performant as developers make them out to be.

Sadly, the Web Components specification seems to be a mess. I have hope one day it will turn out as well as ES6 did. Until native API's and specifications align more with the requirements of modern front-end development, we'll continue to see these abstractions and bastardisations of the language continue to be popular.


"The problem is that every framework, like ReactJs, Angular(JS), VueJs, or some other smaller UI framework, uses its own patterns and solutions to common issues. "

I believe React and Vue is not a framework. Also, if they solve common problems the problem, what's the problem with that? It's similar to design patterns solving common problems. It's well tested overtime.


I understand why we have all these frameworks, but I don't like it either. Whatever "correct" is, this wouldn't be so bad if everyone used them correctly. But the number of frameworks multiplies the ways to do things badly. Like when you encounter Angular with weird stuff hacked in where it didn't belong because someone didn't know any better.

It takes less effort to use something, but way more effort and experience to be able to look at code and recognize what's wrong so that you can fix it and avoid piling onto a mess.

I'm concerned that developers are learning just enough of one to make a giant mess, realize that it's out of control, blame the tool, move on the the next one, and repeat. Every time that happens they leave something behind that lives for years for someone else to come along and maintain.

That's my view of the problem, not a proposed solution. I'm leaning towards Blazor. Not that it's better, but because I've got a way better chance of looking at it and knowing what's right and what's wrong. In past experience I've also noticed that ASP.NET MVC code is slightly less likely to turn wild west than JavaScript, so I'm a little bit optimistic that I'll encounter less unmaintainable stuff.


While I fully understand the sentiments here, I think the article may have lost sight of WHY frameworks and libraries like Angular, Vue and React exist in the first place. I really love the idea of true open, complete standards. I can't wait for the day when we can build pure standard components, when PWA is the only kind of app, etc. Wonderful dreams! Lacking in reality, though, most of the time.

There are reasons why we have frameworks like Angular and Vue, though. Why we have libraries like Polymer and LitElement. To one degree or another, the core standards usually don't go quite far enough to really provide a complete solution that does not just solve a particular problem, but solve all the problems on the table, as well as support the infrastructure of validating them, deploying them, and keeping them maintainable, etc. They tend to lack opinions where opinions are useful, and often lead to "wild west" style projects that lack cohesion, consistency, etc. that can leave projects rather messy and unique (i.e. not easy for future developers, long term maintainers, to take on even if they have general experience in "Library/Standard X").

React in and of itself isn't even a framework. It is a library. And React itself is usually not enough to get the job done on its own. You will usually find other libraries glued together in a React product because of this shortcoming. Similar problems usually arise with "plain old web components", as they solve a problem, but are not a complete solution.

Angular gets a lot of rap from...many on the other side of one fence or another. The big thing Angular has going for it, though, is a consistent, reliable, and effective pattern for designing, building, deploying and maintaining simple apps through large scale, enterprise scale, applications. I think Vue is coming a long way down that road now as well.

These frameworks are complete solutions to business problems and the process of solving them, not just a solution to a particular problem inherent in leveraging the web as an applications platform. Components are a part of the machine, but not the whole machine itself. In real-world product development, we usually need The Whole Machine. ;) Further, that consistency and cohesion provided by a framework like Vue or Angular has solid benefits for long term projects that may move through many developer hands or many dev teams over their lifetime.


React, Vue and Angular are stepping stones and imperfect visions that brought components to developers in a cohesive way for the first time. I don't think the problem is we don't have the entire developer pool writing components for a unified compatable component scheme; that's not really how the web works. All of these frameworks already have robust calendar components out there, but everyone has a different functional requirement when it comes to actually implementing a component like a calendar that beyond the bare-bones, adding more features is only going to annoy people by bloating their code and project complexity. Even if we were all writing the exact same code, like in standard programming languages, you never see people really get together and build the "grand calendar" program, you have 500 and each operates differently in some specialized way. So while it may be odd we're all currently segregated into different libraries, it's promoted incredible progress and feature adoption that the web standard will need exponentially more time to implement. A standard underlying component structure is fine, disliking everyone working on various libraries is against the fundamental nature of an open-source community.


In the end all these frameworks are plain old javascript and HTML and CSS

The browser HTML rendering engine does not understand reactjs components.

It only understands simple dom manipulation.

So we technically already targeting one platform it is called HTML and JS


I think there's a good reason for why so many frameworks exist. It's rare to find developers that truly think/code the same way. A Java/C++ developer looks at JavaScript with disgust, but TypeScript makes sense to them. The same thing happens on the frontend.. Angular makes sense to those of us that have been with it since the beginning, but we look at React and get headaches trying to figure it out. However, VueJS not so much, it's a simpler way to do what Angular can do, without all the drama.

Newer developers don't seem to have an issue with writing HTML inside javascript code blocks, and so they lean towards React. Those people clearly dip their chocolate chip cookies in the Ketchup. But hey, to each their own.

At the end of the day, you go with the method/framework that you can wrap your head around, without making you look like a fool.


When I started web development you would be in the hall of shame if you would mix HTML and js and CSS.

It was an anti-pattern.

I still think JSX is not the right way to go.

That's why I like for example sveltejs more.

And yes everybody should use whatever he or she likes!


You should be asking a different question. It’s like the question of it you should work hard or if you should work smart...

I don’t know about you, but I work both.

And when it comes to learning Angular or React, the same is true. If making the outcome of the decision between the two is important to you, if you don’t learn both you’re just being lazy.

Take an afternoon and run through the hello world tutorials for both React
and Angular and you’ll get a whole lot more context of what each is doing.

Then, you can make an informed decision based on the aspects of the framework instead of using silly metrics that don’t matter like number of cream chargers searches, etc


Web components evangelists: ditch frameworks! It's a standard!

People in reality: "why use CSS Grid when we always used div?", "React is too hard, I'm fine with jQuery", "we need support for Internet Explorer 11 because the clients use it, and x product is only certified for it", moving to React/Vue/Angular like they're shiny hot new toys (from 2013 or even earlier). I even recently discussed with people who find ES3 just as good as ES6. Lol. Companies with internal policies like "no NPM, no Babel, no transpiling, no pipelines" who have to support the oldest browsers around.

Never mind the fact that I've been working with React since 2016 and little to nothing really changed since, and I've not really been tempted to move away from it. People in reality isn't all first year CS students. Angular, Vue, React, all are solid choices that are here to stay for a while.