Live data from Hacker News

The browser's main thread is expensive

kciter.so

161–165 of 165 posts

Re: The browser's main thread is expensive

#161
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

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 #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/
Post reply on HN