from Hacker News

Evaluating front end frameworks and not choosing any

by musikele on 1/3/22, 2:41 PM with 103 comments

  • by jklm on 1/7/22, 3:56 AM

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

  • by okareaman on 1/7/22, 4:32 AM

    > 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

  • by andrewstuart on 1/7/22, 4:24 AM

    Discarded React because it takes 120K?

    The background image on his blog post is 168K

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

  • by baron816 on 1/7/22, 4:15 AM

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

  • by darkerside on 1/7/22, 3:58 AM

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

  • by DrBenCarson on 1/7/22, 4:11 AM

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

  • by catillac on 1/7/22, 3:50 AM

    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?

  • by throw_m239339 on 1/7/22, 4:44 AM

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

  • by itsbits on 1/7/22, 3:51 AM

    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.

  • by rdubs333 on 1/7/22, 5:22 AM

    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.

  • by paulryanrogers on 1/7/22, 3:45 AM

    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 tylerchilds on 1/7/22, 4:36 AM

    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

  • by serverholic on 1/7/22, 4:43 AM

    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?

  • by diegof79 on 1/7/22, 5:12 AM

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

  • by 88913527 on 1/7/22, 4:09 AM

    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 duxup on 1/7/22, 4:11 AM

    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.

  • by CitrusFruits on 1/7/22, 4:21 AM

    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.

  • by qaq on 1/7/22, 4:45 AM

    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.

  • by pcthrowaway on 1/7/22, 4:44 AM

    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.

  • by steinuil on 1/7/22, 4:35 AM

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

  • by ricardobeat on 1/7/22, 4:03 AM

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

  • by leetrout on 1/7/22, 4:34 AM

    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.

  • by EMM_386 on 1/7/22, 4:35 AM

    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.

  • by idiocrat on 1/7/22, 6:27 AM

    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.

  • by tchvil on 1/7/22, 4:19 AM

    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.

  • by cutler on 1/7/22, 4:21 AM

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

  • by thysultan on 1/7/22, 4:34 AM

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

  • by fouc on 1/7/22, 4:57 AM

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

  • by lerpapoo on 1/7/22, 3:35 PM

    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.

  • by pranit10 on 1/7/22, 4:34 AM

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

  • by mosdl on 1/7/22, 4:23 AM

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

  • by techsin101 on 1/7/22, 6:25 AM

    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.

  • by nesarkvechnep on 1/7/22, 6:20 AM

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

  • by croes on 1/7/22, 5:55 AM

    It is a pity that SolidJS was not also considered