Unopinionated framework faster than everything (0kb raw and gzipped)(github.com)
github.com
Unopinionated framework faster than everything (0kb raw and gzipped)
https://github.com/undefinedbuddy/vanilla
7 comments
"Unopinionated"? This is nothing but the expression of an opinion.
It's a terrible framework, but it works and many successful projects have been built on top of it.
This is a really bad shitpost
The algebraic effects link made my head spin.. So webdevs go from synchronous, to callback hell, to async await, to callfrom?
I start to understand more and more why I see so many frontend devs learn about Rust as an alternative for the near future.
I start to understand more and more why I see so many frontend devs learn about Rust as an alternative for the near future.
I write vanilla JS for a majority of projects. If you adhere to a certain code structure it is quite productive and maintainable, while avoiding dependencies.
But that is only when I don't have a choice over the template engine.
In reality it is: a template engine + vanilla JS vs. React. And as soon as you also need to do client side routing and manage state across page transitions you are in a world of hurt with the former (exaggerating, in comparison).
This is why I prefer React and frameworks like Nextjs.
With Nextjs you get a full-blown solution that is feasible and performant for both simple and complex sites, a convenient top level structure, complete control over when you render (SSG/SSR/CSR) and a uniform way to build your UI (JS + React).
And in some cases a React SPA is just right, especially if your website is mostly a structured "CRUD" UI, since these are (hopefully) designed in a very consistent way, so you end up updating small pieces of your DOM with every transition/action.
The alternative is not "Just use Vanilla-JS", it is a hodgepodge of languages, code/logic duplication and choices/trade-offs that you need to make such as "where is the right place for this thing" etc.
But that is only when I don't have a choice over the template engine.
In reality it is: a template engine + vanilla JS vs. React. And as soon as you also need to do client side routing and manage state across page transitions you are in a world of hurt with the former (exaggerating, in comparison).
This is why I prefer React and frameworks like Nextjs.
With Nextjs you get a full-blown solution that is feasible and performant for both simple and complex sites, a convenient top level structure, complete control over when you render (SSG/SSR/CSR) and a uniform way to build your UI (JS + React).
And in some cases a React SPA is just right, especially if your website is mostly a structured "CRUD" UI, since these are (hopefully) designed in a very consistent way, so you end up updating small pieces of your DOM with every transition/action.
The alternative is not "Just use Vanilla-JS", it is a hodgepodge of languages, code/logic duplication and choices/trade-offs that you need to make such as "where is the right place for this thing" etc.
It's great to hear you use plain JS for most of your projects when there are so many frameworks out in the world. In these times, developers are often fooled into thinking their applications won't 'scale' if they don't use frameworks or opinionated UI patterns.
This is why even the most basic of web applications will be using a framework (I'm not referring to Web Components consumers).
Sometimes, said frameworks and patterns become convoluted and make things cumbersome. On top of that, many will be using bundlers, transpilers for syntax and polyfills, etc. Of course, some of these frameworks are not so tied to build tools and will have ESM support, but the convention is what will strictly differ.
Nevertheless, with some abstractions, frameworks make building web applications fun. However, those abstractions should not be a cause for users paying a hefty price when performance kicks in. Most of the time, these frameworks won't give you a choice. "You pay for what you use" sorta thing.
I really like your conclusion and I totally agree frameworks fit somewhere (large, actually). I just don't get why shipping bulk JavaScript is a price we have to pay. That is why Preact and Svelte have an upper hand in this case.
My take: I'd rather use Vanilla for building my projects instead of a combination of:
1. React with ReactDOM, ReactRouter, React-X, React-Y, React-Z
2. Angular and RxJS
3. Ember with GlimmerVM
This is why even the most basic of web applications will be using a framework (I'm not referring to Web Components consumers).
Sometimes, said frameworks and patterns become convoluted and make things cumbersome. On top of that, many will be using bundlers, transpilers for syntax and polyfills, etc. Of course, some of these frameworks are not so tied to build tools and will have ESM support, but the convention is what will strictly differ.
Nevertheless, with some abstractions, frameworks make building web applications fun. However, those abstractions should not be a cause for users paying a hefty price when performance kicks in. Most of the time, these frameworks won't give you a choice. "You pay for what you use" sorta thing.
I really like your conclusion and I totally agree frameworks fit somewhere (large, actually). I just don't get why shipping bulk JavaScript is a price we have to pay. That is why Preact and Svelte have an upper hand in this case.
My take: I'd rather use Vanilla for building my projects instead of a combination of:
1. React with ReactDOM, ReactRouter, React-X, React-Y, React-Z
2. Angular and RxJS
3. Ember with GlimmerVM
Truly. The fact that React devs are more concerned over API elegance, ergonomics and other niceties reveal how much Vanilla is needed.
Vanilla might be ugly sometimes, but you can bet on it when Web development is concerned. :)
Vanilla might be ugly sometimes, but you can bet on it when Web development is concerned. :)