The State of JavaScript – Survey results

Interesting. I didn't know that.

If anything, that actually somewhat affirms my preference for Apollo. Since Apollo is built on top of Redux, you can use both in tandem without any problem instead of having to learn a whole new tool and refactor your application to use it.

> somehow JS devs have decided switch statements are bad

Nonsense. Though sometimes using an object can look cleaner depending on your use case.

> indenting with 2 spaces is the only way to go

I love 4 spaces and I use 4 in my JavaScript projects. Just because you've seen some subset of people use 2 doesn't mean it's the majority, what you have to use, etc.

> semi-colons should be banished

Absolutely, positively NO. Semi-colons are a requirement of the language. Some people elide them, incorrectly, because the JavaScript engines are good enough to still handle it. In my experience being playing a limited part in open source JavaScript eliding the semi colon seems to be a rarely done practice.

Regardless it's incorrect no matter how you slice it.

> "boilerplate" code should be hidden in libraries the magically wipe it away so your code looks "clean,"

This sounds more like a rails-ism than a JavaScript-ism. Though you'd be hard pressed to find libraries without implicit behaviors in every language. Some people take DRY way too far.

This point just seems more anecdotal than anything else.

> a make file. Who has time to wade through umpteen million build systems?

A lot of JavaScript devs use make. Nothing wrong with that.

I switched from browserify to webpack when I started writing ES6 on the client because the browserify build times with ES6 were slow enough that they felt disruptive to my workflow (somewhere between 10-30 seconds, I don't remember the exact amount). I'm not sure if that's improved now for Browserify, but it's the kind of thing that you're not likely to switch back from once you have a working setup.

IMO, the problem is looking at Javascript as a single unified thing. One thing I came away with from this survey is that there are two major competing "stacks" at the moment- the Typescript/Angular stack and the Webpack/Babel/React stack.

Personally, I've been focusing the majority of my "professional research time" in keeping up with the latter stack, and it's ended up paying off in the sense that it's almost trivial to spin up a new project at this point.

> Every tool seems to be broken into 200 different parts that subsequently have to be reassembled in order to implement a working pipeline.

I agree that this can be frustrating. Setting up a new Webpack/Babel/React project does tend to involve installing a bunch of different plugins, presets, and loaders. The way I learned this stuff it was by focusing on one thing at a time: set Webpack up to bundle my Javascript modules. Okay, cool, I fully understand that thing. Okay, now let's add Babel, with the ES6 preset. Alright, rad- now what about CSS?

> But as it has developed as an application platform, it feels more and more like I am fighting the tools, rather than having them help me. That's not a nice feeling.

I absolutely promise that I'm being earnest, NOT snarky, when I say that it sounds like you need to learn the tools more thoroughly. Personally, I tend to forget how much of a pain it was to learn other ecosystems, and so I sometimes get frustrated because it feels like learning a new ecosystem should be easy. And, yes, other ecosystems definitely have an easier learning curve. That said, I'm right there with you when it comes to testing frameworks. Oh god, testing frameworks. -_-;

A major part of the problem, I think, is that the current Javascript ecosystems spend a lot of time optimizing their tutorials and documentation for newbies and junior developers. I'll admit that I think it's a categorically Good Thing to have that, but many's the time I've wished for intermediate-level docs. The absolute best examples of this, in my opinion, are the Rails guides, the Rails API documentation, and the Elixir documentation (all of it).

> I was overall quite pleased with how easy and more importantly how obvious everything was. I found this to be the same when I wrote applications in Qt, and also when starting to work with newer languages (like Go).

Can you go into a little more detail on this? I'm genuinely interested in the details of what these languages got right.

>Overall, developers are not happy about JavaScript testing.

This is because of the low percentage of devs in the survey who have used Jest. I can't begin to describe the joy of finally finding a JS test utility that just works and doesn't require a giant configuration file.

If you aren't using Jest, make the switch now! It's likely a lot of your existing tests will work with Jest.