One problem with front-end development at the moment is that there are such a ridiculously large number of ways of doing things, such an incredible rate of churn, that there is this sense that you have to say something to justify whatever choices you've made. Perhaps because the actual arguments for choosing, say, Webpack over Browserify really aren't very strong (perhaps both are great solutions to the same problem; perhaps neither are perfect solutions and will be superseded in another six months!), there is a tendency to resort to an emotional and dismissive argument, the so-called "smack talk" mentioned in this article.
Certainly it's frustrating for any front-end developer who has invested his time in learning Grunt only to find out he should now be using Gulp, or Broccoli, or make(1)...
There's nothing wrong with saying "I chose technology X over technology Y because they are basically the same, they each have small advantages in certain areas but nothing that will materially impact our success, and making any decision is better than making no decision."
I remember the last time there was this sort of fragmentation and polarization in the web framework world (2005-2007), I chose Python & Django over Ruby on Rails because, well, I liked it better (that and the RoR community had a certain evangelistic quality to it that turned me off, while Pythonistas are basically like "Yeah, it's a tool. I can build cool stuff with it. Let's move on and solve some problems"). I'll freely admit that it doesn't matter, Ruby is a fine language, and Rails is a fine framework. But they do largely the same thing, I've never once regretted my choice, and I've been able to build some pretty cool things with the energy that wasn't expended getting emotionally involved in language/framework/tool wars.
> There's nothing wrong with saying "I chose technology X over technology Y because they are basically the same, they each have small advantages in certain areas but nothing that will materially impact our success, and making any decision is better than making no decision."
Well, except that saying that X and Y are effectively the same is not a great method of getting booked to speak at conferences about X and write articles for sites dedicated to Y. It's the truth, of course, but if your main goals are self-promotion and/or demonstrating how smart you are, it's not going to help you much.
I don't see why "they're effectively the same, but I chose X and have been using it for Z years now, and I'm widely considered an expert" would be any different from...I don't know, denying that they're the same.
If anything, denying it would be evidence of ignorance, no?
Sigh. I had just about decided on using Browserify in my current projects (instead of Require.JS), and now I have to find out there's ANOTHER option... (Though looking at one comparison [1], I guess I'm sticking with Browserify moving forward.)
It does feel like information like this is siloed: Everyone talks about their own favorite solution, and few actually make intelligent comparisons. I didn't know about gulp until after I'd already set up grunt, for instance, and I don't really want to tell the team "now we're using gulp" after having selected grunt only two months ago. I hadn't even heard of Broccoli until just now, either. I obviously need a better JavaScript news feed.
That said, I don't feel a need to slam gulp or say grunt is great. But something that the article misses is that the kind of loud, rude argument that it describes is a basic, well-known psychological reaction to insecurity: The less self-confidence you have, the more you feel the need to be loud about your opinions. And I think a lot of JavaScript developers are insecure, based on the evidence.
Then you get aggressive opinionation about the projects, but really that's a secondary phenomenon.
One problem is there are no objective metrics for framework or language quality. I don't think anyone knows if objective metrics are even possible, never mind how they would work.
So you pretty much just make a choice that works for you and stay with it until something obviously much better comes along.
And if it doesn't - if it's obviously much different, but not so obviously better - you can still be getting useful work done.
The seductive promise is that Framework X will make the job take half as long and produce half the bugs.
I doubt that's ever true in practice, for general values of X, especially when you consider learning/retooling time.
Actually, the main reason I was feeling like I might want to switch from Grunt to Gulp was the extreme and measurable time difference between running the two. Honestly the "it's easier to set up!" arguments fall somewhat flat; it's not HARD to set up Grunt, and you don't need to do it often, so that stinks of "premature optimization." Broccoli seems to entirely be about how clean and tiny the configuration files are; not interesting, because that means it's actually harder to understand how to change them to do something the designers didn't expect. If it's even possible.
It does feel like each group has their own little fiefdom and they want you to use THEIR tool rather than a competitor. The Grunt main page says "THE JAVASCRIPT TASK RUNNER", as if there are no other options. As a new JavaScript developer, it made me think that was just the only option.
I am much more impressed with the integrity of open source projects that actively advertise the options -- especially when they cite advantages and disadvantages of the options. Actively misdirecting you to believe that there no options is pretty much the opposite of that philosophy.
> [...] there is this sense that you have to say something to justify whatever choices you've made.
Whenever I somehow get time to work on a new "weekend project", I go through that every time. I know better and should stick to the rivers and lakes that I'm used to, but when working with (often) sub-par code in my day job, I always have the itch of trying new shiny things.
After I get that out of my system, I often keep my own "standard" stack and force myself to just say "No" to the new tools that are not fit for the project. At that point, I've probably wasted the entire weekend playing around with tutorials and fiddles to see that going through the learning curve isn't worth the time.
You've basically described 99% of the PHP development community there too. When there are so many ways to do something, it fosters the worst kinds of pedants, who don't seem to understand that "using exactly the same syntax/libs/style that I use" isn't the same thing as writing good code. I've seen people over on reddit's /r/shittprogramming make posts about how someone used a 2-space indent instead of a 4-space indent, and _that_ got upvotes.
You read plenty of comments about always "write tests first" or 100% test coverage, ignoring the fact that many businesses don't have the resources, and just want something quickly. Even if it is a bit buggy, the something that works for 98% of the cases today is better than something that works for 100% of cases in two months time.
I stared filling in an application form the other day:
do you prefer
A) I prefer "standard" solutions because they work and are easier to implement and maintain.
B) I prefer to create from scratch because it fits better the needs and offers better performance.
Without a context this question is entirely pointless to me.
And I will be judged on it? There people obviously have their ideals and I am going to be judged on them. There is no "it depends" in the answers.
Yikes, that's bizarre. I don't even think the conclusions they draw are even correct: there are many solutions I build from scratch because they're easier to maintain. e.g. this morning I needed to fetch data from 3 APIs: google analytics, twitter, and soundcloud. I could have downloaded the PHP lib they bundled for each of them separately, read their docs, and pulled my data from those. Instead, I just looked up their API docs, found the endpoints I needed and fetched what I needed with libcurl. I think it's easier to implement and maintain 3 simple calls to curl than it is 3 different libraries. Conversely, there are many 'standard' solutions that perform quite well, e.g. underscore.js has many methods, such as its .each(), which often outperform their builtin counterpart.
Questions like that are like being asked if you prefer:
A) A backhoe, because it gets the job done faster.
B) A shovel, because you have finer control
without being told what it is that you're actually digging.
> I've seen people over on reddit's /r/shittprogramming make posts about how someone used a 2-space indent instead of a 4-space indent, and _that_ got upvotes.
absolutely not surprising given that there is even a pretty popular language with indent base syntax out there.
I agree. FE technologies are in and out of fashion faster than anything else, it seems. Dig in and hate away and then maybe your knowledge will get a slightly longer ROI.
Certainly it's frustrating for any front-end developer who has invested his time in learning Grunt only to find out he should now be using Gulp, or Broccoli, or make(1)...