Live data from Hacker News

Too Many Tools and Frameworks (2015)

mrmrs.io

11–20 of 125 posts

Re: Too Many Tools and Frameworks (2015)

#11

For side projects, it can be a little daunting, but ultimately represents a healthy eco-system. But the issue for me is how employers handles it. No, I don't know Angular. But I have used Backbone, Ember & React. So do you really need an Angular expert, especially when Angular is only a few years old and is completely changing in Angular 2? Should employers insist on extensive trade knowledge in a specific framework,…

@michaelchisari honest question: are you a bit discontent with the fact that you don't know angular framework?

Not at all. Angular, from an architectural standpoint, is not something I would necessarily gravitate towards, although given a little time and proper documentation, I'm confident I could build something in it, so I don't feel very left out.

Why do you ask?

Re: Too Many Tools and Frameworks (2015)

#12
post #2

Ultimately the responsibility to pick reliable tools lies with the carpenter

The problem with that is that there are accepted standards for tooling for carpentry. Sure, there are 900 different kinds of tools, but they all solve a minimal subset of measuring, cutting, drilling, holding, joining, and smoothing. There's no equivalent of the basic problems of carpentry in the profusion of javascript libraries. Many of the libraries written in the last year solve problems created by other librarie…

Right, which we need to solve through better ways of curating projects as a community. Browsing through 20 different options in npm trying to guess which ones are good is not a scalable way to build software.

The long term answer isn't to have fewer options or barriers to entry for new frameworks. The right solution is to make better ways to browse and select between all the options we have available.

Can we curate libraries algorithmically? Or do we need people to do it? (And if so what should their tools look like?)

Re: Too Many Tools and Frameworks (2015)

#13
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

Re: Too Many Tools and Frameworks (2015)

#14
I confess to being one of the people who moans a lot, but this post might be right. I will try to moan less because the JS community has made a lot of progress. I guess the secret is not getting caught up in hype, and focusing on the real value.

Re: Too Many Tools and Frameworks (2015)

#15
post #9
post #2

Ultimately the responsibility to pick reliable tools lies with the carpenter

On the other hand, a carpenter can buy a good hammer/set of chisels/block plane/circular saw - and use them for decades without cow orkers or project managers questioning their choice of tool and demanding they use completely different incompatible ones...

Imagine if every six months, your circular saw became incompatible with the version of wood you need to cut.

Meanwhile, the hammer you use is no longer supported, and breaks every time you pick it up, but using a new hammer means changing every single nail in the parts that you've already completed.

Then the job ends, and you look for a new job, they don't think you're qualified because you used the same chisel for two years, and don't think you'll know how to use the new chisel design that came out 3 months ago.

Re: Too Many Tools and Frameworks (2015)

#16

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…

I'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?

Re: Too Many Tools and Frameworks (2015)

#17
The tools + framework for webdev are javascript, html and css (and assets i.e. images/data). Everything else is an abstraction that has trade-offs.

Frameworks can help teams create a baseline standard. A custom framework can be something that you need to educate other developers with, better to have an external framework at times. But at the rate of churn, depending on the team and product, some frameworks makes sense and some don't. Monolithic frameworks are harder to change, micro can swap more easily.

Really in the end, all frameworks and tools are abstractions to help accelerate development, but sometimes they don't, and one case of that is constant churn. New frameworks are a healthy sign for active development but they also have a cost associated with them. Frameworks can also abstract away too much and shroud the real platform/standards which leads to lock-in. Each project and product has needs that some frameworks fit and some don't, real development/engineering is deciding what a product/project needs.

Re: Too Many Tools and Frameworks (2015)

#18
The only way we are going to build better tools is to keep building them. Complaining about the sort of cambrian explosion going on right now on web development is short sighted. Ideas need to be discovered, explored and improved. Everything needs to be challenged. This is unknown territory in many ways. It does get a little hectic and tiring at times but that's the price we pay.
Post reply on HN