loading...
Cover image for The Cost of Investing Too Heavily in a JavaScript Framework

The Cost of Investing Too Heavily in a JavaScript Framework

ryansmith profile image Ryan Smith Originally published at ryansmith.tech Updated on ・9 min read

🤠 "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

Libraries

  • 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

Books

  • 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.

Podcasts

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

Talks

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

Discussion

pic
Editor guide
Collapse
victorioberra profile image
Victorio Berra

This approach is very close to the ideals of aurelia.io/ 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.

Collapse
beggars profile image
Dwayne Charrington

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).

Collapse
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!

Collapse
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.

Collapse
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.

Collapse
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.

Collapse
mpuckett profile image
Michael Puckett

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.

Collapse
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.

Collapse
evanplaice profile image
Evan Plaice

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.

github.com/vanillawc

Collapse
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.

Collapse
ryansmith profile image
Ryan Smith Author

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

Collapse
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.

Collapse
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 element.eleme.io/#/en-US.

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.

Collapse
dakmor profile image
Thomas Allmer

maybe add open-wc.org - it's a good resource to get started 🤗

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

Collapse
ryansmith profile image
Collapse
andrewdc profile image
Andrew Colclough

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.

Collapse
codemouse92 profile image
Jason C. McDonald

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

Collapse
ryansmith profile image
Ryan Smith Author

Thank you!

Collapse
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. :)

Collapse
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.

Collapse
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 (apress.com/it/book/9781484249666). 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.

Collapse
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.

Collapse
webpadawan profile image
Serhii Kulykov

Thanks for the great article!

Collapse
ryansmith profile image
Ryan Smith Author

You're welcome, thank you!

Collapse
sebbdk profile image
Sebastian Vargr

Even AngularJS when done right can perform decently and have good structure if used the right way.

Tho i would probably rather quit my job then start a new project in AngularJS. :)

Collapse
ryansmith profile image
Ryan Smith Author

I agree, a tool can be used effectively and get the job done, even if it is outdated. But it is good to consider support before starting a new project.

Collapse
ahmednrana profile image
Rana Ahmed

An eye-opener

Collapse
ryansmith profile image
Ryan Smith Author

Thanks, I'm glad it helped!

Collapse
jamesmfriedman profile image
James Friedman

I appreciate your article and I need to add a bit of color to your commentary about material-components-web. I’m actually the maintainer of RMWC rmwc.io , the community framework that google mentioned in their goodbye post.

Making the assessment that mdc-react was abandoned because frameworks are bad is an incorrect hypothesis, although I understand how one could draw that conclusion. The truth is, Google is the biggest smallest company out there. They still have internal politics, teams that shift, and they’re notorious for killing things off at random. mdc-reacts plug was pulled for a variety of reasons, but most of them were non-technical in nature.

Web components is a framework, like it or not. Write enough custom vanilla JS and you’ll likely have created a framework of your own. They will definitely come and go, but I doubt the web component that was written 5 years ago will need any less refactoring than your React or angular app.

In my quest to become the most infinitely pragmatic dev, I’ll tell everyone: write code using whatever tools you need to solve your problems that you and your colleagues can agree on. Good code is code regardless of what framework you use. Also, I’ve been around long enough to know that in 5 years, some new guy or girl will be cursing your name no matter what “bulletproof” tech you choose today :). Happy coding everyone, keep solving the problems 🚀

Collapse
khrome83 profile image
Zane Milakovic

I think the future is a standard, like web components.

My concern is that the standard we got is lacking. It forces many things into JS, which is the same issue we have with these massive frameworks.

I have seen apps that are built with React, and meet 100 percent desktop, and 87-92 percent mobile page speed score.

Yet in certain parts of the world, it took 20 seconds to load. Mostly because of the poor hardware on the users device, and the time it took to parse the JS bundle, which was 700kb.

The sad part, this region made up 40 percent of the users nationally.

Where the other users would load the site sub second.

It really made me rethink how we put css in js, and hydrate components that are not reactive, and in general move more and more resources to the client.

Web components don’t really solve this. It’s more of a symptom of our change in how we build for the web. For better or worse. The older spec was much better, but Safari killed that.

Collapse
ryansmith profile image
Ryan Smith Author

I think websites can be performant, even if JavaScript is doing a lot of the heavy lifting. Stencil provides a pre-rendering mode, which will generate HTML/CSS with the default properties. Your site will serve up the static HTML/CSS and then JavaScript will download to re-hydrate it. This means that sites can also run without JavaScript, so you get the best of both worlds. I have it enabled on my site if you would like to take a look. ryansmith.tech

Collapse
khrome83 profile image
Zane Milakovic

This does not change my opinion.

I mean I run sites on Gridsome, Next, and Nuxt. All do this as well.

You always end up with some functionality for interactivity that’s requires that bundle.

Sometimes you can split that out. But I have ran into situations where I can’t.

So you still end up with a expensive JS bundle the user has to download. This really depends on the sites complexity. But I saw marked improvements switching from React to Svelte for a product. But things like a non reactive header still gets wrapped up in the hydra table and JS template instead of just HTML and CSS from the server. We just don’t have a clean way to split this out yet.

The SSR for stencil is a good thing to do.

Collapse
bobmyers profile image
Bob Myers

Stencil and lit-html are not "libraries". A "library" is not a compiler. Libraries and frameworks are different.

You make it sound like "learning" a framework is a binary thing--you either learn it or you don't. In reality, becoming acquainted with a framework is an ongoing affair, almost always related to the framework I am using in my work, and the deeper I go the more productive I become. It is not realistic to assume that most developers can actively pursue multiple frameworks; they will have one "main" framework, and their knowledge of other frameworks will be limited to what the read in blogs or toy projects.

So what exactly is it you are saying again?