
Too Many Tools and Frameworks (2015) - moeamaya
http://mrmrs.io/writing/2015/07/27/too-many-tools/
======
dperfect
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)

~~~
electic
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.

~~~
ffggvv
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?

~~~
raverbashing
Which 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
From 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
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

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

~~~
alxndr
Was it famous before the author removed it?

------
michaelchisari
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,
or should they be able to hire based on understanding of development and
architectural principles, and give a new employee a little bit of leeway to
get up to speed on their stack.

If it's the latter, then you can relax, and focus on reinforcing good
practices and understanding the theory about what you're working on, and your
resume will continue to build.

If it's the former, then you have to constantly pad your resume with
skunkworks projects simply so it doesn't seem like you're getting "left
behind." And that is exhausting, and not very useful to anyone.

~~~
throwawayReply
(This isn't a personal attack on you or your ability, I don't know you)

I think yours is a dangerous attitude, I've seen a lot of mess produced by
people who come in to angular knowing other frameworks and their output is
terrible.

Part of that is because angular is different, it's not very nice and it has
obscure knowledge needed to make it play nicely with unit testing.

If you take an ember / backbone / whatever expert and give them a few weeks
angular training they'll rock a todomvc but full apps often end up with
controller-as-a-god-object.

Genuine experts would be really nice to find, but it's really difficult
because frameworks aren't given time to mature before the smartest people have
moved on to other frameworks.

You're right that employers should hire on general understanding and give
time, but the required time is typically 6 months and a failed project or two.
Many employers don't make and don't want to make that kind of human-capital
investment anymore.

The "rockstar" who knocked something up pads their resume with another project
with a hot new framework, got experience with another new set of tooling and
can leverage that to move somewhere else to produce more working but hard to
maintain code in another hot new framework because their CV is padded with
experience showing they're a quick learner, but the company left behind pays
the cost in maintenance.

A genuine angular expert will likely be well employed for a while come helping
troubleshoot and clean up the mess left by the cool crowd.

p.s. I am not an angular dev, this complaint can be leveled at a lot of hot
new tech, particularly but not just the javascript front-end world, it equally
applies to people who knocked up go microservices at a .Net shop, or hastily
introduced mongo to replace oracle, etc., etc.

~~~
acdha
> I think yours is a dangerous attitude, I've seen a lot of mess produced by
> people who come in to angular knowing other frameworks and their output is
> terrible.

Outside of a hire-an-expert consulting gig, I really would say the problem
here lies almost exclusively on the engineering management, or lack thereof,
and broader staffing decisions. I don't think it's necessary to have a project
fail for someone to understand a tool[1] but the ability for someone to get up
to speed is a function of the time invested in things like mentoring and code-
review.

Yes, many companies make the short-sighted decision to skimp on that
investment but that needs to be recognized and fought as a management problem
– any project is going to suffer in those conditions even if your entire team
is staffed with experts because understanding the actual business problems is
as hard as the tech stack and if you can't carve out time to think about a few
controllers, there's no way that the rest of the problem doesn't have problems
which are at least as bad.

1\. If true, that would be a huge sign that the tool has major design failures
and is not suitable for production use rather than an argument against hiring
people who aren't already experts.

------
dkarl
As a back-end developer, I find it interesting that the default answer is a
_framework_ — the state of affairs that prevailed ten to twenty years ago in
server development. Enterprise Javabeans, Spring, everybody assumed that big,
overarching frameworks were awesome and you couldn't afford to do without
them. Our experience with that mindset has pushed us to the opposite default
assumption: everything is better if it can be done as a library than as a
framework. We look for libraries that humbly strive to coexist with whatever
other libraries we need. The few times I've dipped into web UI Javascript,
I've felt like the developers of UI "frameworks" share this mindset much more
than the people using their work; often they'll explicitly point out that the
tool they've built (such as backbone.js) is a _library_ rather than a
framework, while the people recommending it to me will say "no no, it's a
_framework,_ " meaning "no no, it's way better than just a library." Is that
an expression of a real difference between back-end and web UI code, or is it
just different phases in the tide of opinion?

~~~
morgante
I'm pretty sure you're just playing with words here.

One of the most common complaints is that the biggest web tools are libraries,
_not_ frameworks. React, for example, is very emphatically _not_ a framework.
To develop any reasonably sized application, you need to bring in a number of
other libraries as well (such as Redux and/or Apollo).

~~~
dkarl
It isn't just words — the words reflect people's expectation that a framework
determines quite a lot about your design and approach. It's a system and a way
of programming you assimilate into. A library tries to help you do something
while dictating as little as possible about your overall application design.

I think it's very interesting that even though the expert and experienced
programmers who create things like backbone.js and React have openly and
explicitly designed them _not_ to be frameworks, people continue to call them
frameworks, and not disparagingly. There seems to be a huge appetite for
frameworks. From the outside (and definitely projecting my own inexperience) I
would guess that a lot of people feel lost architecting a web UI from scratch.
They don't want building blocks. They want a _way,_ a path to follow. A lot of
server programmers felt the same way twenty years ago. Adopting a framework
meant giving up freedom that they didn't want in the first place because they
didn't know what to do with it.

But I'm coming at it from a very outside/inexperienced perspective, so I feel
like I should leave it as a question rather than a comment. What do you think?
Why are frameworks considered such a good thing in web UI programming that
widely used and admired libraries end up being called "frameworks" as a term
of respect?

~~~
amirouche
First you can use reactjs alone without a flux architecture.

> Why are frameworks considered such a good thing

The only thing nice about framework is that they make the main workflow
obvious. But things becomes scary when you walk on the wild side (backed by
experience with Django and Django RESTframework)

The problem with reactjs is that facebook was using reactjs and its
"architecture" for big apps and now they try to make it work in a more general
context.

> in web UI programming that widely used and admired libraries end up being
> called "frameworks" as a term of respect?

Backbone is framework, saying it's a library because you can use only the
collection model and use whatever method you want to fetch your data or
whatever template language or bind events yourself is like saying you can
replace the URL routing or template language of Django on your own. Doable but
not recommended.

------
fauigerzigerk
I think the complaint about too many tools is really just a euphemism for
complaining about peer and employer pressure to always be up-to-date with the
latest tools and styles. Developers live in constant fear of falling behind.

But is this pressure justified? I see two possibilities:

a) The latest crop of the top 10% tools really makes us much more productive
than last year's crop of the top 10% tools. So the best developers will always
filter through a lot of new tools to find the best 10% and benefit from them.

b) After accounting for productivity losses incurred by constantly relearning
and rewriting everything, the lastest best tools have no productivity
benefits. They are just a distraction from the product we're supposed to be
working on.

I don't think there is ever a time in history when this question can be
answered unequivocally, and therefore it is never possible for good developers
to stop looking for better tools completely.

However, I feel that at no time in the past quarter century has the pendulum
swung so far in the direction of (b) where front end development is concerned.
I realize this is very subjective.

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

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

~~~
douche
The tools need to be better than what came before, rather than just
_different_. So far I've dealt with grunt, then gulp, then webpack. None of
these are appreciably better than make, they are just different and newer...

~~~
austinpray
You don't understand what webpack is. It's a module bundler. You use webpack
in conjunction with make, grunt, gulp, or any other task runner or build
system.

~~~
vonmoltke
What do you use make, grunt, or gulp for in that case? My frontend build
command is just "webpack". Everything necessary is handled in
webpack.config.js.

------
userbinator
I think the problem isn't "too many" \--- it's the fact that they're all
reinventing the same things and adding significant complexity in doing so.
It's an enormous waste of resources both on the part of the developers and the
end-users who ultimately have to "bear the bloat".

Web development seems unusually prone to this trend, but I've seen it happen
with software in general. I hypothesise that the reason for this happening to
web development in particular is largely because the basic problems have
already been solved long ago, so all this churn is created by people who are
"oversolving the problem", having nothing else to do than to think of new ---
but not necessarily better --- ways of doing it.

Introducing complexity must feel productive to a lot of people, and I suppose
some derive pleasure from being able to learn about, build, comprehend, and
modify such complex systems. But I don't. Making websites that require several
MB of JS and the latest browser features to display a few KB of static text? I
just don't see the point.

Related: [http://countercomplex.blogspot.com/2014/08/the-resource-
leak...](http://countercomplex.blogspot.com/2014/08/the-resource-leak-bug-of-
our.html) and discussion
[https://news.ycombinator.com/item?id=8679471](https://news.ycombinator.com/item?id=8679471)

------
joelhooks
I've been building UIs for 20 years, and the tools we have now are the best
I've ever had the pleasure to work with. It's more fun now than ever. More
please.

~~~
amelius
Except now we have to target 3 different mobile platforms, the web, and
possibly 3 different native desktop environments.

Where is the progress in that?

~~~
leppr
You develop for large and small screens, with either keyboard/mouse or
touchscreen inputs. That's all.

The specifics are supposed to be automatically handled by preprocessing and
deployment tools, or only cared for in the optimization/final polish phase.

------
mgalka
> "Using the same standards that categorize 90% of science fiction as trash,
> crud, or crap, it can be argued that 90% of film, literature, consumer
> goods, etc. is crap."

90% is also roughly the failure rate of startups. Pareto principle?

~~~
KerryJones
Yep, you just very concisely explained a comment I just wrote (I didn't see
this one).

------
dreta
The problem with “don’t re-invent the wheel” approach to software development
is that, IMHO, software engineers are yet to invent the wheel in the first
place.

------
swyman
Ultimately the responsibility to pick reliable tools lies with the carpenter

~~~
jaggederest
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 libraries_.

People forget that the reason Rails was such a revolution is that it took all
the fifty kinds of crap that people used to build an application and made it
available in one package with good defaults. The good defaults part of that is
absolutely critical.

The problem is not "bad libraries", it's a complete lack of curation and
direction.

~~~
josephg
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?)

~~~
jaggederest
> The right solution is to make better ways to browse and select between all
> the options we have available.

I think you're missing the point. The problem is not "which library is best at
x y and z", the problem is that nobody agrees on what X, Y, and Z are.

It's a definitional problem, not a curation problem. Curation is easy once you
have a yardstick to measure things with (pun intended).

Again dropping back to the metaphor of woodworking, one can clearly evaluate
the results of using any given tool against a thousand years of physical
history - no such comparison is possible with current libraries, especially in
the rat's nest of javascript, and that's fundamentally the issue.

------
thomasnno
I totally get what you are saying but it seems to be to be increasingly
difficult to find the good frameworks, especially since the badness of some
frameworks only manifest on larger scales.

------
AdrianB1
Looking at the long term life of an application, the abundance and volatility
of the tools and frameworks is a nightmare. Who will find developers for ZZZZ
framework in 3 years from now?

Also the fragmentation of efforts to improve the tools is a waste of
resources. Instead of choosing a few directions and delivering, everyone knows
better and it's doing his own version of different, but usually not better,
tool. That will help anyone else? "Yes!", they will say. "I don't care", they
think.

~~~
usgroup
Yes then at some point we all end up using ML, Lisp or C, and then it all
starts again :)

------
DanielBMarkham
I've been a coder and have watched coders for a long time. I consistently see
two trends.

As an agile guy, back in the day I wrote an Agile story tracker. Fun times.
Then I saw some other Agile project management tools. Then for a while it
seemed like every week or two I was getting emails asking me to evaluate yet
another agile/to-do list tool.

It seemed that programmers were unable to grok the agile story concept without
making their own tool to use it.

But I saw the same kind of thing in the code I wrote. I wouldn't just solve a
problem; I'd solve a class of problems. Generalization was awesome! The more I
generalize and account for edge cases, the more value I am creating! Woo!

Many of us programmers, myself included, are constitutionally incapable of
just solving the exact problem we have using the minimal amount of code and
then moving on. _We confuse coding with value creation, so we build frameworks
and tools out of everything._ If you build a list sorter, that's okay, but if
you build a 30KLOC list uber machine, that's better, right? After all, it does
more. You worked harder at it.

The second thing I saw, which was even more painful to realize and accept, was
that it was very easy to get "upside down" in a toolset or framework and not
even be aware of what's going on.

The first time I saw it was when I was teaching a mainframe team Visual Basic,
back in the 90s. We were building a simple form with a textbox and button. I
had showed them the concepts and they were a smart bunch. I started the
exercise, but a couple of developers were stumped.

Why?

When I walked over, the problem they had was the properties page. Sure, they
got the concept of drag-and-drop. But once the button was dropped? There were
like a million options in there! What was the right font size? What did this
thing mean? And so on.

I thought that was pretty silly and tried to forget it. But then I noticed in
my own work that I'd get sold on a new set of tools. For sake of argument
let's use the old Infragistics web controls. They do everything! Amazing
control and look-and-feel!

I'd drop them on a web page wanting to create a smart grid. But the grid
didn't do X, and in my mind, X was what needed to happen. So I'd poke around
at the help file. I'd go online. In some cases I'd tear apart the javascript
and start fixing it myself. Hey, it's only web programming. I can do this.

But holy shit that took a lot of time. On my next project when I needed a
grid? I dropped a HTML table in. Just added whatever functionality I needed
directly from JS. Not only did it take less time, but the resulting codebase
was easier to read.

Then I started watching the teams I coached. They very rarely talked about
actually solving problems, or language/foundational issues. Instead they
talked about tools and frameworks. This tool or framework would do this cool
thing if you tweaked it like this. Joe spent 2 days trying to get Y to work.

 _For many, many teams, buying into the framework means buying into a
complexity and cognitive overhead that 's siomply not relevant to the actual
problem they're trying to solve._ I don't know. Maybe it makes them feel cool
or something. One of the smart kids. But speaking as both a participant and an
observer, it's whack.

tl;dr So sure, let a thousand flowers bloom. But your job isn't arranging
flower baskets, it's helping somebody who's down feel better. You might not
even need flowers at all. Stop focusing on the tools and start focusing on the
solution. Then the tools will work themselves out.

~~~
JustSomeNobody
Interesting, but you're pretty spot on. Personally this has caused me great
angst[0] as I tend to write the absolute minimum amount of code necessary to
solve the exact problem I'm trying to solve.

I tend to wait until I've solved a problem in similar ways three[1] or so
times before I generalize it.

[0] Because other developers want to solve for a more general problem. [1]
Three is such a comfortable number, isn't it?

~~~
crasm
I've noticed I tend to work in three passes, although not necessarily three
tries.

First is an over-abstracted mess that may or not work before it eventually
collapses. Brainstorming.

Second is a rewrite aiming for compactness, that could end up impossible for
anyone else to understand.

Third pulls just the right amount of abstraction out of the terseness of the
second pass.

I treat it like a feedback driven control-system. Too much abstraction? Dial
it down. Not enough abstraction? Dial it up. Repeat until good enough.

If I stop at 1 or 2, the code is poor. If I don't oscillate, it takes more
passes.

------
sotojuan
As an aside, the author of the article is one of the authors of Tachyons—the
library I consider the tool that makes me not want to die when designing web
pages:

[http://tachyons.io/](http://tachyons.io/)

~~~
cel1ne
Tachyons is amazing, so I ported it for react-native:
[https://github.com/tachyons-css/react-native-style-
tachyons](https://github.com/tachyons-css/react-native-style-tachyons)

    
    
       <View cls="ba jcfs pa2">                
          <Text cls="white tc">
              Something
          </Text>
       </View>

------
KerryJones
This is simply the Pareto principle (80/20) rule, and it's true of most
things.

This is also true of Startups -- most of them die, but that doesn't mean they
didn't add value in validated learning (positively or negatively).

Elon Musk has often stated that he thought Space X had very little odds of
success, but he continued because he believed he could create value that
someone else could build on.

------
Walkman
I disagree. When more developers build the same framework, quality will always
be better, because it will be better tested, more reviewed, has more
knowledge, has more integrations with tools, packages, other frameworks. I
really hate when effort on the same area is distributed. When you have
multiple tools instead of one, it's hard to find the best one.

------
jomamaxx
This is all fine and good - but it would be nice to know which one's work
well, which are robust, and which one's are 'pro level' \- without have to
experiment with each one.

It's really hard to tell these days.

After some experience with node.js - I'm weary to pluck anything that's not in
the 'top 10' most established frameworks.

------
dataharry
Wake me up when the good ones are created then

------
andres_kytt
It's a feedback problem. People seek to solve problems and by doing so create
new ones. Which also need solutions. That create more problems. Packaging,
transpiling etc are already second order problems and there are third and
fourth ones as well. This won't stop until js becomes completely unusable.

------
satyajeet23
(DEVELOPARALYSIS) [[https://techcrunch.com/2014/10/18/you-too-may-be-a-victim-
of...](https://techcrunch.com/2014/10/18/you-too-may-be-a-victim-of-
developaralysis/)]

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

------
heinbehrens
Java had the same issue in the beginning. Then time and money made many
disappear. Now it is Spring and JSF. The hundreds of other frameworks have
largely disappeared .

You need organisation. Which is again time/money/resources.

------
heinbehrens
Java had the same issue in the beginning. Then time and money made many
disappear. Now it is Spring and JSF. The hundreds of other frameworks have
largely disappeared .

------
niftylettuce
I'm building a better JS framework [https://github.com/crocodilejs/crocodile-
node-mvc-framework](https://github.com/crocodilejs/crocodile-node-mvc-
framework) \- release v1.0.0 comes out soon, join in Slack at
[http://slack.crocodilejs.com/](http://slack.crocodilejs.com/)

~~~
DSteinmann
> 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.

~~~
enraged_camel
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...](http://www.javaworld.com/article/2079190/scripting-jvm-
languages/6-things-you-should-know-about-node-js.html)

~~~
DSteinmann
I know that. I wouldn't touch node with a 10 foot pole (after past
experiences) and since the parent comment's framework is integrated with Node
it's a non-starter.

------
hoodoof
The solution - don't use them.

------
vanillajs
>.io domain

why am i not surprised

------
bungle
Light bulbs have not improved, they have become worse, and are designed to
fail.

~~~
reubano
The parent is right after all. Just do a search for "the 100 yr light bulb".

~~~
noselasd
"planned obsolescence" for lightbulbs is not a recent thing though;
[https://en.wikipedia.org/wiki/Phoebus_cartel](https://en.wikipedia.org/wiki/Phoebus_cartel)

