> 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.
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.
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.
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.
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.
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.
> 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.
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.
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?
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!
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.
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.
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
> 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.”
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
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.
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.
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.
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?
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.
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.
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).
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.
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.
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.
> 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.
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.
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.
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.
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
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.
> 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.