Hacker News Reader

Comment by colordrops | Hacker News Reader

Hate to go down this road, but JavaScript is anything but slow. What is slow is the layer upon layer of complexity + poor coding of many web apps. That's not an exclusive problem to JavaScript.

View on HN

There is some amount of overhead in the VM due to the dynamic nature of JavaScript values and the need for a GC that can't be avoided (even though VM implementations have had years of effort and optimization put in to address this). You can get around a lot of this by using WASM and having control over the data layout though. In my experiments some times the browser just kicks in and drops some frames in any case. :/ Things just feel a lot smoother in native apps always. Figma for example is doing a pretty good job with a C++ engine running in WASM and using WebGL for their canvas (https://www.figma.com/blog/webassembly-cut-figmas-load-time-...).

It can be avoided to a degree if you understand how JavaScript memory allocation works for a particular VM, and use custom methods instead of built-ins for certain operations, to avoid the overhead of the generalized nature of the built-in.

You might reduce it for sure, but you aren't going to avoid it entirely. The best is when it gets to a tracing JIT and all of the calls have a similar codepath. And the fact that you need to jump through hoops like this instead of just writing normal code and expect it to do only what you're saying instead of doing a bunch of other stuff too, is part of the problem. Like, what you are saying, is exactly the point: the default method of working introduces performance issues and makes it hard to reason about performance in a way that is predictable, requiring you to understand VM internals and just 'hope' that the runtime works it out. So you are essentially saying that the default path is slower. It's also hard to ensure that your objects have a predictable layout in memory (important for cache issues) other than by just using a `TypedArray` and re-inventing structs within that.

The semantics of JS itself make certain optimizations hard. Even a simple VM can do arithmetic faster than no-JIT Node.js and JSC: https://godbolt.org/z/5GbhnK (an example I've been working on lately) (I'm interested in no-JIT perf because that's what you're allowed to do in your own runtime on iOS). LuaJIT is the best at this, and even there Lua's semantics prevent certain optimizations--https://news.ycombinator.com/item?id=11327201

I think you can do a lot better with a bytecode that is more 'typed', like in SPIR-V: https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.html...

Everything you say is correct, but I was just addressing the statement that "it can't be avoided".

For sure, I think you can mitigate it, but I would take that as being different from avoidance (simply because there are other languages / runtimes where there is clear actual avoidance). Regardless I think we have enough details in the conversation at this point to understand what each other is saying. :)

Yes, for sure :)

> Hate to go down this road, but JavaScript is anything but slow. What is slow is the layer upon layer of complexity + poor coding of many web apps. That's not an exclusive problem to JavaScript.

where are those fast javascript apps ? where ? compare the super snappiness of a Telegram Desktop with molasses $every_other_chat_client_using_electron for instance. And if you are gonna say that VSCode is fast you have no idea how truly fast software feels like - if you come across try a QNX 6 demo iso and be amazed at how fast your computer answers to literally everything.

That doesn't contradict my statement at all.

The problems you speak of are due to the browser runtime, not JavaScript.

What makes you say that they aren't also due to the kind of programming style that JS encourages ?

Also, my anecdotal experience writing some audio algorithms in pure JS is that it's ... not an order of magnitude, but not far away, from the performance of the same code written in C++ with std::vector<double>s. Likely there's some magic that could be done to improve it, but the C++ code is written naïvely and ends up extremely well optimized.

VSCode seems fast until one starts Notepad++ or Sublime Text.

Microsoft's React Native team has charts where it shows Electron has 300x slowdown versus native applications.

The poor coding is one thing, but it's javascript's fault that layers of complexity inherently result in performance losses beyond those caused by leaky abstractions.

JavaScript is just a programming language with the same constructs as any other. And it's much faster than most languages, especially dynamically typed languages.

It sounds like you don't understand how a browser works. Performance issues are typically due to the browser runtime environment which includes a slow and complex DOM.

JavaScript will mop up most CLI apps in performance, including python and ruby, and will get close in perf to C if written carefully.

> JavaScript will mop up most CLI apps in performance

I'll bet half the coreutils are a minimum of 10x slower in their day-to-day use cases (i.e. small n) when re-implemented in any interpreted language like JS. Cold start overhead matters a lot for CLI programs.

> JavaScript will mop up most CLI apps in performance, including python and ruby, and will get close in perf to C if written carefully.

asm.js is what you mean?

If you so, you are not better to handwriting an assembly yourself.

I am kind of an involuntary webdev from time to time, and I am often the one invited to fix consequences of coding under influence, like a decision to write a GPS server with 100k+ packets per second load in Javascript.

People claiming that JS can be made be as fast as C have no idea at all what they say. Even Java with hand-jacked VM is easier to scale for such load than a JS server reduced to 1k lines of vanilla JS, using all and every performance trick Nodejs provides.

No I don't mean asm.js. You can write vanilla JS that avoids memory allocation beyond initialization as well as garbage collection, and runs certain algorithms faster than typical C due to differences such as JIT optimizations or the lack of a sentinel to terminate strings, etc.

My point was never to say that JS is in general as fast as C, only that a careful dev that is familiar with the VM's operation can get close for some tasks.

> [...] the browser runtime environment which includes a slow and complex DOM

Counter to this narrative the DOM is very fast, and compared to many other platforms it's much faster at displaying a large number of views and then resizing and reflowing them.

ex. Android warns when there's more than 80 Views, meanwhile Gmail is 3500 DOM elements and the new "fast" Facebook is ~6000 DOM elements. Neither of those apps spends the majority of their time in the browser code on load, it's almost entirely JS. Facebook spends 3 seconds running script on page load on my $3k Macbook Pro. That's not because the DOM is slow, that's because Facebook runs a lot of JS on startup.

If you cut down to the metal browsers can be quite fast, ex. https://browserbench.org/MotionMark/

Giants like Airbnb have resources to write fast and responsive apps. But it is still slow. There is no point to worry about 16ms latency, if web app refreshes 6x times just to load couple of images.

Reply on news.ycombinator.com