4 ms·
I actually think fragmentation is ideal, it demonstrates the failures in a system more cleanly. For example, I started with Protoype.js many years ago, after a
by RobertRoberts 9y ago
I actually think fragmentation is ideal, it demonstrates the failures in a system more cleanly. For example, I started with Protoype.js many years ago, after a bunch of research at the time. But then later switched to jQuery, because it was simply better in every way.
There simply was no fixing the problems with Prototype.js, they were inherent in the system.
I think when a fragmentation occurs in every framework, its for the same reason. Consider Angular 1 to Angular 2, they broke backwards compatibility because they had too. Angular 2 could have been called something else, and it would be viewed as "fragmentation" not an "upgrade", but in effect, it was fragmentation.
This is the exact reason why I think all of these frameworks will ultimatly end up in the dustbin of history. Does any major programming language in the last 30 years use a framework that requires multiple build systems, multiple "dialects" of differing syntax just to do what is inherently available already? (but just faster and easier?)
This sounds like the end result is Webassembly, not the "perfect framework".
- ZenoArrow 9y agoThe end result may be development without a 3rd party frameworks, perhaps in a way that allows you to mix and match libraries without needing to use a large underlying framework. However, as things stand now there is clearly a need for JS frameworks. They are plugging gaps in vanilla JS. My argument isn't that frameworks do not have any utility (right now), my argument is, if you stick to a smaller selection of frameworks and work on both polish and flexibility, you'll have frameworks that make people want to develop in JS. At the very least it'll mean that the basics would be easy, and design decisions could be deferred until later in the site design.