Too Many Tools and Frameworks (2015)

http://mrmrs.io/writing/2015/07/27/too-many-tools/

by moeamaya • 10 years ago

274 118 10 years ago

swyman• 10 years ago

Ultimately the responsibility to pick reliable tools lies with the carpenter

jaggederest2• 10 years ago

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• 10 years ago

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

keyle• 10 years ago

True but most often the carpenter is misinformed by crowds or large corporation pushing their tools as "the best in the business".

KaiserPro• 10 years ago

only if they are an arse, and can't figure out changes in quality of work.

bigiain• 10 years ago

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

michaelchisari5• 10 years ago

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.

mgalka• 10 years ago

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

KerryJones3• 10 years ago

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

thomasnno• 10 years ago

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.

bungle2• 10 years ago

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

reubano• 10 years ago

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

noselasd• 10 years ago

"planned obsolescence" for lightbulbs is not a recent thing though; https://en.wikipedia.org/wiki/Phoebus_cartel

KerryJones3• 10 years ago

How so? Energy consumption is far less, the raw price is much cheaper, varieties of brightnesses and Kelvin, different quality of lights, different designs for the aesthetic look.

We even have smart light bulbs -- my door light turns itself on and off at dusk and dawn.

michaelchisari5• 10 years ago

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.

highmastdon• 10 years ago

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

michaelchisari5• 10 years ago

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?

59nadir3• 10 years ago

I think the real markers should be that a person is not afraid of broadening their views. Usually, the advice for hiring for Erlang, as an example, is not to hire people that know Erlang, but focus on hiring good people (who are capable of learning beyond your average C-like) and then teach them Erlang. It's a small and very easily learned language, for sure, but learning it is certainly a bigger undertaking than learning a JS framework.

It astounds me that hiring for JS frameworks actually is that specific, considering you're likely passing up on people that are simply better problem solvers.

lucaspiller• 10 years ago

I've been trying to learn Angular2 recently, maybe I'm not a good developer (but I faired ok with Erlang :D), but it really is such a struggle. Documentation is lacking, and what is available is often wrong or outdated. It doesn't help that half the tools and libraries are still in 'beta' and breaking changes are seen as a way of life.

This post really sums up my experience, and I've done plenty of Javascript before (I just haven't kept on top of client side frameworks):

https://hackernoon.com/why-learning-angular-2-was-excruciati...

If I were to hire someone to work with me, I would try and find someone who has experience with Angular2. Angular2 vs JavaScript are effectively different technologies compared to Ruby vs Rails.

I'd actually say for someone completely new (e.g. locked in a basement doing C or Java for the last 20 years), learning Erlang would be far easier than learning modern JavaScript and Angular2.

crdoconnor• 10 years ago

But the issue for me is how employers handles it.

Often they opt for what's "hot". Which is the worst possible approach. Or for what it seems easy to hire in (which isn't much better).

throwawayReply• 10 years ago

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

perlgeek• 10 years ago

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.

A possible approach is to let developers new to a framework on a prototype or toy project first, and, very important, throw away that prototype.

Yes, that means you might have to wait two or three weeks longer until you get started with the real project, but the result will be so much better.

But that's one of the prices you pay for using an immature technology. For a more mature one, you could read a book on successful usage pattern of the technology.

michaelchisari5• 10 years ago

full apps often end up with controller-as-a-god-object.

Wouldn't a depth of knowledge of dev patterns (and anti-patterns) be enough?

I don't have to know anything about Angular to know that's a bad idea.

acdha• 10 years ago

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.

dperfect• 10 years 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

inopinatus• 10 years ago

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?

usgroup4• 10 years ago

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

vog• 10 years 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.)

electic• 10 years ago

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• 10 years ago

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?

sorokod• 10 years ago

Are you saying that JS devs are different from Ruby devs in this regard?

lettergram• 10 years ago

I somewhat agree...

However, there is also something to be said for rewriting work. There's the concept of "plan to throw it away"[0] I think a lot of these projects start because people are just trying to learn. Then they share them and get built upon. You then have an ever increasing amount of technical debt, eventually inspiring others to write a simpler version and then that becomes the defacto and so it continues...

I think my favorite example of just stupid stuff that keeps getting propagated is the Date type in javascript - the month field starts with "0", but the day field starts at "1"[1]. Like what is with that?

Even with everyone contributing to Javascript that stupid thing still exists because you can't break the internet to fix it (ask the Python community how changing a lot of syntax works out - although Python wasn't even that bad). That's why people write new stuff, because they want to make things simpler. Not really something to complain about IMO.

The unique stuff I learned is probably just these four languages: BASIC, C, C++, Python - I learned it in that order and now I can pretty much do w.e. language I need to use. Because all frameworks are based off the same stuff. Go is easy, Javascript - no problem!, I do full-stack work and data science in my day job it's really not hard at all. All the frameworks make it even easier.

[0] https://en.wikipedia.org/wiki/The_Mythical_Man-Month

[1] http://www.w3schools.com/js/js_dates.asp

throwmenow_0139• 10 years ago

I second the part about ego. I once wanted to write a BaaS because I was not happy with parse-server. After considering the time efforts and comparing it with the efforts to improve parse-server I decided to just improve that software and don't care about my own project, because I try to value my time higher than my ego. It isn't easy to be rational if your ego is involved.

But it's also difficult to decide if it's worth it, especially if you've found a real deficiency. The creator of http://propelorm.org said to me that his framework gets him €120k+ offers and that he recommends building open source projects that are in demand.

So I don't think it's possible to give a definite answer what developers should really do. Maybe bit of both?

ravenstine• 10 years ago

You took the words right out of my mouth. It has more to do with ego than everything else, and you can tell because most competing tools, in JS anyway, don't have a significant edge over the others and are largely the same tool reimplemented without much of a concrete goal besides "performance" and "scalability ". Like you said, taking an existing tool with a deficiency and rewriting it from scratch without that deficiency. Advances have occurred for sure, but not without some massive failures from not having a good roadmap. Brute force, in other words. The projects that do have more concrete goals and vastly different methodologies in the JS world happen to be low in popularity, relatively speaking. I wonder if the inflated egos in the JS community comes from all the talk of "Node.JS is the future" in recent years. There aren't nearly as many competing projects in the Ruby world, or Python or even PHP.

mamcx• 10 years ago

This not work at all, is super-unrealistic.

And it grow more un-fixable as longer and bigger is the project.

For example: Fix C. Or javaScript. or Angular.

Is impossible to do it without change what them are. And when the trouble is intrinsic the only sane option left is restart.

In fact, stick to old is as worse (and maybe more) then rewrite. The trouble is when rewrite not change enough to be worth it.

patates2• 10 years 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• 10 years 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• 10 years ago

Its nice that there is one (fairly) obvious choice to go for unless you have specific needs.

oblio2• 10 years ago

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

morgante3• 10 years ago

In 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

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• 10 years ago

I 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• 10 years ago

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.

blowski• 10 years ago

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.

drawkbox• 10 years ago

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.

asimuvPR2• 10 years ago

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• 10 years ago

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

asimuvPR2• 10 years ago

They should definitely try to do things differently. Even when the end result is the same. The reason is simple: it provides an alternate point of view of the problem. Some issues only appear when we try to do things differently. Those issues might exist in the more common approach and be completely unknown.

austinpray• 10 years ago

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.

piotrkaminski• 10 years ago

On the contrary: when looking for a global maximum you will almost certainly have to pass through local minima, so different _is_ good in this case.

TheAceOfHearts• 10 years ago

I disagree. With webpack you declare all dependencies are resolved and declared with code, instead of a separate manifest. It's a big improvement over gulp and grunt.

I don't know why people compare gulp and grunt with webpack, they solve different problems.

niftylettuce• 10 years ago

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

symlinkk• 10 years ago

lol, this is exactly what OP is talking about

DSteinmann2• 10 years ago

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• 10 years ago

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

mastazi2• 10 years ago

When I clicked on that link I was really hoping to find a Rick Astley video.

rurounijones• 10 years ago

I am honestly not sure if this is some satirical masterpiece or not.

The README says yes but the amount of work that has gone in to it...

gaius• 10 years ago

I upvoted it on the basis that it was!

imtringued• 10 years ago

I'd like to see more chicken comics.

AdrianB1• 10 years ago

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.

usgroup4• 10 years ago

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

KerryJones3• 10 years ago

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.

joelhooks• 10 years ago

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.

rekshaw• 10 years ago

Can you provide a shortlist of the tools you use?

progx• 10 years ago

The list won't solve any of your specific problems.

I had a much better list, then the previous Poster, because it solve my problems the best way.

Did you need my list now too?

I am absolutely sure, that somebody else had a better list.

amelius• 10 years ago

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?

leppr2• 10 years ago

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.

spdionis• 10 years ago

That we actually can target all of them more or less easily?

hoodoof• 10 years ago

The solution - don't use them.

Walkman• 10 years ago

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.

satyajeet23• 10 years ago

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

DanielBMarkham• 10 years ago

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.

menckenjr• 10 years ago

This x 1000. As an additional perspective, I used to be on the board of trustees of my church when we were picking new bookkeeping software (for a church whose annual budget was less than $100K). We kept getting shown software that "handles everything for you" and eventually got strongarmed into Quickbooks (which the treasurer set up wrong) and nobody listened to me when I told them that unless they knew the finances well enough to run them with a paper spreadsheet, a checkbook and a calculator they had no business picking software.

The point of that story is that it takes a long time to properly understand a problem domain well enough to start solving problems in it at the right level of abstraction. A framework can "understand things for you" and just work if you set it up right, but the cost is that you lose the freedom to replace that framework with something smaller and lighter.

JustSomeNobody• 10 years ago

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• 10 years ago

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.

fauigerzigerk• 10 years ago

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.

andres_kytt• 10 years ago

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.

jomamaxx• 10 years ago

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.

heinbehrens2• 10 years ago

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 .

heinbehrens2• 10 years ago

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.

dataharry• 10 years ago

Wake me up when the good ones are created then

userbinator• 10 years ago

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.

sotojuan2• 10 years ago

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/

cel1ne• 10 years ago

Tachyons is amazing, so I ported it for react-native: https://github.com/tachyons-css/react-native-style-tachyons

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

dkarl2• 10 years ago

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?

weberc2• 10 years ago

I agree. I program in quite a few languages, but Go is my favorite when it comes to a low-bullshit ecosystem. There are probably too many web frameworks, but the standard HTTP library seems to have the bulk of the marketshare.

morgante3• 10 years ago

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

dkarl2• 10 years ago

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?

amirouche3• 10 years ago

There is a clear distinction between a framework and library. AFAIK a library is focused to solve a particular problem for instance routing, data validation, i18n, state management, view rendering (like templates systems), data models etc... On the other hand framework try to tackle a set of related problems into a coherent/logical workflow. For instance there is not a single library that can handle by itself the issue of isomorphic apps. Angular is a framework, reactjs is a library but http://reactboilerplate.com/ is framework using reactjs.

I think backbone is framework not a library it tackles several issues (class system, views, and middle end) and it does it badly but that's a topic of ~another post~ the past.

Historically Javascript community has favoured the do-it-yourself framework hence or because there is a lot of libraries you can choose from or because the needs of everyone are so different that's it's difficult to create a miningful framework. Mind the fact that Google previous "framework" named Google closure was a stdlib kind of framework compared to the competition of MV* framework like emberjs or angular it did not force a given workflow.

dreta• 10 years ago

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.

vanillajs• 10 years ago

.io domain

why am i not surprised

Too Many Tools and Frameworks (2015)

Related Stories