10 ms·

Evaluating front end frameworks and not choosing any

67 points by musikele 5y ago

cutler 5y ago
Is Angular really half the size of React? It was the other way round last time I looked.
lerpapoo 5y ago
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.
nesarkvechnep 5y ago
Another story of JS devs who make sure they wouldn’t have to learn anything new.
paulryanrogers 5y ago
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?
- rk06 5y ago
  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
catillac 5y ago
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?
- riwsky 5y ago
  They're just practicing SDD: Shyamalan-driven development
  - dmcgee 5y ago
    Winner, and still champion!
itsbits 5y ago
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.
jklm 5y ago
> 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.
- taeric 5y ago
  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.
- soperj 5y ago
  We actually have our documentation as a sandbox for the framework. So it gets updated as you build new pieces.
- throwawayboise 5y ago
  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.
  - serverholic 5y ago
    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.
    - 5y ago
darkerside 5y ago
> 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.
- pqdbr 5y ago
  I've never been more productive in my life with a combination of Vue and Rails.
  - cutler 5y ago
    Curious - did you use Rails in API mode?
  - sadn1ck 5y ago
    ive worked on vue and have been looking to dip my toes into ruby on rails, any tips?
- temp8964 5y ago
  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.
  - darkerside 5y ago
    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.
- markdown 5y ago
  30kb is too much for js. A modern website should run fine on half of that.
  - snowl 5y ago
    Any _real_ modern website should run fine on under 1Kb, no matter the contained data
ricardobeat 5y ago
> 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.
88913527 5y ago
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.
DrBenCarson 5y ago
This is like building your own car because the Camry doesn’t have enough cupholders and the Civic looks kinda funny.
- Brian_K_White 5y ago
  The article said they're building cup holders and didn't want them to come with a car.
- deleted 5y ago
  [deleted]
- crehn 5y ago
  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.
- stirfish 5y ago
  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.
duxup 5y ago
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.
- rk06 5y ago
  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
baron816 5y ago
> 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.”
- tengbretson 5y ago
  I wonder if they base hiring decisions on how long of a commute and what kind of car the would-be employee has.
  - dgut 5y ago
    Anybody above 160 cm consumes too much energy so we only hire below that for a greener planet.
- eternityforest 5y ago
  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.
tchvil 5y ago
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.
CitrusFruits 5y ago
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.
mosdl 5y ago
Why the need for hooks for preact - hooks are the worst part of the react system. They are not necessary at all.
- lerpapoo 5y ago
  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
  - mosdl 5y ago
    Functions are nice for simple components, but any non-simple component becomes unreadable with hooks, classes are easier to read/reuse and debug.
    - lerpapoo 5y ago
      yea…okay lol
andrewstuart 5y ago
Discarded React because it takes 120K? The background image on his blog post is 168K https://michelenasti.com/images/bg.jpg https://michelenasti.com/images/bg.jpg
- stickyricky 5y ago
  I assume his personal blog is not the usecase. There may be bandwidth limitations in their usecase.
  - andrewstuart 5y ago
    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.
    - lerpapoo 5y ago
      You forgot * performance *
- croes 5y ago
  It's easy to get rid of the picture, try that with the react components.
okareaman 5y ago
> 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
- resonious 5y ago
  Are you criticizing Svelte because it's "not rocket science"? Would you be more inclined to use it if it was extremely complicated?
  - okareaman 5y ago
    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/requestIdleCallback https://developer.mozilla.org/en-US/docs/Web/API/Window/requ...
- lowwave 5y ago
  thanks for the technical clarification. What's ur take on Solid js?
pranit10 5y ago
We did lost something Just nitpicking here but I think the correct statement is "We did lose something"
thysultan 5y ago
Why are they using preacts gzip size(3kb) and not React's gzip size(~36kb).
leetrout 5y ago
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.
steinuil 5y ago
> 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.
EMM_386 5y ago
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.
- tylerchilds 5y ago
  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.
  - EMM_386 5y ago
    > . 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.
    - tylerchilds 5y ago
      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.
      - EMM_386 5y ago
        > 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 https://www.primefaces.org/primeng/showcase/#/table
tylerchilds 5y ago
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/ https://thelanding.page/tag/ Todo MVC Demo: https://thelanding.page/apps/todo https://thelanding.page/apps/todo Todo Demo Source: https://git.sr.ht/~tychi/todo-list/tree https://git.sr.ht/~tychi/todo-list/tree
serverholic 5y ago
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?
pcthrowaway 5y ago
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.
throw_m239339 5y ago
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).
- eternityforest 5y ago
  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.
qaq 5y ago
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.
fouc 5y ago
I'm kind of surprised they didn't settle on something like mithril.js
diegof79 5y ago
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_method https://en.wikipedia.org/wiki/Architecture_tradeoff_analysis...
rdubs333 5y ago
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.
croes 5y ago
It is a pity that SolidJS was not also considered
techsin101 5y ago
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.
idiocrat 5y ago
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.

67 points by musikele 5y ago

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

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.

nesarkvechnep 5y ago

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

paulryanrogers 5y ago

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?

rk06 5y ago
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

catillac 5y ago

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?

riwsky 5y ago
They're just practicing SDD: Shyamalan-driven development
- dmcgee 5y ago
  Winner, and still champion!

itsbits 5y ago

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.

jklm 5y ago

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

taeric 5y ago
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.
soperj 5y ago
We actually have our documentation as a sandbox for the framework. So it gets updated as you build new pieces.
throwawayboise 5y ago
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.
- serverholic 5y ago
  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.
  - 5y ago

darkerside 5y ago

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

pqdbr 5y ago
I've never been more productive in my life with a combination of Vue and Rails.
- cutler 5y ago
  Curious - did you use Rails in API mode?
- sadn1ck 5y ago
  ive worked on vue and have been looking to dip my toes into ruby on rails, any tips?
temp8964 5y ago
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.
- darkerside 5y ago
  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.
markdown 5y ago
30kb is too much for js. A modern website should run fine on half of that.
- snowl 5y ago
  Any _real_ modern website should run fine on under 1Kb, no matter the contained data

ricardobeat 5y ago

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

88913527 5y ago

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.

DrBenCarson 5y ago

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

Brian_K_White 5y ago
The article said they're building cup holders and didn't want them to come with a car.
deleted 5y ago
[deleted]
crehn 5y ago
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.
stirfish 5y ago
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.

duxup 5y ago

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.

rk06 5y ago
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

baron816 5y ago

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

tengbretson 5y ago
I wonder if they base hiring decisions on how long of a commute and what kind of car the would-be employee has.
- dgut 5y ago
  Anybody above 160 cm consumes too much energy so we only hire below that for a greener planet.
eternityforest 5y ago
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.

tchvil 5y ago

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.

CitrusFruits 5y ago

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.

mosdl 5y ago

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

lerpapoo 5y ago
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
- mosdl 5y ago
  Functions are nice for simple components, but any non-simple component becomes unreadable with hooks, classes are easier to read/reuse and debug.
  - lerpapoo 5y ago
    yea…okay lol

andrewstuart 5y ago

Discarded React because it takes 120K? The background image on his blog post is 168K https://michelenasti.com/images/bg.jpg https://michelenasti.com/images/bg.jpg

stickyricky 5y ago
I assume his personal blog is not the usecase. There may be bandwidth limitations in their usecase.
- andrewstuart 5y ago
  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.
  - lerpapoo 5y ago
    You forgot * performance *
croes 5y ago
It's easy to get rid of the picture, try that with the react components.

okareaman 5y ago

> 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

resonious 5y ago
Are you criticizing Svelte because it's "not rocket science"? Would you be more inclined to use it if it was extremely complicated?
- okareaman 5y ago
  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/requestIdleCallback https://developer.mozilla.org/en-US/docs/Web/API/Window/requ...
lowwave 5y ago
thanks for the technical clarification. What's ur take on Solid js?

pranit10 5y ago

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

thysultan 5y ago

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

leetrout 5y ago

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.

steinuil 5y ago

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

EMM_386 5y ago

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.

tylerchilds 5y ago
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.
- EMM_386 5y ago
  > . 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.
  - tylerchilds 5y ago
    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.
    - EMM_386 5y ago
      > 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 https://www.primefaces.org/primeng/showcase/#/table

tylerchilds 5y ago

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/ https://thelanding.page/tag/ Todo MVC Demo: https://thelanding.page/apps/todo https://thelanding.page/apps/todo Todo Demo Source: https://git.sr.ht/~tychi/todo-list/tree https://git.sr.ht/~tychi/todo-list/tree

serverholic 5y ago

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?

pcthrowaway 5y ago

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.

throw_m239339 5y ago

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

eternityforest 5y ago
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.

qaq 5y ago

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.

fouc 5y ago

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

diegof79 5y ago

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_method https://en.wikipedia.org/wiki/Architecture_tradeoff_analysis...

rdubs333 5y ago

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.

croes 5y ago

It is a pity that SolidJS was not also considered

techsin101 5y ago

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.

idiocrat 5y ago

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.