Hacker News Reader

Comment by dolni | Hacker News Reader

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.

View on HN

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.

Elixir and Erlang aren't async everything. Everything runs synchronously by default, you need to use separate primitives to turn it async

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.

Async != concurrent.

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

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.

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.

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.

> 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.

It is the other way around.

Electron embeds a web browser, which is a highly complex asynchronous application which is written in C++ by one of only a handful of super high tech companies. It is notorious that efforts to make web browsers with other runtimes (e.g. Hotjava) have failed.

The web browser is async from top to bottom so it never blocks when loading possibly hundreds of resources that make up a web page. JavaScript is asynchronous so it can be embedded in the web browser, if it wasn’t it could lock the whole thing up.

I looked at what the options were for cross-platform guis written by applications programmers and they were not pretty, had serious warts, and all went out for long lunch breaks.

Pretty sure that browsers loads resources in one dedicated thread just like complicated games do. It is a solid and simple technique to implement in C++, there are many good tools to handle that. That isn't the hard part of making a browser, the hard part is implementing all the different file formats/videos, rendering and scripting engine, security etc.

You’re talking about very simple games here. Open world games are constantly streaming huge amounts of data, much more so than a browser, at much tighter timing limitations.

What more complex games do (simplified) is put file IO on one thread, network IO on another, and use async (worker threads with jobs) for the rest.

Godot use "Servers"[0] to implement the game loop, which is async by design.

[0] - https://godotengine.org/article/why-does-godot-use-servers-a...

Isn't node.js then stand-alone server-side product?

What's the browser got to do with it?

Because that's the circular path that gets you the hated "async only" programming model.

For every node.js server there are probably 100 CLI programs that get run by the way.

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.

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

>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

[1] https://medium.com/softup-technologies/node-js-internals-lib...

[2] https://siliconangle.com/2013/04/01/the-birth-of-node-where-...

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.

> 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.

I never got why there is just one. The script tag can take any number of languages.

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

[1]https://eager.io/blog/a-brief-history-of-weird-scripting-lan...

[2]https://www.hanselman.com/blog/javascript-is-assembly-langua...

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.

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.

Thinking about it there are so many angles from which one could approach it.

It could not be required to run the script. For example require the visitor has his own website and have the script interact with specified tools installed there. Or a very limited language that disables js for security.

It could be a highly readable DSL, for example something to write interpreters in.

Or something narrow like interact with a rich text editor or data visualizations.

Perhaps a basic game engine.

It's also the most popular language for Lambda functions on AWS.

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.

That's a tarted-up container environment, irrelevant to node.js as such.

"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

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.

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.

Reply on news.ycombinator.com