Regarding "embrace the suck," the best I can say while being brief is...
Ah man, this is such an interesting topic, and it's worthy of a blog post in its own right. You have to trust me when I say "there's something here; it's worth tugging at this thread to find out whether it might be true."
It is counterintuitive. But the fact that it's counterintuitive is a hint that it might be worth checking whether it might be true. Relativity was counterintuitive too.
If you embrace the suck, you can pull the simplicity out of the chaos. But only after you've mastered the chaos.
That sounds like some combination of naive or impractical. Who could possibly master chaos?
You can. And that's all I'm saying. Step one is to force yourself to choose to try.
I do think it's a great situation where one single programming language allows one to not only create complete applications that run on every computer under the sun (without installing Java), but allow you to fucking debug it in a pleasant way on pretty much each of those computers.
But all that said, I wish I hadn't started out with JS and blindly followed the 'chaos'. I've wasted so much time using React and Redux when simply React, or in some cases even good old Backbone of jQuery would have sufficed. I wish I'd learned good programming practices from more overtly functional or perhaps more overtly OO languages, before learning JS. I wish I hadn't spent many hours dealing with Grunt, no, Gulp, no Webpack, no Webpack 2, only to become a 'master' at something that is entirely irrelevant outside the JS ecosystem.
Sure, I learned the intricacies of the 'chaos' and I find myself going more and more for simpler solutions within the ecosystem. I'm comfortable using Baobab.js or MobX instead of Redux. I'm comfortable using only lodash instead of a whole bunch of modules that do part of what lodash does.
But I don't feel any of that made me better as a programming. In fact, as the JS ecosystem is improving, I find that a lot of my arcane knowledge of how to, say, enable hot code reloading in Webpack 1 is entirely useless now that Webpack 2 sort of does it out of the box.
More and more I'm inclined to let the JS ecosystem do its crazy shit and wait for something semi-standard to shake out before I even bother. Because everything I learn about the specifics of this chaos will not be worth knowing in <x> months.
You're right, in a particular way that I hadn't thought of:
Most people don't have a background in programming. They weren't doing it when they were teens, and many people probably started writing code within the last year or so.
In that context, I completely agree. It's absolutely true that at the end of all that chaos, you won't end up a better programmer.
I was speaking as someone who was in the inverse situation: I'd amassed a lot of theoretical knowledge, and spent a lot of time chasing the phantom of "being a good programmer." I researched memory models, read whitepapers, explored how Google implemented bigtable, went through rtm's 6.824 Distributed Systems course just for fun (it's freely available online)... You know, a bunch of hardcore stuff that it seems like "real programmers ought to know."
Yeah... Turns out that doesn't always translate into dollars. It came really close to being a bad situation (explained here https://news.ycombinator.com/item?id=15642428).
Let's put it this way. If I had to do it all over again, it's very possible I would swap skillsets with you. Because you know all of the stuff you rattled off. You are now prepared to avoid it. So yes, it's easy to feel like you've wasted your time. But when it comes to employability, you are far better positioned from a career standpoint.
Stuff like this may feel "out of bounds" of traditional conversation. Normally we're supposed to make up arguments that support our points purely through reason alone, right? Like it would be much more persuasive for me to say "Well, this matters because X" where X is something related to programming. Talking about career stuff and employability may seem like punting. It might also seem like it's something you don't really need to worry too much about.
But when you relax and let yourself stop learning, and stop going through the motions of all that stuff you hated, it's merely 3-5 years before you end up in a similar position. Maybe. Or maybe you'll get lucky.
But that doesn't make it less shit. I'm actively re-schooling myself as a more backend-ish, or perhaps full-stack-ish developer that allows me to use more of Elixir, Clojure, or even Ruby/Python, and less of JavaScript.
I'd say there are basically three perspectives on this:
1. development ease/quality, where JavaScript is not the worst, but far from the best. 2. ecosystem health and best practices, where I find that JS is not doing a great job. A lot of churn, a lot of reinventing the wheel, and a lot of stockholm syndrome defending the mess. 3. money, where being a good front-ender is worth most of the effort and frustration.
I'd say 3 is the most contentious. Most people seem to agree on 1 that JS and its ecosystem are not a paragon of good development. It takes work to even just get a good initial setup, which is not a problem in many other ecosystems. Transpiling, to name one example, is just not necessary. I think a sizable portion of multi-lingual devs would agree on 2 as well.
But 3 is difficult to quantify. Is it a good thing that I can me a good chunk of money building React/Redux apps when I could've built a saner, more stable version in Django/Rails/Elixir in a fraction of the time if the only downside is that it requires a full page reload? I'm not so sure anymore. But it's worth a discussion.
Point 1 and 2 strike me as obvious enough that bringing them up ad nauseum on HN is just pointless and frustrating.
I find myself often frustrated at criticism of JS that really is a criticism of the need to know the ins and outs of the ecosystem as a whole to be productive.
It's frustrating because blaming, well, anyone for that situation just seems a bit utopian and unrealistic. It implies that JS devs are not aware of the problems, when in my experience most non-fanatical ones are aware, but pragmatic.
I'm at least old enough to have been working within various ecosystems where arcane knowledge was pretty much a prerequisite to being productive in said ecosystem. One of the most common frustrations I had was people criticizing this need for arcane knowledge, where my thoughts were "sure, but that doesn't change the reality of day-to-day programming in ecosystem X, and the advantages of doing so perhaps maybe offset the shittiness".
I've experienced this with obscure Delphi-related issues concerning the app's 'chrome' (title/task bar coloring). I've experienced this doing PHP development and being told I'm a shitty dev for even touching PHP. I've experienced this with jQuery, being told that I should use Backbone (which FWIW was a good choice moving forward, but it never really solved my fundamental issues in my previous jQuery work. If anything functional approaches did).
There's a point where it just gets exhausting to hear people bring up the same tired old argument, again and again, for karma or whatnot, against a particular ecosystem, when the arguments are theoretically sound, but where they disregard the pragmatism of 'participating' in said ecosystem.
It's really not that different from a libertarian getting uppity about capitalism when you're busy volunteering for some non-profit civil society-related endeavor to improve things. It's not technically wrong, but it's a hell of a lot more pointless than pragmatically working within said system (and yet, confusingly, still worth pointing out).
And of course then there's a bunch of people who build something that vastly improves a possibly shitty ecosystem, using lessons they probably learned from other ecosystems. I'd say Redux as well as React are great examples of that. I'd love to go into how these are fundamentally very much about functional programming principles, and how I think all these tired discussions about languages hide the more important discussions, but that's unfortunately probably seen as tangential to this discussion.
Before I get into the details, as a general comment I find that while you're not wrong, I've found that I need much less 'diving into a pool' when I enter other language ecosystems. I understand why this is the case with JS, and personally I have a soft spot for the language, but even if it's not JS 'fault', I find that it is not a good thing that it takes such a 'deep dive'. They're valid concerns.
> - There is exactly one way to define a module. Write a file. Done. Webpack takes care of it.
it's a lot better now, but this has not been true even until recently. I've probably lost weeks of time over the years figuring out how to load module <x> using import statements where require() worked instantly, and from what I understand it can be a serious headache for module developers to support both 'ESNext' imports and CommonJS requires.
I can't tell how often I still need to search whether it is import x from 'x', import {x} from 'x', or import * as x from 'x', or in some cases the only thing that works is require(x).
> - The fact that Webpack either wasn't on your radar or already solving your problems says a lot.
Not really. I've used Webpack since the early days, and I've tried switching to Rollup, Brunch, and Gulp because Webpack just didn't make any sense to me. Then came Webpack 2 and half the tutorials and documentation stopped working.
FWIW I generally go for Webpack 2 these days, and it's an improvement. But it's a solution that causes quite a bunch of problems of its own. Plus, it's a solution that isn't even needed in anything but front-end JS. For good reasons, and I don't think JS is the cause of the problem (rather, it's bandwidth and general front-end concerns). Nonetheless, it's not even remotely simple.
> JS stdlib seems like nonsense? Lodash.
Why yes. I love lodash. But it's a huge library that I'd rather not load in its entirety if I'm not using most of it. Have you actually tried loading parts of lodash using import statements? Last I checked, a few months ago at most, this was not possible. I had to do require('lodash/blah'). That's not obvious until you've figured it out.
> Feels like you're importing too much bloat? Webpack tree shaking takes care of that. Closure compiler eliminates all the code you're not using. There's no reason not to use a first-class stdlib, whether it's Lodash or whatever else you prefer.
Webpack tree shaking is relatively new. Much of the online help (tutorials, etc.) still refers to Webpack 1.
> - The JavaScript community seems to have the opposite of NIH syndrome, so that even basic functionality is offloaded to a third-party modules (see leftpad). The project I'm working on has over 1000 modules in it's dependency tree.
> This is the power of JS. It's the thing to force yourself to embrace. You need to join the cult of bullshit and just mentally force yourself to love this rather than hate it.
I don't see how defending JS by telling someone to embrace the suck is any kind of valid argument in favor of the JS ecosystem. Could you elaborate?
> It's why JS won. You can hate it all you want and revel in the insanity, but there is zero reason to do that other than as a way of making yourself feel good. Which is just another way of saying we're all acting very selfish when we lash out at JS like this.
First of, JS won despite its quirks and the insane ecosystem. And second, selfish in relation to who? Brendan Eich? I think complaining about the things that do suck about JS and its ecosystem are important toward improving things. As a fan of JS, I don't feel offended when people say it sucks. It sucks, and while I think that's not primarily the language's fault, I also don't get my self-worth from being (predominantly) a JS programmer.
> Yes, you're correct. Every one of your points is absolutely true. Yet it's all so very wrong. I wish I could put it into words better than this.
Without meaning to be snarky, I'd love for you to elaborate. In the grand scheme of things I'm not a great programmer, and I got started with JS, so it's quite possible that I'm overestimating how much better the non-JS ecosystems are.
> Look dude. I've been around the block. [rant that I fully agree with]
> JS works now. That is not the expected behavior. It's difficult to convey how fucking strange this is. Anyone who lived through that 2006-era transition knows what I mean.
> But the way you know these things is by being a JS dev. Living and breathing it every day. There's no way around that. You either throw yourself wholeheartedly into the pool or keep one toe in while complaining about how big the ocean is.
> This rant came out quite a lot harsher than I intended; it's just a reaction to the very common trope that HN throws around of "JS is shit, the web is shit, this is shit." Yes, this is true. And yet -- simultaneously -- no. No no no. We can do magical things now. Hooking up Vue with hot reloading is literally magic. If 2007-era me had these tools, I would have launched a startup that could dominate everyone else solely due to the advanced tooling that we now enjoy. Our tooling now vs 2007 is like Lisp vs C++ back in 1999.
This I do agree with. I'm incredibly happy that front-end development has made massive steps in being saner than it used to be. And it does often frustrate me to read low-effort criticisms that don't really add to the conversation.
But in the past year I've ventured further and further out of my JS world, and I'm starting to understand why so many people are so negative about JS. If I were an experienced dev with little JS experience, the ecosystem would strike me as insane, to the point of just giving up and doing everything with 'server-side' languages. And honestly in the past few months I've been wondering if perhaps I've underestimated how much the JS ecosystem sucks. How much perhaps I've been Stockholm Syndrome'd into thinking this is normal in any way.
All that said, the constant criticism is grating. It doesn't solve anything, and it often carries a whiff of 'if only sane people were working in this area things would be different'. Which is utter bullshit. The JS ecosystem sucks, but it's the best we have, it's not because 'JS devs r dum', and in the end it often offers enough advantages to be worth the trouble. But that doesn't mean it isn't insane. It's batshit insane even now, but for the first time in years it's at least less frustratingly insane. We're moving in a good direction.
EDIT: let me add that I do agree that comparing JS to Ruby/Rails is not perhaps the best way to argue that JS isn't good. I'v encountered plenty of batshit in the Ruby ecosystem.