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

161–170 of 171 posts

Re: The browser's main thread is expensive

#161

Post by pjmlp »

stickfigure wrote: post #147
sgift wrote: post #138

Earlier quoted context omitted.

Ignoring for a moment that most websites don't need any interactivity: Even for those that need it, for almost any of them something JQuery-like is more than enough. You really, really, really don't need the latest super big framework.

> most websites don't need any interactivity I dispute this. I don't have any statistics either, but my subjective experience is that most websites are not like newspapers or blogs. Even shopping websites have pretty heavy interactivity these days. Also, most boring pure-information-presentation problems are mostly solved by ancient technologies like wordpress. If you're working in web development in 2026, you probab…

There is hardly anything novel in Web other than catching up to Flash or native apps.

Re: The browser's main thread is expensive

#164

Post by amelius »

odo1242 wrote: post #134
amelius wrote: post #121

Earlier quoted context omitted.

You are saying it as if there is some logical consequence.

No, I'm just saying that cooperative multitasking is there for good reason and isn't necessarily a bad idea.

But you left out what the reason is.

Re: The browser's main thread is expensive

#165

Post by pedrovhb »

kccqzy wrote: post #114

Here is a problem that I had thought about in my last frontend project: the project needed to parse a user-provided string to provide syntax highlighting. The implementation was to parse the string immediately after a user keystroke so the user always sees correct colors. But I had this nagging thought that if I had designed the grammar wrong some parses might take more than linear time and would hold the main thread…

You'd use an incremental parser, they're specifically designed to be efficient for small edits. The big name is `tree-sitter`, but its output is compiled so on the web it requires some wasm shenanigans. For webpages, I'm a fan of `lezer`: https://lezer.codemirror.net/docs/guide/

Re: The browser's main thread is expensive

#166

Post by duskdozer »

bgirard wrote: post #107
nerdralph wrote: post #81

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 eve…

It's a good nitpick. A hypothetical 1000Hz display will still look smooth to the human eye at 60/120Hz. A 1Hz display will never look smooth. But it's more about honoring the user's preference. I personally would rather 60Hz, then 120Hz heating up my room unnecessarily. If someone has a display set to 1000Hz for whatever reason, then you should try your best to honor that.

It depends. My display being at 1000hz doesn't mean I need your homebrewed accordion menu eating up the CPU to slide out and wiggle at 1000hz

Re: The browser's main thread is expensive

#167

Post by duskdozer »

bee_rider wrote: post #70
bob1029 wrote: post #57

If you are currently trying to build a web-based clone of something approximating ChatGPT, pretty much everything in this article is absolutely mandatory. The streaming response UI/UX is a total nightmare to make work smoothly. You have to come up with clever heuristics around where to chop up the stream of changes and how to batch the work relative to frame updates to make it not look like confetti during a streamin…

I really don’t understand why the LLM web chat clients have all converged on this UI where one character appears at a time. It is kind of fun the first time (like you are watching some Harry Potter special effects where an enchanted book writes itself). But really they could send sentence or paragraph long chunks of text, it would be fine. Seems like an artifact of the time when tokens-per-second were low enough that…

I suspect one reason is to subtly make the user feel more like they are interacting with a person.

Re: The browser's main thread is expensive

#168

Post by andrekandre »

locknitpicker wrote: post #146
Spivak wrote: post #145

Earlier quoted context omitted.

Yes? Users often prefer a nice GUI but CMSs are effectively what you describe and run the majority of content oriented sites. Static site generators are just the dev-centric version of that. The more common situation is that you're generating pages on the server and shipping a massive JS bundle just to display what could have been rendered once. But even given your position you see no difference between shipping the…

> Yes? Users often prefer a nice GUI but CMSs are effectively what you describe and run the majority of content oriented sites. I don't think you understood my question. I stressed the fact that complaining about the complexity of a page implemented with a JavaScript framework is a red herring, because said complexity doesn't go away by moving it to a server. And the old "dynamic HTML" approach is not easier to maint…

  > said complexity doesn't go away by moving it to a server.
complexity for the client or for the developer?

  > why do software engineers bother with JavaScript frameworks?
because the dev cycle is much faster for the developer than most backend rendering stuff?

Re: The browser's main thread is expensive

#169

Post by phoghed »

cryptonym wrote: post #160
phoghed wrote: post #111

Earlier quoted context omitted.

These people definitely have an overly rosy view of the past. The sites that are dog slow shit ux now still would be with server rendered html and jquery spaghetti, just like they were in the past. Ever submit some giant form to get some random error and then lose the entire state of it? Used to be extremely common, even though it shouldn’t have been.

Losing the entire state happens on SPA. Plus a random error not providing any feedback is a typical SPA experience. You can poorly execute on any technology. It's just much easier to do things wrong using this-year-trendy-SPA-framework. Use the appropriate technology, everything doesn't have to be a SPA.

And yet it used to be much more common. SPA or not doesn't change how your team executes, what kind of management you're working under, or any other externality that makes you end up with a shit website.

Re: The browser's main thread is expensive

#170

Post by cryptonym »

phoghed wrote: post #169
cryptonym wrote: post #160

Earlier quoted context omitted.

Losing the entire state happens on SPA. Plus a random error not providing any feedback is a typical SPA experience. You can poorly execute on any technology. It's just much easier to do things wrong using this-year-trendy-SPA-framework. Use the appropriate technology, everything doesn't have to be a SPA.

And yet it used to be much more common. SPA or not doesn't change how your team executes, what kind of management you're working under, or any other externality that makes you end up with a shit website.

Yet you can look at RUM data (http archive tech report or other) and start noticing it's not just management.
Post reply on HN