loading...

The Cost of Investing Too Heavily in a JavaScript Framework

Ryan Smith on January 13, 2020

🤠 "What Framework Should I Learn?" Trying to decide what framework to learn is a common question, but there is no clear winner. The comm... [Read Full]
pic
Editor guide
 

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.

 

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

 

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!

 

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.

 

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.

 

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.

 

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.

 

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.

 

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

 

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.

 

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

 

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.

 

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.

 

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

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

 
 

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.

 

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

 

Thank you!

 

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

 

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.

 

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.

 

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.

 

Thanks for the great article!

 

You're welcome, thank you!

 

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

 

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.

 
 

Thanks, I'm glad it helped!

 

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 🚀

 

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.

 

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

 

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.

 

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?

Code of Conduct Report abuse