To all people who write React-alternatives: please modularize as much as possible. For example, JSX-like syntax is not necessary and some developers might not want to use it; therefore, it should be in a separate module that is completely optional. Also, the virtual-DOM part may be useful in itself, therefore it should also be a separate module. React offers some tools to more easily manage state, but please acknowle…
I disagree, and prefer monolithic frameworks than modular ones. Catering for a common configuration of modules allows the maintainer and contributors to make more assumptions. These assumptions allow them greater freedom to optimize performance and simplify interfaces. Lego like frameworks have to be uber generic thus catering to theoretical computer science aesthetics rather than real world practical use cases. if a…
Back in 2012, I remember when Backbone Marionette broke into pieces. It made "logical" sense, but the instances you'd actually want to pull in the event library without taking in Marionette is rare.
There's a certain sense you have to be tactical with decoupling stuff. I decouple front ends from libraries because I don't want my users to be forced to use my CLI front end when they just want an abstraction with minimal requirements.
I get away with it because there's 1 library and 1 frontend.
In JS, there's a front end, a library, and an extension marketplace that make you wonder what they were thinking when they were decoupled. Stuff like extract-text-webpack-plugin.
Guess what that plugin does: It allows you have your CSS show up as CSS files instead of JS. But the title denote that, (forget that fact you'd expect webpack to have such simple stuff in webpack itself.) It instead is "extracts text", despite the fact the convention of "text extraction" means nothing to web developers.