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

Web Browser Engineering (2021)

browser.engineering

Post reply on HN
Print view View original

111–120 of 138 posts

Re: Web Browser Engineering (2021)

#111

Post by niutech »

mike_hearn wrote: post #35
currygen wrote: post #24

It's refreshing that browser engineering seems to become a "trend" now. The ecosystem is quite sparse with basically only Google, Apple and Mozilla defining it. I'd like to see forward into a future with more independent browser engines.

I don't think it's worth trying to write a rendering engine for HTML. You will never finish - HTML is a spec fully owned by Google and Apple at this point and it's just too complex to implement from scratch. The interesting space is really post-HTML UI/document tech. There's another thread running about Typst which is a sort of better LaTeX. Markdown was highly impactful. There's a lot of scope for people to do inter…

> I don't think it's worth trying to write a rendering engine for HTML. You will never finish - HTML is a spec fully owned by Google and Apple at this point and it's just too complex to implement from scratch.

Andreas Kling, the author of Ladybird browser, proves otherwise.

There is also QML as an alternative for HTML - see Canonic browser: https://www.canonic.com

Re: Web Browser Engineering (2021)

#112

Post by userbinator »

mannyv wrote: post #32

One great thing about this book is the 'stuff I didn't do' part. Layout is really hard. Just tables by themselves are hard, even without any css around them. CSS makes layout impossibly difficult. I challenge anyone to keep the whole CSS spec and its associated behaviors in their head. At this point css + html + javascript have become a dynamic PDL, and probably is one of the most complex pieces of software today. As…

Tables are trivial in comparison to floats. If you think the latter are easy --- there are many (literal) edge-cases to consider.

Re: Web Browser Engineering (2021)

#113

Post by niutech »

01HNNWZ0MV43FF wrote: post #31
currygen wrote: post #24

It's refreshing that browser engineering seems to become a "trend" now. The ecosystem is quite sparse with basically only Google, Apple and Mozilla defining it. I'd like to see forward into a future with more independent browser engines.

Something that uses less RAM would be nice. Other than that and the spyware from Capital-G Google Chrome and Capital-M Mozilla Firefox, I don't have a problem with it being sparse. It's millions of hours of de-duplicated work. I'd like an alternative to HTML though. If I was to make a browser maybe I'd focus on replacing HTML because I can't stand it, and replacing js just because the runtime is heavy. Like, a browse…

For less RAM, try: Dillo, Netsurf, Otter Browser, K-Meleon, Pale Moon, Basilisk, Ultralight.

As an alternative for HTML, why not QML with Canonic browser?

Re: Web Browser Engineering (2021)

#114

Post by kroltan »

mattlondon wrote: post #28
DavidPiper wrote: post #18

Earlier quoted context omitted.

I'm one of those ~nobodies. Firefox is actually quite good these days, I use it at home and at work, 100% of the time - i.e. no Chrome or Safari fallback needed. If anyone's looking for a reason to try a switch again, consider this your sign.

Is the performance hit sorted yet when opening a page? For me Firefox used to hang for a second or two doing something? Just a blank screen with the progress bar paused around 20% or so and apparently nothing happening...(DNS? HTTPS handshake?) and then it would kick off and load normally. Happened on mobile(android) and desktop(windows, Linux, macros). On chrome-based browsers the same pages on the same computers on…

Did you happen to have used uBlock Origin during your stay?

It's the most common source of browser-load latency, as it by default blocks the main page request until it is able to load its blocklists, so when you open the browser afresh, or reopen a window, it takes a while until the browser gets to continue loading the thing you asked.

I think by default it comes as enabled in Firefox, go to the "uBlock settings > Filter Lists > Suspend network activity until all filter lists are loaded", though of course it is a tradeoff.

From the Wiki: https://github.com/gorhill/uBlock/wiki/Dashboard:-Filter-lis...

> In Firefox-based browsers, this setting is enabled by default. Disabling it gives the option to potentially speed up page load at browser launch, at the cost of possibly not properly filtering network requests as per filter lists or rules.

> In Chromium-based browsers, this setting is disabled by default, since Chromium-based browsers do not support natively suspending network requests.2 Enabling this setting in Chromium-based browsers may lead to negative side-effects at browser launch.

Re: Web Browser Engineering (2021)

#115

Post by pmarreck »

niutech wrote: post #109
pmarreck wrote: post #42

Earlier quoted context omitted.

Or perhaps an entirely new platform/protocol, since this one is completely saturated with complexity at this point.

Why not go back to WAP & WML? ;) There is QML (see https://www.canonic.com ) and Gemini (see https://gmi.skyjake.fi/lagrange/ ) as alternatives.

These are fascinating!

Re: Web Browser Engineering (2021)

#116

Post by khana »

vbezhenar wrote: post #45
mannyv wrote: post #32

One great thing about this book is the 'stuff I didn't do' part. Layout is really hard. Just tables by themselves are hard, even without any css around them. CSS makes layout impossibly difficult. I challenge anyone to keep the whole CSS spec and its associated behaviors in their head. At this point css + html + javascript have become a dynamic PDL, and probably is one of the most complex pieces of software today. As…

This Babylonian tower will crumble one day. Layout does not have to be so complex. There are dozens of GUI frameworks with simpler layout system. Those are enough for applications everyone uses.

[dead]

Re: Web Browser Engineering (2021)

#117

Post by mike_hearn »

niutech wrote: post #111
mike_hearn wrote: post #35

Earlier quoted context omitted.

I don't think it's worth trying to write a rendering engine for HTML. You will never finish - HTML is a spec fully owned by Google and Apple at this point and it's just too complex to implement from scratch. The interesting space is really post-HTML UI/document tech. There's another thread running about Typst which is a sort of better LaTeX. Markdown was highly impactful. There's a lot of scope for people to do inter…

> I don't think it's worth trying to write a rendering engine for HTML. You will never finish - HTML is a spec fully owned by Google and Apple at this point and it's just too complex to implement from scratch. Andreas Kling, the author of Ladybird browser, proves otherwise. There is also QML as an alternative for HTML - see Canonic browser: https://www.canonic.com

Andreas hasn't finished. Also, I question to what extent it's worth it.

Re: Web Browser Engineering (2021)

#118

Post by echoangle »

msie wrote: post #96
vbezhenar wrote: post #45

Earlier quoted context omitted.

This Babylonian tower will crumble one day. Layout does not have to be so complex. There are dozens of GUI frameworks with simpler layout system. Those are enough for applications everyone uses.

Pixel positioning is so nice! I remember how easy it was to layout UIs with VB.

How does that work when someone resizes a window? I'm genuinely asking because pixel positioning to me sounds like hardcoding positions. Do you have to manually code the reflow when the window becomes narrow for example?

Re: Web Browser Engineering (2021)

#119

Post by Sesse__ »

afavour wrote: post #50
pstrateman wrote: post #34

Earlier quoted context omitted.

> As an aside, video decoding is offloaded onto hardware, so it's not as battery intensive as it used to be. This is technically but not usefully true with most videos on the web today. The video decode itself is accelerated, but each frame passes through JavaScript to be composited. The only time video is fully hardware decoded is when it's a simple video element to a static video file.

> not usefully true with most videos on the web today > The only time video is fully hardware decoded is when it's a simple video element to a static video file. These seem in disagreement to me. The vast majority of videos on the web are simple video elements going to static video files. It is not usual for each frame to pass through JavaScript before being displayed.

The decoded frames do not pass through JavaScript. The compressed data may (e.g. if you are using the Media Source API).

Re: Web Browser Engineering (2021)

#120

Post by mannyv »

Some major problems that browsers have to deal with have to do with UI. Specifically:

1. Users expect the UI to update in realtime,

2. Developers expect the UI to update in realtime,

3. UIs tend to be single threaded, and

4. The principles of software engineering and the reality of software stress encapsulation, but the realtime nature of UI requires visibility into these processes.

And of course this impacts the Javascript layer, since this is yet another environment with the same constraints as above.

Post reply on HN