
Unopinionated framework faster than everything (0kb raw and gzipped) - saddam96
https://github.com/undefinedbuddy/vanilla
======
throwanem
"Unopinionated"? This is nothing _but_ the expression of an opinion.

------
zelphirkalt
It's a terrible framework, but it works and many successful projects have been
built on top of it.

------
Kaze404
This is a really bad shitpost

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

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

~~~
saddam96
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

