When I started writing apps using Cocoa, for example, I had a pretty good experience. Yeah, I fought some of the tooling that I wasn't really used to, but given that it was quite different from my backgrounds in web and embedded development, 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).
This contrasts very much with the Javascript ecosystem. Despite having been a nominal web developer for approaching a decade, I am still consistently baffled by how difficult it is to get to grips with how everything is put together. There seem to be dozens of different workflows, none of which are entirely compatible with one another. There are bad configuration formats all over. Every tool seems to be broken into 200 different parts that subsequently have to be reassembled in order to implement a working pipeline. Documentation is erratic at best, and so on.
I used to feel pretty productive with Javascript, back when the web was a bit more 'Wild West'. 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.
My usual stack looks something like: Express / React / Redux / Webpack / Enzyme / CSS Modules
I do SSR / Universal JS whenever possible and it works great. The only problem on my stack nowadays is the CSS. Still haven't figured out a good flow. I currently use CSS Modules, but without dead code elimination, it just doesn't do exactly what I would like to (feed in the whole CSS library I use and let it pick and choose the classes that are used in my components, throwing the rest away)
Getting up to speed on all these tools hasn't been easy, but at this point, most of my projects are a breeze. No worrying about browser JS support. No worrying about CSS support. No more choosing between server side and client side rendering. Linting that works great and keeps the projects looking clean. Testing that doesn't make me wanna blow my brains out. Combining and minifying projects is a piece of cake. HMR + Autorefresh is like magic.
I'm really enjoying working on the web now.
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.
I guess part of my point is I'm made uncomfortable by the encroachment of Javascript into areas where it's not particularly well suited, and the historical baggage it must carry into those areas. It's the when you have Javascript as a hammer, everything looks like a nail issue. I don't think my organization is unique in its embrace of Javascript-everything, either.
I'm surprised you feel that way; I always find it nice to do plain 'ol desktop development because it does feel solved. Everything is clean, quick, and heavily documented. Much of the languages, frameworks, and libraries have been around for decades.
Because all of those things sound very similar to the complaints I hear from web developers on their first foray into desktop development.
There are so many tools it's impossible to know them all (or to even know which one is best to use in which situation), so much legacy code out there it's tough to learn what the "right" way to do things is, it often feels like you are fighting the OS or the language to get what you want how you want it, and dependencies are hard.
Application development is hard, and is still far from "solved". And while the "web stack" is far from perfect, I'm personally significantly more productive in it than I ever was in anything else. And in my experience that extra productivity makes better applications because I spend less time just trying to get it working, and more time getting it working well.