DEV Community 👩‍💻👨‍💻

Cover image for The Cost of Investing Too Heavily in a JavaScript Framework
Ryan Smith
Ryan Smith

Posted on • Updated on • Originally published at

The Cost of Investing Too Heavily in a JavaScript Framework

🤠 "What Framework Should I Learn?"

Trying to decide what framework to learn is a common question, but there is no clear winner. The common, uncontroversial answer is "You can't go wrong, they are all great frameworks." They are indeed all great, but I think you can go wrong by investing too heavily in a framework.

I struggled with deciding what framework to learn and jumped back and forth between them for a while. My concern was that learning a specific framework would limit me to only using that framework. I could not confidently advocate for a framework knowing the churn of the JavaScript ecosystem. I wanted to learn something that could transcend the divisions between frameworks. Learning is an investment and I'm not a gambler, are you? 🃏

📊 Framework Fragmentation

Libraries and tools evolving is the natural progression of the web, but framework usage changing over time creates fragmentation among websites. There are sites built with old libraries such as MooTools, jQuery, and Backbone that are still in production today. Those sites will continue to work, but using them may not be preferred by developers or the libraries may not receive any new updates. Also, the components written for older libraries cannot be used in modern libraries.

Similarly, components built in a modern framework cannot be used in another. There is a split between modern front-end frameworks like React, Vue, and Angular that goes beyond developer preference. A full component library created in React cannot be easily ported to Angular.

  • "What's the problem? We can just rebuild those old Angular apps to use React."
    • You could, but rewrites can be costly. The Angular apps work fine and another team in your company may prefer using Angular for that project. If it ain't broke, don't fix it.
  • "Okay, we'll just implement the same components in Angular and React."
    • Now you have two codebases that do the same thing. Any updates are double the work or you run the risk of those codebases becoming out of sync. Don't repeat yourself.
  • "Maybe we can separate the styles from our components and import in React, Angular, or any other framework we decide to use."
    • That sounds difficult to maintain and you would still have to repeat yourself. You have to reconstruct most of the component's markup and functionality. Why use a custom solution to do that? Keep it simple.
    • This was the approach taken by Google's Material Components for React, we will see how that worked out later in the article.
  • "Well then what do you suggest?"
    • Use what the web platform gives you. 🌐

📚 Web Standards

Around the time I was researching what framework to learn, others were advocating for using a standards-based approach with Web Components. The reasons for Web Components sounded appealing to me and would address my concerns about being locked into a framework that may not survive the test of time. The problems I ran into were the negative opinions surrounding them and how to use Web Components effectively. I found that the initial pitch was appealing but trying to put it into practice was confusing and left me with a lot of questions.

  • Do I write plain standards-compliant JavaScript?
  • Do I use a basic library to make it easier? How do I build a full web application with it?
  • Do I use a library to compile to standard Web Components?
  • There are a lot of libraries, how do I choose?
  • Wait, why am I researching different Web Component libraries, isn't this what I wanted to avoid?

I tried to answer these questions in my research and wanted to share what I learned here.

🌉 Build on a Solid Foundation

I started learning basic HTML, CSS, and JavaScript 20 years ago and most of the fundamentals are still valid today. The web moves slowly. Standards that are implemented in the browser will not change overnight. There are committees to decide what features to add. Each feature goes through stages before it is officially part of a standard. Because of this, new standards move slowly and obsolete features may never be officially deprecated, so they will continue to work for backward compatibility.

That is still the case today. The standards that make Web Components will not disappear in 3-5 years. Can you say the same for your framework of choice?

🐎 The Framework Wild West

Frameworks are not bound to a standards body, which means the framework can introduce breaking changes at any time. An example is transitioning from Angular 1 to Angular 2. Existing Angular apps required a significant refactor to be ported over to Angular 2. The Angular community was upset about that but there was never any agreement or guarantee that things would always be the same.

Facebook builds React for Facebook. If they need to change it, they can do that. Just because the code is open source does not mean that their interests are open source. Again, there is no agreement or guarantee that they won't pull the rug out from under you.

Frameworks can also become unsupported over time. You can still use old frameworks and they will work, but eventually, there will not be any more updates to the framework or updates to community-maintained packages. That can affect a team's productivity if a bug in the framework or package will not be fixed. This could also affect the potential to attract new developers and keep them if developers do not want to be stuck using an outdated tool.

⚙ Not-so Reusable Components

Reusable component libraries written for React or Vue only work in those frameworks. If your company implements a design system and uses React for the component library, what happens when a new project decides not to use React? What happens when the next React introduces fundamental changes or the next big thing is a different library entirely? That polished component library that your team spent years building will not work in the new framework. If you want to continue using it, you will be stuck on older technology. If you want to move to new tools, that component library needs to be rewritten.

Google began building reusable components for Material Design. The React version used an approach of importing styles from Material Components Web (which is the Bootstrap-like version, not the Web Component version). The .scss file for each React component typically only contained an import statement that imported the styles it needed. Then each component was rewritten with everything else that could not be imported into React components such as markup, properties, and component state. This approach was problematic because if the core of Material Components Web changed, the React version may have also needed to be fixed or updated to accommodate those changes. I think the team behind it began to realize that these should be fully reusable Web Components and decided to focus on those because they are independent of any framework. They passed off the React version to the community.

"MDC-React is no longer under active development.

We created MDC-React in 2018 to implement the updated Material Design guidelines. Since then, the open-source React community has embraced the new guidelines and created a number of excellent unofficial implementations. See Material Design Components - Web Framework Wrappers for a partial list.

In order to increase our focus on implementing our core, framework-independent libraries (MDC-Web and MWC), we’re passing the Material+React baton back to the community. That means Material Design will no longer be updating and maintaining this repo. We recommend that you switch to another implementation and keep building beautiful, usable apps based on Material Design. Thanks for being part of the project!" - Google's Material Components for React

I would not bet on React being the top framework a few years from now, but I would confidently bet that the browser standards will remain backward compatible. With frameworks like Vue and Svelte on the rise, can you confidently say that you will be writing React code in a few years?

🔮 Web Standards Will Not Replace Frameworks (And That's Okay)

I'm not suggesting ditching frameworks for Web Components. Frameworks are good because they can freely innovate where browser standards cannot. The aim of using a standards-based approach is not to replace frameworks, it is to augment them.

  • Build your reusable component library and use it for the foreseeable future, no matter what framework. Or use it without a framework.
  • Teams across your organization do not have to implement the design system in their framework, they can use their framework of choice and use the existing component library.

"React and Web Components are built to solve different problems. Web Components provide strong encapsulation for reusable components, while React provides a declarative library that keeps the DOM in sync with your data. The two goals are complementary." - React Documentation.

Web Components + Frameworks, not Web Components vs. Frameworks

🔧 Embrace the Tools

Web Components by themselves are not good enough. You might be thinking, "Aha! Frameworks are better!", but not so fast. Standard Web Components are missing some key features and the modern developer experience that framework users have come to expect. This is a common criticism of Web Components. Luckily, there are tools out there to help ease these pain points.

Because there are many libraries to choose from, tools built to target web standards may also seem fragmented. There is Stencil, LitElement, other lesser-known tools, or standard Web Components. The key difference between Web Component tools and proprietary frameworks is that the output produced by the Web Component tools will be more future-proof. If your team decides to use React, then switches to Svelte for another project, Web Components can make that transition without those components being rewritten. If your team needs to put together a simple app, Web Components can also be used without any framework.

The idea is not to go completely standard and stop using tools because there are too many, the goal should be to target web standards to help make the work you are doing more future-friendly. This will result in fewer rewrites because those components will work anywhere. This will also give you the flexibility to migrate to the next big framework because your existing components can come with you.

🎯 Summary

  • You can't go wrong with any modern front-end framework, but you can go wrong by investing too heavily in them.
  • Having choices in frameworks helps move the web forward but it also fragments it. The hot framework today may not be the hot framework tomorrow.
  • By investing in web standards, your front-end will be more future-friendly.
  • Framework authors are not bound by standards, they might pull the rug out from under you.
  • Reusable component libraries that are built in a particular framework are only reusable within that framework.
  • Web Components will not replace frameworks, but they complement them nicely. You can have reusable components and use the latest and greatest frameworks.

📖 Resources


  • Stencil - Stencil is a tool for building reusable design systems. It generates standards-based Web Components and provides a virtual DOM, asynchronous rendering, reactive data-binding, TypeScript, and JSX. This was the top write-in answer for the 2019 State of JavaScript Survey - Front End Category.
  • LitElement - LitElement is a base class to make it easier to create Web Components. It is ideal for sharing elements across your organization or building a design system. Use your components in an HTML page or a framework like React or Vue. This was the number two write-in answer for the 2019 State of JavaScript Survey - Front End Category.

Articles & Links


  • Web Components in Action - This book covers how Web Components are a standardized way to build reusable custom elements. It includes how they are encapsulated to keep their internal structure separate from other elements. It goes through designing, building, and deploying reusable standard Web Components.


  • Bet on the Web - A podcast from the Ionic team about the web platform.


💬 Did I miss something? Have a different opinion? Leave a comment below!

Top comments (33)

victorioberra profile image
Victorio Berra

This approach is very close to the ideals of Aurelia's main guiding principal is to be standards-based. Plus they focus on your business logic being the center of your app.

So in the end your view-model is a simple Vanilla JS class and your view is a standards-based HTML templates.

beggars profile image
Dwayne Charrington • Edited on

Aurelia user (and core team member) checking in here. This is exactly the goal of Aurelia and always has been since it debuted in January 2015. It has a simplicity that no other framework seems to have because of convention over configuration.

I also think another point worth mentioning is the fact Aurelia supports Web Components, so you can truly write spec-compliant Javascript applications in Aurelia that resemble something closer to Vanilla than the likes of other offerings out there.

In 2020 after Aurelia 2 is released, I think more people are going to realise the power of Aurelia. Furthermore, I also think given the interest people have in Svelte, developers are yearning for simplicity and less verbosity, something that has been missing since jQuery hit the scene over ten years ago. Aurelia is simple enough to get out of your way but powerful in its features to be there when you need a feature (routing, state management, validation).

ryansmith profile image
Ryan Smith Author

I haven't had the chance to check out Aurelia, it is an interesting concept. It looks incredibly easy to pick up if you know some JavaScript. I will have to try it out sometime, thanks for sharing!

weswedding profile image
Weston Wedding

Wait, why am I researching different Web Component libraries, isn't this what I wanted to avoid?

This part made me laugh because this was exactly my thought process when experimenting with Web Components during a project. I was thinking, "yeesh, I need to find a library or something, this is kind of a pain in the butt!"

And then I felt like I was just shopping for a WC framework when I was doing WC to avoid the frameworks issue to begin with.

ryansmith profile image
Ryan Smith Author

Yeah, I could see how the experience might generate negative feelings about Web Components. I think proponents of frameworks would have difficulty trying them, see that the tools are like learning a framework and wonder what the point of that is, then go back to their framework of choice. Hopefully, this post will help change the perception a little bit.

tomekbuszewski profile image
Tomek Buszewski

Oh boy.

"The web moves slowly. Standards that are implemented in the browser will not change overnight."

This should be printed and put in every single IT department out there. I had a discussion on Friday about the new landing page. And here we go – "let's use Gatsby, Styled Components and some Redux, pair it with some headless CMS and have full deployment cycle". For a simple text page with ONE subpage.

Great article man, a little long, but great. Thank you.

mpuckett profile image
Michael Puckett • Edited on

I agree - this is the future!

Unfortunately, recently, I ran into some interesting quirks when trying to pass properties between a Svelte-compiled web component and a Vue one. Also noticed that the frameworks either don’t support compilation to web components by default or if they do the authors don’t seem very keen about the platform (evidenced by the Rich Harris link)

Personally I would like to see us developers rally around web components and force the frameworks to play nice.

The good news is Shadow Parts is now in 2/3 major browsers (yes it’s Safari) which will make using them a little more appealing I think.

ryansmith profile image
Ryan Smith Author

I agree, it seems that the compile to web components in Svelte and Vue is an afterthought. I can see the challenge there, they built their framework before compiling to Web Components became more prevalent, so all of the framework features may not translate nicely to a web component. Since Stencil built that way from the start, they can do it more effectively.

evanplaice profile image
Evan Plaice • Edited on

Finally! Somebody else said it. I feel like I've been shouting into the void for the past year.

Great write up 👏👏👏

As far as vanilla web components go. I'd be willimg to bet that for every 100 negative takes on them, there's maybe 1 dev who has actually tried.

That's why I created an org entirely devoted to Vanilla Web Components. Why? Literally nobody else in the entire world has done so yet.

gablaroche profile image
Gabriel Laroche

Great article! I usually don't bother learning frameworks or libraries in depth, because I know they won't last. I just learn the standards on my own time and if I have to use a new framework or library for work, then I won't have too much trouble picking it up.

ryansmith profile image
Ryan Smith Author

Thanks! Agreed, knowing the fundamentals is a solid choice and allows you to adapt easily to new tools.

afsharm profile image
Afshar Mohebi

Nice advice to focus on standards than on frameworks. Also, enjoyed the term future-friendly so much!

Personally, I prefer to keep the front-end layer light so changing it cost less. In other hands, I tend to give more consideration to back-end.

DISCLAIMER: I am mainly a back-end developer.

jcarlosweb profile image
Carlos Campos

I totally agree, both Stencil and LitElement are impressive, the only small problem I see is that there is no adaptation of component libraries such as Boostrap, Ant Design or

But yes, we have to think about using these libraries before React, Vue or Angular.

And of course we don't have to complicate what is just HTML and a little bit of Javascript in some cases.

dakmor profile image
Thomas Allmer

maybe add - it's a good resource to get started 🤗

PS: I am biased as I am involved in the project 😬

ryansmith profile image
Ryan Smith Author


andrewdc profile image
Andrew Colclough • Edited on

I recently started a new job that was looking to begin building a universal design system of UI components. In the past, building a system locked into a framework end in crippling technical debt and problems. Sometimes, we were completely blocked from upgrading to new and needed features, because the expense and breaking changes to our supported applications was simply too costly.

With all of that in mind, I did a bit of digging this time, trying to find an answer to this costly problem. LitElement was promising but required more integration that I'd like. (For instance, getting litElement into a WebForms app...oh goodie).

Ultimately, we decided on Svelte for our org's component design system because we can distribute compiled javascript packages that expose a simple API for other apps, stacks, and teams to consume. It certainly requires some technical hurdles to distribute, but the payoff is huge, as we can incrementally update, change, or upgrade components (bulk or individually) and push them out to consumers. And, because they are compiled to straight-up javascript, the other teams require no dependencies, other than some basic configurations.

Plus, Svelte's architecture is very simple and straightforward. You get a lot out of the box, and it doesn't require a huge amount of overhead to get going with. Of course there are weaknesses to this approach, as all things have trade-offs. It's all a bit more bleeding edge than I am typically comfortable with. We have already started to compile a list of best practices, and things to avoid. But because Svelte's components are compiled, what is delivered is technically framework agnostic.

Thus far, we are pretty happy with this choice, but are still early on in the journey. I'm not a Svelte pitch-man, but it has helped to answer this difficult question for now. I'd love to hear if anyone else is moving in this direction.

codemouse92 profile image
Jason C. McDonald

A fantastic, reality-grounded take on the issue! Bravo,

ryansmith profile image
Ryan Smith Author

Thank you!

s0meon3 profile image
Gabriel Corrêa

Good article! I think the key to this is, if you're going to learn about more than one library you should learn them separately. Choose one, master it and after you know you can use it to create big projects you go to another.
For example, you started learning React and mastered it, then you went for Angular. But while you are learning Angular you should still build, small and less often, React projects. We forget about things that we don't use. :)

ryansmith profile image
Ryan Smith Author

Thanks! I think mastering a framework then moving on to the next might be spreading yourself too thin. I'm more of a "just-in-time" learner, I pick up things when I need to use them or if I have a strong interest in it.

slash84 profile image
Giorgio Mandolini

I completely agree with the concept of investing both in frameworks and in web standard. A book that I strongly suggest reading is "Frameworkless Front-end Development" by Francesco Strazzullo ( In the book, the author explains how to work without frameworks, just using standard web technologies. The book also provides a chapter about Web Components.

jankapunkt profile image
Jan Küster

Just try on your next project to write as much as code as possible without the frondend library but using vanilla js. You wouldn't believe how far you can go.

webpadawan profile image
Serhii Kulykov

Thanks for the great article!

ryansmith profile image
Ryan Smith Author

You're welcome, thank you!

Some comments may only be visible to logged-in visitors. Sign in to view all comments.

This post blew up on DEV in 2020:

js visualized

🚀⚙️ JavaScript Visualized: the JavaScript Engine

As JavaScript devs, we usually don't have to deal with compilers ourselves. However, it's definitely good to know the basics of the JavaScript engine and see how it handles our human-friendly JS code, and turns it into something machines understand! 🥳

Happy coding!