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.
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.
It's analogous to how everybody jumped to document-based databases a few years ago and gradually developed an RDBMS-like schema system enforced only by coding conventions.
I see many new / intermediate people trying to do this. They want to make everything asynchronous when it does make sense to. You want asynchronous when you're accessing an external resources or for something low running (in which case yields / multiple asynchronous calls are necessary to free up the thread for GUI rendering if we're talking web browser here).
I do not like the new async / await syntax. Some days I think I'm alone in this but synchronous and asynchronous are two very different use cases and I think allowing both to be represented the same way can be highly confusing.
> The dependency tree of any one project tends to be incomprehensibly sprawling
This is entirely developers faults. NPM gives you A TON of rope to hang yourself with and every project I jump into people use libraries without considering to their dependencies and end up with a tree of over 3,000 dependencies. It's absolute madness!
> Runtime version numbering is... weird
Semantic versioning has been around for quite some time. I used it when I did Java and C# development; is it really that weird? Is there something about it that's weird?
> Don't even get me started on the interplay of Gulp, Grunt, Webpack and NPM.
NPM is kinda necessary for dependency resolution but beyond that gulp, grunt and webpack are all replaceable with simple scripts. It's actually one of the best and worst things about the JavaScript ecosystem: you can make your build work and behave in any way you want but you have to write the code or learn one of many build systems to do this. In other spaces, like Java, you typically just have ant and mavin and no one bothers with anything else.
I'm talking about the various schisms that have led to this page: https://nodejs.org/en/download/releases/
It's not a big deal once you familiarize yourself with what everything means, it's just a good example of some ecosystem baggage.
The ubiquity of using babel to get future language features also obscures the relevance of any one version of the runtime.
It has a single dependency management tool (pub), support for Angular 2, and is generally a joy to use.
Material widgets for Angular 2 (the same ones Google uses internally to build Adwords) are expected to be announced at the Dart summit in October.
The sweet thing about Dart is you don't need libraries like Angular or JQuery. I just use the built in Dart HTML methods and they compile down to vanilla JS.
While it is possible to write Dart code without using types (hence "optional") - the vast majority of Dart code is written using types.
The new Dart compiler also provides a "strong mode" which enforces strong typing in order to generate cleaner Javascript code.
I'm not a heavy AdWords user, so I can't say for certain that this represents all of the AdWords UI. But based on the linked interview, it sounds like they replaced a lot of GWT with Angular.
Source: http://news.dartlang.org/2016/03/the-new-adwords-ui-uses-dar...
I really wish gar1t would make some new videos, I love them.
(you're getting downvoted unfairly I think, probably a bit politically incorrect in this neighbourhood).
I'm pretty sure the video would violate the "code of conduct" at our local JS user group, though.
So it's a bit more of a "wild west" and it does represent wasted productivity if you look at it that way. You can also see it in a more positive light as a tradition of taking ownership of the tooling and continuously improving it. Because there's no central authority setting a course for the future, progress is through competition among solutions developed by the community.
I know this is the future and I'm trying to embrace it, but boy does it feel icky doing it.
http://stackoverflow.com/questions/33629343/what-is-the-best...