Evaluating front end frameworks and not choosing any | Hacker News Reader

Evaluating front end frameworks and not choosing any

michelenasti.com

67 pointsmusikele103 comments

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

I've found most applications people make on any framework are ultimately things to be learned by new folks. That is, picking a framework doesn't really help in this angle.

It is true that simple apps can usually keep up with trends and documentation of a chosen framework.

But, all too often, the choices in how to use a framework pile up and are lost to the tribal knowledge of a team. This was worse when libraries are pulled in easily to scratch itches for each part of the application without care to the whole.

We actually have our documentation as a sandbox for the framework. So it gets updated as you build new pieces.

Does it really matter? In 5 years none of the popular frameworks are going to be the same. React will be "legacy" (if it isn't already) and something else will be the hotness.

React was released in 2013 and it's been the top framework for awhile now. There's a strong possibility that React will still be one of the top frameworks if not the top framework in 5 years still.

The Lindy Effect is real.

Doubt. React is here to stay. This is about as grounded in reality as people 5 years saying Ruby on Rails and Django would be gone today.

Gone, no. But both seem to have distinctly ebbed since their peak (especially Rails).

As much as I don't like React, it is here to stay. But even if it weren't, it would still be a better idea to use something existing than writing your own framework. It is documented, well tested, easy to integrate with other tools, has devtools, and lot of developers already know it (and will still know it several decades from now).

Writing your own framework is almost never a good idea. It is only a good idea for the one writing it because we like tech and we like to show how good we're at building things ourselves. Business wise is the worst mistake ever... unless you're Figma or something like that building something radically special, I don't see how this is a good idea.

You have the first example of this problem in the post itself:

"...We did lost something with this choice. 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...."

The more your project grows, the more of that you will get. Then one day the people that took this decision leaves the company. And then the new joiners are stuck with an undocumented, failing, spaghetti frankestein mess they have to work on day to day.

And finally...those "few simple" components, will evolve...and sooner than later they won't be neither few neither simple anymore.

Anecdotally documentation in JS framework world is quite bad or missing. So maybe not much of an argument? Compare React documentation to Flutter for example. Also you do not have to update your framework more than necessary. Often times there's a dependency that needs to be updated that requires everything else to be updated and you spend a lot of extra time with that instead of just fixing whatever bug you were supposed to fix. Tradeoffs to both approaches of course.

> Anecdotally documentation in JS framework world is quite bad or missing. So maybe not much of an argument? Compare React documentation to Flutter for example.

can you give some examples of poor documentation? most frontend JS frameworks (react included) have friendly, comprehensive documentation.

- https://beta.reactjs.org/learn

- https://redux.js.org/introduction/getting-started

- https://svelte.dev/docs

- https://vuejs.org/v2/guide/

> 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

thanks for the technical clarification. What's ur take on Solid js?

You're welcome but I'm sorry I'm not familiar with Solid.

Solidjs is nice if you want something that's going to feel familiar to react users, but is a bit easier to wrap your head around. Also the main driver behind it and community all seem pretty positive/chill from what I've seen.

Now that I've looked at it I think it might be what I'm looking for. It's fast, reactive and composable.

There are some really good comments about Solidjs in this thread and some others backing up what I'm saying about the virtual DOM

https://news.ycombinator.com/item?id=29388296

I'm currently looking at svelte for a desktop app, so I'm very curious. Is your harshest criticism that the author has taken more credit than deserved? That I can live with!

Rich Harris has this "stick it to the man" attitude which I thoroughly enjoy. In his case "The Man" is React and Vue. He shows some back and forth between himself, Evan You and Dan Abramov in one of his videos. Evan You called it SvelteScript in not a good way. This is all part of the competitive fun.

My biggest beef with Rich Harris is that he doesn't credit Lars Bak and the small team at Google for doing incredible work speeding up V8. Google saw nodejs take off and realized they had to make V8 faster, so they put a lot of money into doing so. Unfortunately the virtual DOM took off before V8 got super fast. Look up "you don't need a virtual DOM" for confirmation.

I believe it's one of the reasons Microsoft threw in the towel and adopted Blink. If you can't beat 'em, join 'em.

Harris also doesn't give any credit to the reactive binding work that came before him. He acts like he used a spreadsheet and had the bright idea to make a website that way. I have a strong sense of fairness so I don't think a designer/dev working for newspapers should take the credit from the geniuses at Google who made it possible. I think it's quite possible that he doesn't know any computer science but he's a gifted amateur.

Im looking at Shadow DOM components myself, but it's quite possible I might use Svelte. It's a nice tool, but it's not the magic beans that solve all your problems like no one ever before.

Is it possible to have a fast reactive framework without virtual DOM?

Sure! Use Vanilla JavaScript, TypeScript, jQuery but do some research first so it doesn't turn into spaghetti code.

https://en.wikipedia.org/wiki/Data_binding

https://en.wikipedia.org/wiki/Observer_pattern

https://developer.mozilla.org/en-US/docs/Web/API/Window/requ...

There's a bunch of them I'm sure, but solidjs is a really good example.

It has syntax very familiar to react, but works differently under the hood.

Ejs plus rx seems like a fun weekend challenge

Are you criticizing Svelte because it's "not rocket science"? Would you be more inclined to use it if it was extremely complicated?

I guess I fell for the hype. When I looked at it I thought, is that all? I think simple is better. It simple enough that writing my own component compiler is a nice project to work on. I already started. I found out today that it will be easy to write the observer pattern because Google added requestIdleCallback in 2015, so in my idle loop I just check the message queue and see if any changes are posted so I can update the subscribers. The other thing about doing my own is I can do it in Dart instead of TypeScript.

https://developer.mozilla.org/en-US/docs/Web/API/Window/requ...

> Now React is stuck with it's virtual DOM. But sure Richard, take the credit for being fast if you want.

Would it be hard for React to remove VirtualDOM(if they don't believe), and maintain most of API?

Dan Abramov is fairly responsive on Twitter. I'd ask him.

Did you mean: preact

Preact uses a virtual DOM still.

Oh my bad, totally mess this up.

But I think VDOM is pretty much the core idea of react so it just wouldn't make sense for them to get rid of it. And also with React 18 coming with features like automatic batched updates and suspense, I would imagine it would be pretty hard to do without VDOM maybe?

may be it's one of challenges for devs, who ever are interested to make React alternative with same API and dev experiance without VirtualDOM support.

https://en.m.wikipedia.org/wiki/Egg_of_Columbus

Nice. Yes I can see that.

> I just don't think Svelte does that much.

Not to be pithy, but I believe that was Rich’s intention.

I guess the tagline "Cybernetically enhanced web apps" is a joke I didn't get. The first sentence on Svelte.com is "Svelte is a radical new approach to building user interfaces" alrighty then!

Discarded React because it takes 120K?

The background image on his blog post is 168K

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

I assume his personal blog is not the usecase. There may be bandwidth limitations in their usecase.

That's what's missing here - a set of criteria defining what matters in the evaluation.

What are the key criteria and what core does each framework get? Also, the "built some new thing" must be evaluated and scored alongside the others.

If "we are building for super low bandwidth users" matters then it should be stated in this blog post.

Here's a start point for criteria for evaluating JS frameworks - each framework should get a score against the criteria, and the criteria should be weighted to indicate importance for this project:

* Open source number of project maintainers and activity level of project commits

* Maturity

* Size of user base/community

* Size of runtime

* Quality of documentation

* Availability of third party components

* Recruiting new team members - availability of developers experienced with this framework

* IDE support

* Availability of third party documentation

* Number of questions and answers on Stack Overflow/online forums

* Experience level of framework within our team

etc etc add criteria that matter to you.

You forgot * performance *

It's easy to get rid of the picture, try that with the react components.

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

I wonder if they base hiring decisions on how long of a commute and what kind of car the would-be employee has.

Anybody above 160 cm consumes too much energy so we only hire below that for a greener planet.

They could save a lot more Co2 by making sure the site this goes into don't have any 1MB images that nobody will look at for more than 1 second.

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

Why does it has to be criticism? They didn't choose it and they did say it's bad. Just it's not what they want.

The article purports to be a rational comparison. If you just want to write an uncritical opinion piece, do it. If you claim you are working pros and cons, do that.

30kb is too much for js. A modern website should run fine on half of that.

Any _real_ modern website should run fine on under 1Kb, no matter the contained data

I've never been more productive in my life with a combination of Vue and Rails.

Curious - did you use Rails in API mode?

ive worked on vue and have been looking to dip my toes into ruby on rails, any tips?

They don’t want to emit greenhouse gasses because of a few kbs and they don’t want future people to deal with Vue.js. Talk about first-world problems…

They want to write their own framework and inflict it on the engineering team

Way more fun than actual customer problems

Instead of learning gzip, now in 2 years everyone will have to learn a library that has been abandoned and has almost no tooling or documentation!

It's like when they didn't want to codify SQLite as Web SQL so they tortured everyone with an extra layer of crap they added on it.

They wanted it under 15kb. And for some reason, give future devs ability to not use Vue.

I don’t know how they settled on 15kb, but “don’t want to force people of future” is as stupid of a reason as I have seen. Surely, “people of future” can refactor old code, or have different constraints altogether

Seems like a tautology. They didn't want Vue because they didn't want Vue.

Whatever your choice is, you're going to have to move off of it one day.

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

To be fair, the Civic does look a little funny.

But yes, there should be more emphasis on what drives business value (hence on picking a stack that allows providing that value as efficiently as possible), and with the minefield that's modern web development, starting from scratch doesn't seem sensible. The post doesn't go too deep into what they're building though, so maybe I'm missing something.

Build the cupholders first, delivery them to the client, and re-reevaluate. Maybe the client was only looking at cars because that's where they've seen cupholders before.

The article said they're building cup holders and didn't want them to come with a car.

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?

They're just practicing SDD: Shyamalan-driven development

Winner, and still champion!

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

If it were up to me the browser would just include Vue/React like functionality.

The legacy debt issue is mostly because nobody knows what the future of the framworks are. It's not like Vue will be bad. There might not even be something better, just new and shiny and 2kb lighter.

With code size a complete non-issue and native optimization, things could be a lot better.

All our components could be under a unified standard with no overhead. Trivial sub-kb things could take advantage of reactive type design.

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.

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?

No, EJS is a template library. While frontend frameworks(vue, svelte, react) have templates, their main focus is on syncing js with html.

So, not only EJS is strictly less useful than any FE framework, at 22kb (min) it is also heavier than some of the options

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.

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.

When I read that line, I thought svelte should be the one. But no, they chose something with even less documentation, community and tooling support

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.

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.

My problem with TypeScript isn't the fear of compiler errors. It's because then my day job became hammering scope until the problem could be solved with CSS so we didn't need to write any Superset of JavaScript at all.

> . It's because then my day job became hammering scope until the problem could be solved with CSS so we didn't need to write any Superset of JavaScript at all.

CSS is the least of your problems, wait until your career gets to the point of 20+ developers.

And by "compiler errors" I don't mean TypeScript, that is easy peasy ... I mean Angular.

And even that is easily sorted if you know why it's complaining and how to fix it.

I work with more than 20 engineers.

Our biggest problems stem from abstraction A built on abstraction B, built abstraction C, built on abstraction D.

Specifically, the abstractions are material UI, our component library in react, react data grid, and an app specific for any of it.

For end users, they want a table. TypeScript provides the logistics to make this sprawl predictable, albeit with a 500ms delay on user input.

CSS isn't a problem: it is the solution. That's why I'm working to get our tech debt paid upfront and upstream with it.

> For end users, they want a table. TypeScript provides the logistics to make this sprawl predictable, albeit with a 500ms delay on user input.

This is a problem with your engineering, not with TypeScript or front-end frameworks. TypeScript isn't even a thing for end-users, that gets transpiled to plain old JavaScript.

We deal with real-time grids that are updated via RxJs 7 subscribed to multiple data feeds. Thousands of rows all being updated in real time without a page refresh.

The performance impact is negligible. Especially compared to the desktop apps I used to write that did the same thing. 500 ms is insane, you are doing something wrong. Our grids update on the order of less than 5 ms, and with virtual infante scrolling on top of that.

Lots of rows, all scrollable smoothly and all flashing updated numbers in real-time.

It works perfectly and is extremely performant. If you are having issues with "sprawl" and data grids, you have a problem with a poor component library and/or poor engineering.

We use PrimeNG. It's table component is blazing fast. You stick a <p-table> component in your template and bind it to a data source, the rest is handled from there for the most part.

I'm not sure what there is to complain about any of this. It works as advertised.

At least in Angular it does. I have no idea with React. I know both but I avoid React like the plague for various reasons.

https://www.primefaces.org/primeng/showcase/#/table

Your assessment is spot on. I've been working on building a proof of concept outside of our jenga tower of dependencies. This is the foundational open-sourced layer I built that I'm now building on top of: https://thelanding.page/tag/

I'm starting to transition to sell mode, it's just a tough sell when the entire org is heavily invested in the aforementioned jenga tower.

We migrated to Angular 13 from 11. I LOVE Angular for front-end.

TypeScript is love, TypeScript is life :)

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"

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

preact has worse performance than react at the expense of size and hooks are basically on the only reason I’m still using react. Without hooks I would be forced to create react component classes instead of simple functions… they are very very handy

Functions are nice for simple components, but any non-simple component becomes unreadable with hooks, classes are easier to read/reuse and debug.

yea…okay lol

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

Reply on news.ycombinator.com