3 ms·

Purely from an outsider perspective, it's interesting to see all the different frameworks out there, but for front end devs I can't help but feel that this type

Purely from an outsider perspective, it's interesting to see all the different frameworks out there, but for front end devs I can't help but feel that this type of comprehensive list hinders more than it helps. One key thing JS needs less of is fragmentation. If I were in the front end dev community I'd want to see people making the front runners more mature and flexible, not endlessly fragmenting just because they slightly disagree with what a more established framework does. Looking through a number of the entries in this list you read that it was "inspired by React". Why not just make React more flexible so that your alternative way of handling code fits within it? Does each of these new approaches really require a whole new framework? Contrast this with something like the .NET Framework (which is something I'm more familiar with). Whilst the CLR has the potential to run frameworks other than the .NET Framework, you don't see the same churn in frameworks that you see with JS. I'd suggest this is due to a mixture of two things: 1. A greater focus on getting things done over code elegance. 2. The more mature a framework becomes, the more work is required to match its feature set. On this second point, if JS continues its constant framework churn, it'll be stuck with immature frameworks. I'd suggest that JS devs should be doing what they can to get past this stage, and if that means (for a few years) treating new frameworks as interesting experiments rather than the next big thing, then that may be a cost worth paying.

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 ago
  The 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.

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 ago
The 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.