Evaluating front end frameworks and not choosing any (opens in new tab)

> the [Svelte] user base is very small compared to the react world. In the end, we judged svelte too risky to depend on.

So your custom framework user base is much bigger than Svelte's or is it just you and a couple people on your team?

Here are some actual criticisms I have of Svelte:

Rich Harris thinks it's fast because it doesn't use a virtual DOM. No, it's fast because V8 speed has increased dramatically since React found a virtual DOM necessary. Now React is stuck with it's virtual DOM. But sure Richard, take the credit for being fast if you want.

A command line tool to parse some text based .svelte files and assemble them into regular browser files is almost trivial, not rocket science. Adding hashes to the CSS identifiers to namespace is also not hard.

Data binding and reactive programming are part of the observer pattern in the Gang of Four book. Rich Harris invented some sugar reactive syntax, but more power to him. I just don't think Svelte does that much.

Edit: Rich not Richard

> VueJS is smaller, around 30kb, but not that small. Also, it is very opinionated and we don’t want to force people of the future to use VueJS.

I don't understand what the criticism is supposed to be here.

> First, we lost compatibility with a couple of tools that we really wanted to use. One of them was storybook, that is a super-nice preview system. We had to develop our own frankenstein to do the same.

> Our choice does not need anyone to learn anything, and one can create a widget in no time!

As someone who made the mistake of writing their own internal framework, I tip my hat to you.

You just created your own framework that people now have to learn. And best of all, the documentation is always going to be less detailed than what you'd get with popular frameworks.

Discarded React because it takes 120K?

The background image on his blog post is 168K

https://michelenasti.com/images/bg.jpg

> Less bytes sent -> less energy used -> greener planet

So was their basis of choosing that low bundle budget solely around reducing carbon emissions? I’d really like to see their math on that. I looked for a calculator that would try to estimate it, but couldn’t find one. If anyone know of one, please reply.

I imagine a lot will depend on how many users there will be for it, but how big of a difference could there be? If we’re talking 1 million users per month, what will the difference between 15kb and 150kb look like? Are we on the scale of emissions of a couple dozen cars, or pack of coffee filters?

I would expect it’s important to figure that out before spending “months” making a decision. At the very least, if you’re making a blog post about it, you should try to figure that out because right now is sound like “we spent a lot of time figuring out the smallest possible bundle size we could have because something something greenhouse gasses.”

This is like building your own car because the Camry doesn’t have enough cupholders and the Civic looks kinda funny.

I'm working on a massive Angular 13 project and I love it.

There are reasons for choosing "front-end frameworks" and once you get into Enterprise-level territory you start to see why.

I'm both front and back and Angular is hitting the sweet spot with our developers who come from OOP backgrounds and can grasp TypeScript at a glance and don't get scared by compiler errors.

So you evaluated a whole list of things against your requirements, then chose something not on the list of things evaluated that didn’t meet your requirements?

Why the need for hooks for preact - hooks are the worst part of the react system. They are not necessary at all.

Interesting. Ultimately for me the size of a library/framework isn't really a great argument if the web app is javascript intensive, since my own code might be 5 or 6 times bigger than the framework itself.

The "legacy/debt" issue is more interesting matter. React and Angular are obviously big right now so most shops go with these.

But I explored the best ways to front-end without any framework, what would be the minimal boilerplate to deal with views and trees of components.

Webcomponents are OK for components but they don't really solve all problems React solves, like component aggregation, updating a component tree easily, and of course, testing without having to fire a browser instance (testing is the biggest reason as to why React is useful in my opinion).

We kind of have events covered with event delegation and custom events.

In my opinion, a native DOM diff algorithm as part of the DOM spec would already goes a long way for the teams who want to get rid of third party frameworks. It is very easy to build a view functionally (then use the visitor pattern to serialize functions into a DOM tree, which is basically, let's admit it, a poorman's XSL). Updating the DOM attached to a webpage is the hardest part in terms of performance and third party libraries aren't often as fast as they should be.

I'd be interested in hearing about alternative "frameworkless" approach regarding building interactive HTML pages without too much initial boilerplate (which can quickly turn into one owns framework anyway).

EJS looks a lot like a framework to me. Just because it leverages vanilla JS doesn't make it a non-framework. Or does it?

By the end it’s not really clear to me that their choice isn’t potentially the worst choice.

The vagueness about this project doesn’t help.

The project / use case is what should matter / drive this, less so rando idea like “ we don’t want to add any extra KB that is not strictly necessary”. Maybe if we understood the project the decision might make more sense.

Although I can understand additional size that comes with any framework, all the apps I worked have metrics so far, was in tens or hundreds of kbs. Never in ones. I was surprised when I read 3+7kb of Preact was felt heavy.

On Side Note: I think very soon most of JS Frameworks will reach that saturation point where all have equal performance metrics. After that it's more of developer experiance in building applications.

I chose Laravel 8 with Jetstream and Livewire for this next project. Its a hybrid SPA. We'll see how it goes. I got sick of huge ever changing JS SPAs that stop working every two years. If you have a big team, thats way to do it but for me its small projects, one person and fast dev times. Not sure how secure it is, but we'll see. Was suprised how I liked Tailwind CSS also.

I landed on the same conclusion and built a very small framework on top of vanilla JavaScript, with solid browser support (~2018).

I've built a complex internal app at Netflix with this, primarily composed of small widgets roughly the size and complexity of that todo app.

My main motivation is to make it as easy as possible to do the right thing when it comes to user experience engineering. And also to be able to hire people with less experience.

Library Documentation: https://thelanding.page/tag/

Todo MVC Demo: https://thelanding.page/apps/todo

Todo Demo Source: https://git.sr.ht/~tychi/todo-list/tree

Let me get this straight... Your requirements were small size, developer experience, and tooling so you decided to throw the last two out the window to save a few kilobytes that nobody will ever notice?

Not only that but this evaluation took you months?

I found that a good way to pick a framework or make architecture decisions is to borrow ideas from ATAM [1]

In a nutshell: specify some important scenarios based on your requirements; for each scenario make a list of desired quality attributes and a way to measure them; use this combination of (scenario, quality attributes) to evaluate each option.

It’s a simple and obvious method, but for some reason is barely used.

A critique to the article: the evaluation criteria doesn’t seem to take into account any real scenario. For example why 15kb? Are they planning to serve people with very low bandwidth? Is the speed of the FCP more important that time to interactive (TTI)?

Regarding frameworks. A difficult metric to measure is hiring: if you are planning to grow your team, a popular, nice to use framework is another point to attract talent (eg choosing Backbone,jQuery,and CoffeeScript may fit your quality attributes but in 2022 is not very attractive for a job description).

[1]: https://en.wikipedia.org/wiki/Architecture_tradeoff_analysis...

Kilobyte budgets, in some scenarios, do not matter. If you're targeting users in areas with high or limitless data caps, and have 4G or better connection speeds, the choice between React Svelte etc. is an academic exercise with respect to bundle size budgets. Unless you're at Amazon scale, that extra 100kb in loading time isn't costing you millions in lost sales.

A critique of this blog post; I have no idea what you are evaluating these frameworks for which makes any insights you've shared a little hard to learn from. Kudos to you for even writing them down, but maybe consider linking to your project at the end of the post or something like that. And yeah, without knowing the target project, it's hard not to be skeptical. The only use case where I could think of the file size constraints you've placed on yourself would actually be meaningful is if the target audience's internet download speeds are measured in kB/s, like they are for connections in many less developed parts of the world.

Haven't done any FE work for a while but recently had to do a decent amount for a greenfield project. Man have the things improved over the last 4 years. Vite + Vue3 + vuex very smooth dev. experience. Vite config is like 3 lines.

If the author is reading this: Svelte can do SSR, and it does an amazing job of it. Depending on how you configure it and what you need, it even serves pages that run fine without JS; the entire page is built by the server, and the svelte compiler doesn't need to do any lifting on the front-end.

There are some caveats though; if you need to do any fetching based on user interactions and reassembling based on that data, then Svelte will ultimately need to run some things on the front-end. If you just need to fetch some data and render the page based on that data however, Svelte can do all the rendering on the server.

> Our choice does not need anyone to learn anything, and one can create a widget in no time!

EJS is not "anything", imo. I'd probably feel at home with it since I've used a bit of ERB, but despite how simple it looks there's some gotchas, syntax highlighting is always going to be an issue, and making those widgets modular is going to require at least some conventions to be used, and at worst some helpers that will eventually start looking like a framework (of course this depends on the scope of the project). Also, bundle size for EJS is not mentioned.

> In the end, we judged svelte too risky to depend on. Maybe in 3-5 years Svelte will be a good choice

Most people don’t realize that Svelte is just as old as React. It’s predecessor, Ractive.JS came out years before React or any of the others. It’s not new in any sense, we just got over the “React is the only truth” phase.

Besides, the community is already huge. When react came out having 1k starts on GitHub was a massive achievement!

As another commenter put well, they’ll just end up with their own little framework, which is riskier than any of the choices they had.

Criticizes sveltes syntax and chooses EJS? Ok. Nothing about this is consistent.

I love EJS but it is not comparable to some of these other frameworks and libraries.

Depends on your needs, the WiseJ is really great for complex LOB applications.

Full control over input data validation, rich controls, easy integration with other libraries (Charts, Editors, PDF viewers), the rapid web app development in its the original meaning.

No need to touch JS.

The 2.5 paid version is for .NET Framework, but the upcoming 3.0 has limited free licensing and net.core support.

We just did the same and choose lit + mobx + tailwind after spending 10+ year with our internal framework, alone, without any public documentation or tutorial.

And VS Code make them easy to write.

In 20+ years of web development, I've never felt an environment that refreshing.

Is Angular really half the size of React? It was the other way round last time I looked.

Why are they using preacts gzip size(3kb) and not React's gzip size(~36kb).

I'm kind of surprised they didn't settle on something like mithril.js

Why are people still going crazy over the distributable file size, just serve react via their cdn and it will already be cached in the browser since it’s already used on every other page you load.

  We did lost something

Just nitpicking here but I think the correct statement is "We did lose something"

i made similar choice, it came down to it, i just didn't feel like my simple dashboard should be 300 components or wanted to see ANY transpiling happening, you forget are delightful it's to save and see browser update <1s on different monitor.

Another story of JS devs who make sure they wouldn’t have to learn anything new.

It is a pity that SolidJS was not also considered