6 ms·

I apologize if the predictability of this comment, but I just want to say, I recently started a new gig at a company that has undergone a full on embrace of Jav

I apologize if the predictability of this comment, but I just want to say, I recently started a new gig at a company that has undergone a full on embrace of Javascript for tooling and server side projects and it boggles my mind how much productivity is wasted on this ecosystem. There is an interesting amount of energy put into making asynchronous code read synchronously in situations where asynchronous code provides no benefit. The dependency tree of any one project tends to be incomprehensibly sprawling. Runtime version numbering is... weird. Don't even get me started on the interplay of Gulp, Grunt, Webpack and NPM. ES6 is bizarrely noisy. ESLint fascism is a necessity given the history of legal anti-patterns the language must shoulder. Scoping can occasionally lead to absurdist solutions [1]. 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-way-in-es6-to-assign-a-constant-conditionally http://stackoverflow.com/questions/33629343/what-is-the-best...

Klathmon 10y ago
Could it be that you are still just new to it (in the grand scheme of things)? 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.
- SadWebDeveloper 10y ago
  I actually thing is the other way around... App Development is solved (unless you want to run the same codebase on multiple OS) but Web Development is a mess now that JS devs are trying hard to put themselves in every layer of the app from the networking layer to the data layer, throwing out the window years of good practices.
- anamoulous 10y ago
  I'm not going from backend to frontend or desktop apps. I'm going backend to backend. 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.
  - deleted 10y ago
    [deleted]
- matthewmacleod 10y ago
  See, I'm not sure that's the case. 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.
  - mhink 10y ago
    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.
- wvenable 10y ago
  > Application development is hard, and is still far from "solved". 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.
to3m 10y ago
Yes, it's awful - and you're making a huge mistake by actually doing it yourself. There are plenty of people that love this stuff, as unfathomable as that is. Why not let them do it?
mrspeaker 10y ago
Just wondering about that stackoverflow question... I don't understand what that has to do with scoping - what is the nice way this would be done in other languages?
davidw 10y ago
If you haven't seen it, you might find this entertaining: https://www.youtube.com/watch?v=bzkRVzciAZg https://www.youtube.com/watch?v=bzkRVzciAZg I really wish gar1t would make some new videos, I love them.
- TickleSteve 10y ago
  Excellent! someone in this world has their head screwed on right! (you're getting downvoted unfairly I think, probably a bit politically incorrect in this neighbourhood).
  - davidw 10y ago
    I don't care about downvotes, I thought that video was hilarious and enjoy sharing it. He's the same guy behind "MongoDB is web scale" and "Erlang the Movie II", which I'd also highly recommend: http://www.mongodb-is-web-scale.com/ http://www.mongodb-is-web-scale.com/ https://www.youtube.com/watch?v=rRbY3TMUcgQ https://www.youtube.com/watch?v=rRbY3TMUcgQ
    - Roboprog 10y ago
      Love me some Erlang, er, "OTP". I'm pretty sure the video would violate the "code of conduct" at our local JS user group, though.
hackerboos 10y ago
There are those of us that have known this to be true for a while and are moving (or trying to convince our employers to move) to alternative languages that compile to JS. Clojurescript, Elm etc.
bandrami 10y ago
> making asynchronous code read synchronously in situations where asynchronous code provides no benefit 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.
Jizzle 10y ago
I see a lot of beauty in the js ecosystem, but only insomuch as related technologies come together to produce platform-independent, user-facing components. Similarly, I find C# or Java and their related technologies to be more beautiful on the server. Of course, one downside to this opinion is the requirement for skill in multiple ecosystems--and perhaps your employer had sought to consolidate these skills with js across the board.
BinaryIdiot 10y ago
> There is an interesting amount of energy put into making asynchronous code read synchronously in situations where asynchronous code provides no benefit. 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.
- sotojuan 10y ago
  The problem with frontend is that making code synchronous blocks the client—even if it's something that "should be" synchronous. If it's anything more complex than a loop or a map through an array, it's recommended you make it async.
  - BinaryIdiot 10y ago
    Making something asynchronous doesn't do anything magical to unblock the client; a long running asynchronous call that's not accessing an external resource will block the client just as much with the only differencing being the scheduler gets freed up just before running the asynchronous code. If you have something long running you need to use a generator yield pattern (process in pieces with ES5). I addressed this in my initial comment.
wstrange 10y ago
Give Dart a try. 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.
- nekitamo 10y ago
  Correct me if I'm wrong, but I thought that the majority of the Adwords frontend is still written in GWT?
  - rpeden 10y ago
    It appears that the new version of the new AdWords UI is created using Dart and Angular 2: http://news.dartlang.org/2016/03/the-new-adwords-ui-uses-dart-we-asked.html http://news.dartlang.org/2016/03/the-new-adwords-ui-uses-dar... 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.
  - wstrange 10y ago
    The new Adwords is built with Dart. Source: http://news.dartlang.org/2016/03/the-new-adwords-ui-uses-dart-we-asked.html http://news.dartlang.org/2016/03/the-new-adwords-ui-uses-dar...
- devsquid 10y ago
  Gotta say its pretty awesome! I can do a whole fully functional web app in about a 80kbs JS library(including embedded HTML for fast loading of different views). 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.
- EugeneOZ 10y ago
  JSON support is awful, "optional types" means "no types". Thanks, but even TS is better.
inimino 10y ago
The Web has been a very popular development platform for a long time, but that time has been characterized by intense competition between browsers. It's a bit different from most platforms which are clearly dominated and guided by a single player. 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.

Klathmon 10y ago

Could it be that you are still just new to it (in the grand scheme of things)? 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.

SadWebDeveloper 10y ago
I actually thing is the other way around... App Development is solved (unless you want to run the same codebase on multiple OS) but Web Development is a mess now that JS devs are trying hard to put themselves in every layer of the app from the networking layer to the data layer, throwing out the window years of good practices.
anamoulous 10y ago
I'm not going from backend to frontend or desktop apps. I'm going backend to backend. 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.
- deleted 10y ago
  [deleted]
matthewmacleod 10y ago
See, I'm not sure that's the case. 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.
- mhink 10y ago
  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.
wvenable 10y ago
> Application development is hard, and is still far from "solved". 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.

to3m 10y ago

Yes, it's awful - and you're making a huge mistake by actually doing it yourself. There are plenty of people that love this stuff, as unfathomable as that is. Why not let them do it?

mrspeaker 10y ago

Just wondering about that stackoverflow question... I don't understand what that has to do with scoping - what is the nice way this would be done in other languages?

davidw 10y ago

If you haven't seen it, you might find this entertaining: https://www.youtube.com/watch?v=bzkRVzciAZg https://www.youtube.com/watch?v=bzkRVzciAZg I really wish gar1t would make some new videos, I love them.

TickleSteve 10y ago
Excellent! someone in this world has their head screwed on right! (you're getting downvoted unfairly I think, probably a bit politically incorrect in this neighbourhood).
- davidw 10y ago
  I don't care about downvotes, I thought that video was hilarious and enjoy sharing it. He's the same guy behind "MongoDB is web scale" and "Erlang the Movie II", which I'd also highly recommend: http://www.mongodb-is-web-scale.com/ http://www.mongodb-is-web-scale.com/ https://www.youtube.com/watch?v=rRbY3TMUcgQ https://www.youtube.com/watch?v=rRbY3TMUcgQ
  - Roboprog 10y ago
    Love me some Erlang, er, "OTP". I'm pretty sure the video would violate the "code of conduct" at our local JS user group, though.

hackerboos 10y ago

There are those of us that have known this to be true for a while and are moving (or trying to convince our employers to move) to alternative languages that compile to JS. Clojurescript, Elm etc.

bandrami 10y ago

> making asynchronous code read synchronously in situations where asynchronous code provides no benefit 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.

Jizzle 10y ago

I see a lot of beauty in the js ecosystem, but only insomuch as related technologies come together to produce platform-independent, user-facing components. Similarly, I find C# or Java and their related technologies to be more beautiful on the server. Of course, one downside to this opinion is the requirement for skill in multiple ecosystems--and perhaps your employer had sought to consolidate these skills with js across the board.

BinaryIdiot 10y ago

> There is an interesting amount of energy put into making asynchronous code read synchronously in situations where asynchronous code provides no benefit. 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.

sotojuan 10y ago
The problem with frontend is that making code synchronous blocks the client—even if it's something that "should be" synchronous. If it's anything more complex than a loop or a map through an array, it's recommended you make it async.
- BinaryIdiot 10y ago
  Making something asynchronous doesn't do anything magical to unblock the client; a long running asynchronous call that's not accessing an external resource will block the client just as much with the only differencing being the scheduler gets freed up just before running the asynchronous code. If you have something long running you need to use a generator yield pattern (process in pieces with ES5). I addressed this in my initial comment.

wstrange 10y ago

Give Dart a try. 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.

nekitamo 10y ago
Correct me if I'm wrong, but I thought that the majority of the Adwords frontend is still written in GWT?
- rpeden 10y ago
  It appears that the new version of the new AdWords UI is created using Dart and Angular 2: http://news.dartlang.org/2016/03/the-new-adwords-ui-uses-dart-we-asked.html http://news.dartlang.org/2016/03/the-new-adwords-ui-uses-dar... 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.
- wstrange 10y ago
  The new Adwords is built with Dart. Source: http://news.dartlang.org/2016/03/the-new-adwords-ui-uses-dart-we-asked.html http://news.dartlang.org/2016/03/the-new-adwords-ui-uses-dar...
devsquid 10y ago
Gotta say its pretty awesome! I can do a whole fully functional web app in about a 80kbs JS library(including embedded HTML for fast loading of different views). 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.
EugeneOZ 10y ago
JSON support is awful, "optional types" means "no types". Thanks, but even TS is better.

inimino 10y ago

The Web has been a very popular development platform for a long time, but that time has been characterized by intense competition between browsers. It's a bit different from most platforms which are clearly dominated and guided by a single player. 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.