- Artículo extraído desde:
this is the only paper that’s willing to tell the truth: that everything is just fine.
There’s a sort of blog post you’ve probably read - a sarcastic stab at
npm and frameworks. There are too many, it’ll say, and
it’s confusing, and how did we make such complicated things? It’ll grab
names from the ecosystem and present them as equal choices in a comic
attempt to construct decision paralysis. Everything moves too fast, and
there is too much of it.
I think it’s a decent time to review some principles
Obsession with shiny things is a personal problem and something you can avoid
I occasionally hang out on guitar forums. They have a name for this thing: Gear Acquisition Syndrome, or GAS. It is what it sounds like
- when you’re more concerned with getting an OCD Fuzz pedal to round out your rig than you are with learning how to play the instrument.
GAS with guitars works the same way as with programming: you start asking whether you’re using the best possible distortion pedal, start your research, and a few weeks later you own $2,000 worth of distortion pedals.
Coding is a craft, for which you need tools. Some of them are shiny, some are new, some are old. They all basically work. Change your tools if they aren’t working for you, and otherwise don’t. Heck, for many startups and almost all early-stage startups, the choice of technology stack really doesn’t matter.
You have to use different tools for different problems
Creating a data visualization? Probably use d3. An application? React and Redux. A library? You might not need any framework.
Sometimes materials are best-in-class for what they do: now that there’s lodash, there are relatively few reasons to use underscore. Other times they’re still duking it out to see what’s best - browserify or webpack, for example, fix the same problem. But a lot of the time they’re clearly for different purposes: I, for instance, use React when writing a large application like Mapbox Studio, but don’t use a framework writing libraries that need to be small.
As you learn and grow, you’ll acquire a go-to list of technology for each task. It isn’t the same as an exhaustive list: at most you might know 5 systems thoroughly. You mainly become capable by mastering these systems, not by tinkering with every alternative.
If someone is holier-than-thou about technology choices, they’re wrong and you should ignore them
If you read the snark, it sounds like you’re required to switch frameworks as soon as a new one accrues more stars on GitHub. Or that you must use functional programming. This may be the case in San Francisco - I don’t live there - but in the rest of the world, that’s nonsense. There are successful companies using every stack, from PHP to Haskell.
October 4, 2016 @tmcw