Hacker News Reader

Comment by throwaway27448 | Hacker News Reader

> Not sure why someone would say it was a wrong decision.

Writing almost anything with javascript sucks ass to begin with. Writing native code with it is even more painful. Most javascript engines don't even have any decent model of parallelism. It takes zero imagination to see the problem here

View on HN

how much parallelism are you writing in your frontends?

The problem with everything being single threaded isn't so much that you want to do a lot of parallel processing, but that you don't want to have the occasional fat loop cause the whole engine to start stuttering. If you want butter smooth scrolling while there's (for example) a lot of dynamic content moving around, you want very precise control of the threading so you can get the gnarly stuff done without causing hitches that don't feel right.

The browser, iOS, and Android all use a main thread separate from the thread responsible for scrolling animations.

However, I think it's true that controlling threading in order to perform gnarly work in a separate thread is more ergonomic on mobile than in JS/React.

You'd need to create a Promise that wraps a Web Worker, which would be an unusual thing to use. I don't think most apps need such control over threading in the browser.

If you care about smooth interactions, the browser even in 2026 is not the most straightforward route, nor the route any reasonable small company takes.

I mean, why would they admit to it being the wrong decision. Its a business.

Reply on news.ycombinator.com