6 ms·

JavaScript is a language whose flaws are well understood by experienced developers, and those flaws are massive. I also don't particularly care for "async ever

by dolni 5y ago

JavaScript is a language whose flaws are well understood by experienced developers, and those flaws are massive. I also don't particularly care for "async everything" by default. It makes your program more difficult to reason about. Rather than dealing with concurrency in a subset of your application, you now have to worry about it _everywhere_. There are only a few classes of software where the async-everything approach even makes sense. Throw in the fact that the ecosystem is an absolute dumpster fire and you have more than enough justification.

dtagames 5y ago
An excellent answer. Although JS has problems, it did already win so Node.js is useful in that sense. But async everything is nutso and requires lots of gating and checking mechanisms in order to get back to synchronous, imperative behavior which is what you normally want in a scripting language. The setup/versioning and dependency hell issues of Node are absolutely bonkers. I work on a monrepo of 400,000 lines of code at work and I think most of the Node stuff is "just guessing" when people run it. Secret incantations that don't make any sense and have to be copy/pasted. All of Node is like this.
- Jensson 5y ago
  > Although JS has problems, it did already win In what way did it "win"? People use JS because it is in the browser, do you have any data that JS won anywhere except the browser? Pretty sure it isn't even the most popular solution for web backends.
  - j4hdufd8 5y ago
    >Pretty sure it isn't even the most popular solution for web backends. Huh?
  - 6510 5y ago
    I never got why there is just one. The script tag can take any number of languages.
    - krapp 5y ago
      While support for multiple languages was the plan all along (the spec for the script tag mentions "text/tcl" along with javascript and vbscript)[0,1], browser makers never bothered to support other languages when javascript became the popular choice, apart from Microsoft with VBScript and Chrome with Dart, whose languages were vendor specific. Eventually, people just compiled code written in other languages into Javascript, treating it more as an "assembly language for the web"[2] than a language directly coded in, and the script type attribute was officially deprecated from the script tag in HTML5. [0]https://www.w3.org/TR/REC-html40/interact/scripts.html https://www.w3.org/TR/REC-html40/interact/scripts.html [1]https://eager.io/blog/a-brief-history-of-weird-scripting-languages/ https://eager.io/blog/a-brief-history-of-weird-scripting-lan... [2]https://www.hanselman.com/blog/javascript-is-assembly-language-for-the-web-sematic-markup-is-dead-clean-vs-machinecoded-html https://www.hanselman.com/blog/javascript-is-assembly-langua...
      - 6510 5y ago
        What properties would a new language make an interesting alternative? What common problem suffers the most solved in js? Preferably something without hope for improvement.
        krapp 5y ago
        Given how practically all Javascript nowadays is generated by Typescript or other compile-to-js languages, probably a stricter type system, actual integers and doubles (JS only uses floats,) maybe as often mentioned, a bigger standard library. There probably isn't much benefit to different languages if you're just manipulating the DOM (which is probably why that model failed, having more than one language doing the exact same thing is needless extra complexity) but using the browser as an application runtime opens up the possibility of making any software written in a supported language accessible and executable from a URL. The "JS as bytecode" model got us surprisingly far, but it was a disgusting hack, and Java applets and Flash had their day in the sun, but Webassembly is probably what's going to make the "multiple scripts in the browser" model eventually feasible.
  - oweiler 5y ago
    It's also the most popular language for Lambda functions on AWS.
    - Jensson 5y ago
      Lambda functions are just a back end framework tightly coupled to a cloud service, they go in the web backend bin and aren't their own thing. Javascript might be the most popular there but I doubt lambda functions makes a significant dent in the overall web backend landscape.
    - smitty1e 5y ago
      That's a tarted-up container environment, irrelevant to node.js as such.
Footkerchief 5y ago
The ecosystem's problems are also amplified by the patchiness of Node's stdlib -- often that ecosystem is all you've got.
jasode 5y ago
>I also don't particularly care for "async everything" by default. I understand your complaint. Just to add some historical background, Node.js creator Ryan Dahl deliberately architected it that way. He thought threads to express concurrency had flaws. (Especially for i/o tasks instead of cpu-bound tasks). An excerpt[2]: >“Node was originally born out of this problem — how can you handle two things at the same time? Non-blocking sockets is one way. Node is more or less the idea, or exploring the idea: what if everything was non-blocking? What if you never waited for any IO to happen?” It's interesting that around the same time, a JVM-based competitor called Vert.x adopted the same philosophy. An example discussion on HN where some favor async by default: https://news.ycombinator.com/item?id=3928738 https://news.ycombinator.com/item?id=3928738 [1] https://medium.com/softup-technologies/node-js-internals-libuv-and-the-event-loop-behind-the-curtain-30708c5ca83 https://medium.com/softup-technologies/node-js-internals-lib... [2] https://siliconangle.com/2013/04/01/the-birth-of-node-where-did-it-come-from-creator-ryan-dahl-shares-the-history/ https://siliconangle.com/2013/04/01/the-birth-of-node-where-...
throwaway743 5y ago
Couldn't agree more on async everything. Been building out a market charting and tracking application and boy oh boy has it been the biggest pain in the ass having a good amount of UI rendering be dependent on async calls. Wish the UI components would just render regardless of whether or not an async call was finished, rather than have to write conditionals for the components to display based on returned promises, populated states/context... I've grown to really hate react these last few months
- PaulHoule 5y ago
  If it wasn’t for async everything your web browser would be locked up and unresponsive half the time. It’s one reason why Electron rules the roost…. Look at how often conventions GUI apps go out to lunch.
  - Jensson 5y ago
    You know you can do concurrency without async calls? Async isn't a good solution for loading data in a data heavy application, game engines doesn't do it that way and they are the most data heavy applications you can find.
    - PaulHoule 5y ago
      Game engines are not as dependent on the network as web browsers. Usually they do all the disk I/O up front, are designed to drop events if the network goes bad, drop frames instead of hang if deadlines are missed. It’s like your compiler just skips an import if it the disk is slow.
      - Jensson 5y ago
        > Game engines are not as dependent on the network as web browsers You do know that web browsers aren't implemented in Electron either and that they don't use javascript to load the resources of a web page concurrently? You were talking about why Electron/Javascript/Node.js rules all. I'm not aware of any web browser implemented in those technologies. I know Electron is based on chromium, meaning they used a browser to implement it, but I am talking about the other way around ie implementing a browser in Electron.
true_religion 5y ago
Well look at Erlang/Elixir. Async everything is fine if your language is immutable and has preemptable execution. You just write code, and the system figures out how to break things up. But that’s a system that was designed from the ground up to be async. In JavaScript it was added after the fact, and you as a programmer have to deliberately annotate your functions to be aware of what is and isn’t async.
- thdxr 5y ago
  Elixir and Erlang aren't async everything. Everything runs synchronously by default, you need to use separate primitives to turn it async
  - true_religion 5y ago
    By the way you approach it, JavaScript isn’t async everything because you need to deliberately define a promise or async function… However the OP and I, are talking about async everything as a programming methodology and not as a fundamental part of the base system.
- cutler 5y ago
  Async != concurrent.
vesuvianvenus 5y ago
"async/await" makes it very easy to reason about async stuff-- async stuff can be done in series, or it can branch off into a pyramid structure of tasks, etc. I think its awesome :D
ecf 5y ago
I had the unfortunate displeasure of selecting Node for a take home interview. My simple express API was working fine when testing with Insomnia but the test suite was a convoluted pile of crap built from different npm frameworks and plugins. At the end of the time slot I had three failing tests for reasons I couldn’t figure out and and my submission was probably automatically rejected. Oh well, I learned I never want to touch Node again.
- midrus 5y ago
  Probably you would have had this problem with any other platform you were not familiar with. Tests can be written properly and in a very reliable way in any platform, and a mess can be made in any platform too.
tored 5y ago
I have a conspiracy, because nodejs is single threaded asynchronous event loop, hence it is easy to temporarily freeze the entire application by mistakenly introduce a tick anywhere in your application that is just too long what it should be, thus the closer you get to a large monolith the more likely it is that your application has reoccurring freezes. My conspiracy theory is that this phenomenon partly created the need of microservices within the web community and by that creating entire new set of problems that needed to be solved.

by dolni 5y ago

dtagames 5y ago

An excellent answer. Although JS has problems, it did already win so Node.js is useful in that sense. But async everything is nutso and requires lots of gating and checking mechanisms in order to get back to synchronous, imperative behavior which is what you normally want in a scripting language. The setup/versioning and dependency hell issues of Node are absolutely bonkers. I work on a monrepo of 400,000 lines of code at work and I think most of the Node stuff is "just guessing" when people run it. Secret incantations that don't make any sense and have to be copy/pasted. All of Node is like this.

Jensson 5y ago
> Although JS has problems, it did already win In what way did it "win"? People use JS because it is in the browser, do you have any data that JS won anywhere except the browser? Pretty sure it isn't even the most popular solution for web backends.
- j4hdufd8 5y ago
  >Pretty sure it isn't even the most popular solution for web backends. Huh?
- 6510 5y ago
  I never got why there is just one. The script tag can take any number of languages.
  - krapp 5y ago
    While support for multiple languages was the plan all along (the spec for the script tag mentions "text/tcl" along with javascript and vbscript)[0,1], browser makers never bothered to support other languages when javascript became the popular choice, apart from Microsoft with VBScript and Chrome with Dart, whose languages were vendor specific. Eventually, people just compiled code written in other languages into Javascript, treating it more as an "assembly language for the web"[2] than a language directly coded in, and the script type attribute was officially deprecated from the script tag in HTML5. [0]https://www.w3.org/TR/REC-html40/interact/scripts.html https://www.w3.org/TR/REC-html40/interact/scripts.html [1]https://eager.io/blog/a-brief-history-of-weird-scripting-languages/ https://eager.io/blog/a-brief-history-of-weird-scripting-lan... [2]https://www.hanselman.com/blog/javascript-is-assembly-language-for-the-web-sematic-markup-is-dead-clean-vs-machinecoded-html https://www.hanselman.com/blog/javascript-is-assembly-langua...
    - 6510 5y ago
      What properties would a new language make an interesting alternative? What common problem suffers the most solved in js? Preferably something without hope for improvement.
      - krapp 5y ago
        Given how practically all Javascript nowadays is generated by Typescript or other compile-to-js languages, probably a stricter type system, actual integers and doubles (JS only uses floats,) maybe as often mentioned, a bigger standard library. There probably isn't much benefit to different languages if you're just manipulating the DOM (which is probably why that model failed, having more than one language doing the exact same thing is needless extra complexity) but using the browser as an application runtime opens up the possibility of making any software written in a supported language accessible and executable from a URL. The "JS as bytecode" model got us surprisingly far, but it was a disgusting hack, and Java applets and Flash had their day in the sun, but Webassembly is probably what's going to make the "multiple scripts in the browser" model eventually feasible.
- oweiler 5y ago
  It's also the most popular language for Lambda functions on AWS.
  - Jensson 5y ago
    Lambda functions are just a back end framework tightly coupled to a cloud service, they go in the web backend bin and aren't their own thing. Javascript might be the most popular there but I doubt lambda functions makes a significant dent in the overall web backend landscape.
  - smitty1e 5y ago
    That's a tarted-up container environment, irrelevant to node.js as such.

Footkerchief 5y ago

The ecosystem's problems are also amplified by the patchiness of Node's stdlib -- often that ecosystem is all you've got.

jasode 5y ago

>I also don't particularly care for "async everything" by default. I understand your complaint. Just to add some historical background, Node.js creator Ryan Dahl deliberately architected it that way. He thought threads to express concurrency had flaws. (Especially for i/o tasks instead of cpu-bound tasks). An excerpt[2]: >“Node was originally born out of this problem — how can you handle two things at the same time? Non-blocking sockets is one way. Node is more or less the idea, or exploring the idea: what if everything was non-blocking? What if you never waited for any IO to happen?” It's interesting that around the same time, a JVM-based competitor called Vert.x adopted the same philosophy. An example discussion on HN where some favor async by default: https://news.ycombinator.com/item?id=3928738 https://news.ycombinator.com/item?id=3928738 [1] https://medium.com/softup-technologies/node-js-internals-libuv-and-the-event-loop-behind-the-curtain-30708c5ca83 https://medium.com/softup-technologies/node-js-internals-lib... [2] https://siliconangle.com/2013/04/01/the-birth-of-node-where-did-it-come-from-creator-ryan-dahl-shares-the-history/ https://siliconangle.com/2013/04/01/the-birth-of-node-where-...

throwaway743 5y ago

Couldn't agree more on async everything. Been building out a market charting and tracking application and boy oh boy has it been the biggest pain in the ass having a good amount of UI rendering be dependent on async calls. Wish the UI components would just render regardless of whether or not an async call was finished, rather than have to write conditionals for the components to display based on returned promises, populated states/context... I've grown to really hate react these last few months

PaulHoule 5y ago
If it wasn’t for async everything your web browser would be locked up and unresponsive half the time. It’s one reason why Electron rules the roost…. Look at how often conventions GUI apps go out to lunch.
- Jensson 5y ago
  You know you can do concurrency without async calls? Async isn't a good solution for loading data in a data heavy application, game engines doesn't do it that way and they are the most data heavy applications you can find.
  - PaulHoule 5y ago
    Game engines are not as dependent on the network as web browsers. Usually they do all the disk I/O up front, are designed to drop events if the network goes bad, drop frames instead of hang if deadlines are missed. It’s like your compiler just skips an import if it the disk is slow.
    - Jensson 5y ago
      > Game engines are not as dependent on the network as web browsers You do know that web browsers aren't implemented in Electron either and that they don't use javascript to load the resources of a web page concurrently? You were talking about why Electron/Javascript/Node.js rules all. I'm not aware of any web browser implemented in those technologies. I know Electron is based on chromium, meaning they used a browser to implement it, but I am talking about the other way around ie implementing a browser in Electron.

true_religion 5y ago

Well look at Erlang/Elixir. Async everything is fine if your language is immutable and has preemptable execution. You just write code, and the system figures out how to break things up. But that’s a system that was designed from the ground up to be async. In JavaScript it was added after the fact, and you as a programmer have to deliberately annotate your functions to be aware of what is and isn’t async.

thdxr 5y ago
Elixir and Erlang aren't async everything. Everything runs synchronously by default, you need to use separate primitives to turn it async
- true_religion 5y ago
  By the way you approach it, JavaScript isn’t async everything because you need to deliberately define a promise or async function… However the OP and I, are talking about async everything as a programming methodology and not as a fundamental part of the base system.
cutler 5y ago
Async != concurrent.

vesuvianvenus 5y ago

"async/await" makes it very easy to reason about async stuff-- async stuff can be done in series, or it can branch off into a pyramid structure of tasks, etc. I think its awesome :D

ecf 5y ago

I had the unfortunate displeasure of selecting Node for a take home interview. My simple express API was working fine when testing with Insomnia but the test suite was a convoluted pile of crap built from different npm frameworks and plugins. At the end of the time slot I had three failing tests for reasons I couldn’t figure out and and my submission was probably automatically rejected. Oh well, I learned I never want to touch Node again.

midrus 5y ago
Probably you would have had this problem with any other platform you were not familiar with. Tests can be written properly and in a very reliable way in any platform, and a mess can be made in any platform too.

tored 5y ago

I have a conspiracy, because nodejs is single threaded asynchronous event loop, hence it is easy to temporarily freeze the entire application by mistakenly introduce a tick anywhere in your application that is just too long what it should be, thus the closer you get to a large monolith the more likely it is that your application has reoccurring freezes. My conspiracy theory is that this phenomenon partly created the need of microservices within the web community and by that creating entire new set of problems that needed to be solved.