Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The browser's main thread is expensive

kciter.so

Post reply on HN
Print view View original

81–90 of 163 posts

Re: The browser's main thread is expensive

#81

Post by nerdralph »

I agree with most of the article, but would clarify the following: > For the screen to look smooth, frames have to be drawn at the display’s refresh rate. On the most common 60Hz display, that means 60 frames per second, or about 16.6 milliseconds per frame.

It isn't absolutely necessary to match the display refresh rate. With a 144Hz monitor, 72FPS is going to look smooth for the vast majority of the people, and even 48FPS will look smooth for most people. I agree that higher FPS is better, but there are diminishing returns.

Re: The browser's main thread is expensive

#82

Post by mikemarsh »

I remember seeing some JS cryptography library a long time (maybe 10 years?) ago that provided an async hashing function for exactly this reason: to split up what would normally be a simple synchronous computation and yield more often to the main thread.

Can't recall the name, but I remember thinking that was very clever once I understood why it was doing that, and am glad to see the concept explained directly here.

Re: The browser's main thread is expensive

#86

Post by doix »

cryptonym wrote: post #58
jcelerier wrote: post #56

Earlier quoted context omitted.

I challenge you to browse the web one week on this laptop part of the current top 10 Amazon best sellers on a gigabit fiber connection and tell me if you still think that this is the problem: https://www.amazon.com/HP-Everyday-Processor-Microsoft-Porta...

It is a problem and plays a role, then the rest of the SPA interactions are as bad. Amplified by 100+ third party scripts. Stop building SPA, go back to HTML. Re-assess every third party. For extra performance and scaling, implement cache. Relax and see web experience healing.

There's definitely trade-offs. I actually prefer a proper SPA to pure HTML when on a slow connection and interacting with a site a lot.

Especially when trying to buy something. I much prefer to have a longer initial load and then have everything just work instead of waiting as I navigate between pages, the multi stage checkout, confirmation etc.

But yeah, if I'm just trying read a single article on a blog, preloading everything is pointless. A hybrid site with the initial page being server side rendered + progressive enhancement afterwards is theoretically optimal in my opinion.

Re: The browser's main thread is expensive

#87

Post by mschuster91 »

prodigycorp wrote: post #42
mschuster91 wrote: post #21

> So what if off-screen posts were left as empty shells that only take up their height, and got filled with real content as they approach the screen? Yeah fuck everyone doing that, hello Reddit, Outlook for Web or Bluesky. It makes searching on such "feed" pages with the browser's search function an utter pain in the ass, made worse by the fact that the platforms' own search functions are outright braindead.

what's your solution to the performance hit that you get when you load up the dom with a zillion things? long, unvirtualized threads will bring every decent computer to its knees. the sites could implement their own search to make it all work if they wanted to. they just dont. but blaming virtualization is not tit.

> what's your solution to the performance hit that you get when you load up the dom with a zillion things?

Browsers can easily render and scroll through entire wads of content.

The problem is, when the "line" comprising an email in the email list of Outlook Web is in a maze of (literally, just looked it up) about 30 divs deep, performance inevitably goes down the drain.

Computers in the 00s could handle inboxes with thousands of emails just fine and scroll through them. Outlook struggles keeping more than 30 in active memory. That's gotta be a joke.

By the way: the solution is rendering tabular stuff in, well, tables instead of armies of divs that try to be tables. That case has been optimized to death because that is how websites and applications used to be built.

Re: The browser's main thread is expensive

#88

Post by pjmlp »

fxd wrote: post #79
pjmlp wrote: post #67

Earlier quoted context omitted.

What a joke of challenge, there is still no browser 3D game that is a match to Infinity Blade, that Apple used to demo OpenGL ES 3.0 hardware in 2011. Anyone serious about 3D gaming on the Web has to do streaming.

[flagged]

Prove that I was the one down voting before writing such shitty reply!

Re: The browser's main thread is expensive

#89

Post by morning-coffee »

jkhdigital wrote: post #22

This article concludes with the following statement: > So much of development is trade-offs, and you have to choose according to the situation, which ultimately comes down to the developer’s experience and judgment. It’s a great article, but I think it is a bit behind the ball in framing scheduling problems as a matter of “experience and judgment”. The problem of allocating work to a scarce resource is one of the old…

This! Since it became easier for people to post their thoughts on a problem vs. research and learn from past work, we're now in the era where its harder to find the seminal and really-well-explained material for having to wade through years and years of people's rediscovery blogs.

(Don't get me wrong; I too think the article is great; just wish all the folks who went to JS bootcamp and are amazed by this would have cracked any CS or OS text book written since the late 60's and browsed a few chapters.)

Re: The browser's main thread is expensive

#90

Post by pjmlp »

groundzeros2015 wrote: post #78
pjmlp wrote: post #67

Earlier quoted context omitted.

What a joke of challenge, there is still no browser 3D game that is a match to Infinity Blade, that Apple used to demo OpenGL ES 3.0 hardware in 2011. Anyone serious about 3D gaming on the Web has to do streaming.

ES 2.0

Correct, my mistake.
Post reply on HN