6 ms·
The problem really isn't a function of the number of tools and frameworks in existence, but rather in the distribution of popularity among them. Each ecosystem
by dperfect 10y ago
The problem really isn't a function of the number of tools and frameworks in existence, but rather in the distribution of popularity among them.
Each ecosystem around a set of technologies essentially has its own "Herfindahl index"[1] of sorts. For example, the Ruby ecosystem's index might be fairly high, simply because Rails is so dominant (to the point where Ruby and Rails are often conflated by outsiders). On the other end of the spectrum, the current JavaScript landscape seems to have a fairly low index; there are a huge number of tools with very few clear winners at this point in time.
I suspect the best/healthiest ecosystem is probably somewhere in between that of Ruby and JavaScript. Rails may have ultimately hurt Ruby by its dominance, just as the current volatility in JavaScript tools seems to drive some people away (or at least add frustration).
Of course, I have no numbers to back any of this up - it's just an observation (one skewed by personal experience, no doubt).
[1] https://en.wikipedia.org/wiki/Herfindahl_index https://en.wikipedia.org/wiki/Herfindahl_index
- inopinatus 10y agoI'm curious, has anyone performed a comparative study that breaks this down e.g. correlating aspects of language design to systemic structures in the resulting ecosystem? I have often wondered whether the level of complaint relating to Javascript framework proliferation is explainable as due to language structures (whether notably present or notably absent) or unusual initial conditions of the JS community/ecosystem. Is there even a field of techno-psycho-sociological studies, and is there an equivalent of the Sapir-Whorf hypothesis for programming language ecosystems?
- usgroup 10y agoI think it's a JS problem with trends around other languages tending moreso to a single eco-system. Regarding JS frameworks, I think the barrier to entry is still low, and given the suffering involved for any given tool-chain, I'd imagine the temptation to roll ones own is high. Finally, JS framework fates are tethered to that of the browser. The latter changes frequently, so the former ends up in a refactoring perma-loop.
- vog 10y ago> Finally, JS framework fates are tethered to that of the browser. The latter changes frequently, so the former ends up in a refactoring perma-loop. Could you elaborate on that? What kind of browser changes are happening so often and are so deep that frameworks need to be refactored every time? (My experience is quite the opposite.)
- usgroup 10y agoSure. E.g ECMAScript supported versions, HTML5 features, HTTP2 support, mobile/tablet specific browser features, CSS1,2,3 support.
- electic 10y agoYou can spin it this way if you like. However, a big part of this framework and Tool epidemic is ego. The trick is to take a dominant framework or tool, find a deficiency, and then rewrite it again with that deficiency fixed. Why? Because if it takes off, your career takes of. What developers should really do is contribute and make the existing projects better. Everyone will thank you for it.
- ffggvv 10y agoNope they won't, because then your are just another contributor. There are thousand working on linux (the kernel). How many of them do you know?
- raverbashing 10y agoWhich is better (for your CV), be a contributor to Angular.js (example) or create your something.js that left-pads and right-pads at the same time?
- ebiester 10y agoFrom what I can tell, something.js if the amount of code is equivalent. Having a patch or two in angular doesn't seem to move the needle.
- raverbashing 10y agoNo. Because nobody knows about your something.js Getting something on Angular means you were able to get your changes approved and merged (team work) Situation is better if you can have a bigger project or more people using your something.js
- bungle 10y agoWell, left pad was quite famous. And especially famous when the author removed it. You never know.
- patates 10y ago> the current JavaScript landscape seems to have a fairly low index; there are a huge number of tools with very few clear winners at this point in time This isn't a problem by itself, the problem is the ever-changing "clear winners" and hordes of people using them with no understanding of their trade-offs. I hear complaints like this a lot: "It was so easy to-do this with jQuery, why is this JS-framework-de-jour so complicated?" - well, why didn't you start with what-you-know and explore their limits litte bit, so you would know what you really needed? With Ruby and Rails, you have a single answer to many use-cases, with JS and the npm, you have many answers to each use-case imaginable and choosing by popularity is very damaging.
- dom0 10y ago> I suspect the best/healthiest ecosystem is probably somewhere in between that of Ruby and JavaScript. Rails may have ultimately hurt Ruby by its dominance, just as the current volatility in JavaScript tools seems to drive some people away (or at least add frustration). I think this description matches the Python web ecosystem quite well. Historically there were the Z(ope)-ish projects, which still exist and are being used (and they work quite nice); Django obviously dominated for a long time, but in more recent years some healthy competition ensued (Flask and it's highly modular approach for example, but also Pyramid), which resulted in a lot of reworking and improvement for all frameworks. Django now vs. Django 2010 is a vast difference in developer and user friendliness. Some specialized frameworks popped up (Tornado comes to mind), but overall there isn't a heavy fragmentation of the ecosystem (bad) but no one dominator either (bad).
- collyw 10y agoIts nice that there is one (fairly) obvious choice to go for unless you have specific needs.
- oblio 10y agoThe Java ecosystem is another good example IMO. Web frameworks: Spring, Java EE, a lot of solid smaller ones. Build tools: Ant (mostly legacy), Maven or Gradle. Then for almost any niche there's usually 2-3 clear contenders, production-grade stuff. For such a huge ecosystem Java is remarkably not-fragmented.
- morgante 10y agoIn practice, there is usually only a single dominant technology at a time even in the JavaScript ecosystem. See this recent survey: https://news.ycombinator.com/item?id=12627693 https://news.ycombinator.com/item?id=12627693 Right now it seems very clear that React, Redux, and Webpack are winners. The difference, I think, is that many of these tools are simple enough that if you have a new idea you will simply write a replacement instead of trying to work with the maintainers to push out a dramatically different new release.
- haney 10y agoI agree that there is a high risk of project abandonment and it is frustrating that we haven't yet found a consensus around javascript frameworks. But, I would argue that Rails became dominant because it was so much better than the alternatives, we're in the messy part of the cycle where we're not sure what the next great/common/standard library or framework is going to be, but on a long enough timeline I'm confident that the best abstractions/communities/frameworks/libraries will be the most popular, because they allow developers to produce the best things quickly. We're a part of the immune system that helps us to converge to that reality.
- erikpukinskis 10y agoHere's another hypothesis: Language communities are in an arms race to create the best platform for the Cambrian Explosion of tools necessary to support a dramatically growing and diversifying developer population. Languages with a proliferation of tools, where developers are experiencing choice fatigue, have the incentive and the usage data necessary to design the meta-tools that will make development in such an environment easy. Languages which rely on small selection to solve the problem will remain niche languages. We're just waiting for some innovations in package/community/docuentation/source control management to crystalize and make the whole problem moot.