5 ms·

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

by aikah 10y ago

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

BinaryIdiot 10y ago
> 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.
jaquers 10y ago
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.
- dilann 10y ago
  > 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.
  - goatlover 10y ago
    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.
mrec 10y ago
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.
mmatants 10y ago
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.
pcwalton 10y ago
> 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?
- aikah 10y ago
  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.
fenomas 10y ago
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.

by aikah 10y ago

BinaryIdiot 10y ago

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

jaquers 10y ago

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.

dilann 10y ago
> 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.
- goatlover 10y ago
  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.

mrec 10y ago

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.

mmatants 10y ago

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.

pcwalton 10y ago

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

aikah 10y ago
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.

fenomas 10y ago

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.