Hacker News Reader

Comment by aikah | Hacker News Reader

> That isn't an argument against leveraging web technology so much as an argument in favour of well written applications

The difference is there is very little room for optimisation in most javascript runtimes. They don't support multi-threading and the memory is impossible to manage. "Lower" level languages always allow better performance tweaking when necessary. Javascript allows next to none. You can't tell javascript :"Give me an array of 10 elements", or "give me a integer of that length". So no "headroom" for performances with Javascript.

View on HN

> They don't support multi-threading

Yes, they do, via Web Workers. They just don't support multithreading at the level of concurrent access to the DOM, and they don't support shared memory. Very few native libraries support concurrent access to UI widgets, and not many native applications make heavy use of shared memory for compute either. (Most native applications don't have heavy compute needs in the first place…)

> Give me an array of 10 elements

new Array(10)?

> give me a integer of that length

Uint8Array, Uint16Array, Uint32Array?

Please :

> Yes, they do, via Web Workers.

Which are not part of the javascript spec, it is DOM related. And web workers were never meant to increase performance. In fact in practice they don't, they often make code slower. They just guarantee that the UI thread will not block.

> new Array(10)?

Which doesn't allow any specific runtime optimization as the array can be resized at anytime

> Uint8Array, Uint16Array, Uint32Array?

Which doesn't give me an integer of a specific size BUT any array of integer.

Most performance problems with websites/webapps out there are just due to sheer nastiness of the shovelware that they embed. No need to have fine-tuned debugging and profiling when the main fix is "don't accidentally run this jQuery selector 1000 times on every click". Very low hanging fruit.

> the memory is impossible to manage.

Nonsense. There are plenty of strategies for managing memory efficiently in JavaScript. Yes you can't do a C++ level of allocation, decallocation, etc but you most certainly can manage the amount of memory your code uses.

This is a non-argument. Firstly, JS does indeed have typed arrays and other tools for managing memory. More importantly, unless you're doing 3D or similar it's vanishingly rare that the memory used by objects you've allocated in JS will be measurable compared to the memory used for DOM objects and rendering generally. Replacing JS with some other language wouldn't affect the memory usage of typical web pages.

I think the spirit of the argument is that if you have requirements for heavy computation such that you need multithreading + low level memory management, then you probably shouldn't use this. Use the right tool for the job. This is just one of them.

Plus there are alternatives to threads. Look at the state of Atom or VSCode. Much progress has been made in terms of perf and these are not trivial applications.

> Use the right tool for the job

That's a funny argument in a thread about js. Js has started as a small language to do scripting on the pages, now they are sticking it everywhere.

Because people don't actually use the right tool for the job when it comes to software. Instead, they take the tool they know, ignore the better tools they would rather not have to learn, and make the known tool do things it was never designed for.

Excel is a great example of that, but it's done with programming languages as well.

Slightly nitpicky, but while lack of support for multithreading might make a particular app slow or unresponsive, I'd have thought it makes it less likely for that app to be able to bring the entire system to its knees.

Reply on news.ycombinator.com