While criticizing the current state of affairs, it
gives a nice overview of many of the emerging technologies
and how they fit together, even if for some tasks
it feels retarded to pull such an entangled mess of
dependencies.
You can then go insane diving into any particular one :)
Being primarily a Java dev, it felt to me like half of this was critiquing the churn rate of using different tools (warranted) and the other half was lamenting the fact that people built tools to solve the common problems they have when developing in large teams (largely unwarranted). Most of those tools have direct equivalents in the Java ecosystem (and there is tool-churn in Java too, just slower).
Facebook, Google, large startups, and the others which are building these tools are doing so to solve the problems they experience in their teams' front-end dev processes. Ironing out the kinks in the code assembly line. And they are of course doing so in a path-dependent fashion: add tool N+1 to solve problem N+1 given the existing toolchain. The result is a lot of tools and a lot of context to imbibe at once, but it doesn't mean they are solving nonexistent problems. Just problems you don't have, or don't know you have, or don't have yet, or can afford to leave unmanaged when developing a small site with just a couple people.
I have run into the problem discussed in the article multiple times. The first time was with Java, specifically J2EE. It isn't that these are non-existent problems, it is that all of the solutions require a full pull of the entire context. That is bad for both learning and software architecture. I was going to start moving in the J2EE direction (I knew Java itself fairly well), but I realized that getting the most basic program up and running would require knowledge about about 7-10 frameworks. That was ridiculous. Additionally, Java was terrible about framework installation at the time, so that made it even worse.
My preference, and I think it is born out by successful long-term projects, is to always keep everything to a minimum. A lot of people say things like, "that's not the optimal way" or "you could make the page load faster" or "you could integrate with xyz".
But, at the end of the day, you have to measure bang for the buck. Bootstrap - VERY high bang for the buck. Jquery, likewise. Pretty much everything else doesn't start yielding dividends until you are at a facebook-level application.
Which, frankly, is fine for Facebook-level applications. But the problem is that people are using these for everything, which is totally ridiculous. How they find people to pay for all of this is what really blows my mind.
Yes, it is called "Enterprising the sh out of it". And yes, Java (and C#/.Net) has a huge problem with that and Javascript is well on its way.
Large companies love to get cool haircuts and wear torn jeans and talk about building fast and being agile and yet, they continues to build frankenprojects.
I can't speak to other projects, but I know the additional pieces of tooling I add to my buildchain are there to automate tasks that are otherwise undocumented/uncaptured and thus easily forgotten (Joel Test, step 2). On a team of ~50 core committers and ~100 intermittent committers across the globe (which isn't that big compared to other teams), if it doesn't have a CI build running and passing regularly, it will eventually break and stay broken. Examples: code generation, database schema generation and checking, dependency compilation, building artifacts. Other pieces of tooling I add to orthogonalize and amortize common tasks, e.g. Dagger2, Immutables, AutoFactory.
Again, I'm not familiar with flavor-of-week web dev stacks and I'm not defending all of it, but there are clearly steady-state benefits to tooling, even if the initial setup often ends up being a maze because it isn't in the critical path of core developers.
I think there is huge benefit to be gained from projects considering the aggregate bootstrap effort required to get the whole stack running. But I still think this fragmented, modular approach, even with the downsides discussed in this thread, is better than the likely alternative: depending and waiting on a company like Microsoft to deliver a monolithic development environment for which a Product Manager has spent literally years crafting and honing the bootstrapping experience before release.
Yes, but I really don't like the "How it feels to learn Javascript" title. Realistically you wouldn't give such a wide array of options to someone who wants to learn how to accomplish something specific.
Yes, realistically if you were to have a conversation with an experienced advisor like the article is staging that wouldn't happen. However, the article reflected exactly how I felt trying to do more JS again a few months ago after not having done much JS for a few years.
While criticizing the current state of affairs, it gives a nice overview of many of the emerging technologies and how they fit together, even if for some tasks it feels retarded to pull such an entangled mess of dependencies.
You can then go insane diving into any particular one :)