Live data from Hacker News

Too Many Tools and Frameworks (2015)

mrmrs.io

121–125 of 125 posts

Re: Too Many Tools and Frameworks (2015)

#121

Earlier quoted context omitted.

> CrocodileJS is a Node MVC framework that lets you chew apart JavaScript Four words in and CrocodileJS is already lumped onto the 4/5ths heap of unusable frameworks (Node is an immediate non-starter in the same vein as MongoDB). Just to give you some perspective and perhaps help you see the irony.

Node is an application runtime environment, not a framework. There are frameworks written on top of Node, such as ExpressJS. http://www.javaworld.com/article/2079190/scripting-jvm-langu...

GP said:

> CrocodileJS is already lumped onto the 4/5ths heap of unusable frameworks

in this context, "framework" seems to refer to CrocodileJS, not Node.

Re: Too Many Tools and Frameworks (2015)

#122
post #114

Earlier quoted context omitted.

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

Well, left pad was quite famous. And especially famous when the author removed it. You never know.

Was it famous before the author removed it?

Re: Too Many Tools and Frameworks (2015)

#123

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…

Here'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.

Re: Too Many Tools and Frameworks (2015)

#124
post #43
post #24

Earlier quoted context omitted.

I 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…

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

Sure. E.g ECMAScript supported versions, HTML5 features, HTTP2 support, mobile/tablet specific browser features, CSS1,2,3 support.

Re: Too Many Tools and Frameworks (2015)

#125
post #39
post #27

Earlier quoted context omitted.

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

Nope 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?

It actually helps if you contribute to an existing project, because it is like, you worked with others on an existing codebase and contributed features in a big project which has high visiblity and is being used in real life by real people.

Much of what we work is all with people and on large codebase, so if you are contributing to existing project, it is actually helpful for interviews. Also it takes weeks to get a PR accepted, so if you actually were successful in getting your feature accepted, it shows your resolve to contribute the feature because you want to contribute and not because you want to do a PR stunt for your career (and not get annoyed by the constant changes which the authors ask, which are close to a million)

Post reply on HN