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

So you want to build a browser engine

robert.ocallahan.org

Post reply on HN
Print view View original

111–120 of 134 posts

Re: So you want to build a browser engine

#111

Post by bdahz »

robin_reala wrote: post #106
bdahz wrote: post #92

Does anyone have the idea of escaping from HTML/CSS? As these specs are too complicated and not friendly for web developers as well. Maybe we could re-invent a browser engine without conforming to HTML/CSS specs? An (early) alternative spec/engine would be a Figma-compatible vector graphics spec[2] and its rendering engine[3]. It is called VeryGoodGraphics[1]. [1] https://verygoodgraphics.com/ , the website is built…

VeryGoodGraphics has no accessibility tree and no results when searching the documentation for “accessibility”, which makes it broadly immoral (or if you want to disagree with that, at least illegal to use it to build production systems in many locations). If you can’t get that right from the start, or even have plans for it, then you’re obsolete.

If there is a VGG-native browser then accessibility is not so hard to implement. The awkward problem is that current VeryGoodGraphics is just a canvas node in HTML (using WebAssembly + WebGL). So adding accessibility support will be a nightmare technically.

Re: So you want to build a browser engine

#112

Post by bdahz »

eropple wrote: post #109
robin_reala wrote: post #106

Earlier quoted context omitted.

VeryGoodGraphics has no accessibility tree and no results when searching the documentation for “accessibility”, which makes it broadly immoral (or if you want to disagree with that, at least illegal to use it to build production systems in many locations). If you can’t get that right from the start, or even have plans for it, then you’re obsolete.

Even if you don't care about that (and you should!), "you can't highlight text [without doing additional work that nobody will do because it wasn't an explicit KPI for them]" is itself really disappointing and bad. We escaped Flash. We shouldn't clamor to go back.

The reasons to escape Flash are the performance and power-consumption issues, rather than accessibility.

If you take browser as a document viewer then accessibility is critical. However if you take browser as a universal application platform, then accessibility is not necessary, right?

Re: So you want to build a browser engine

#113

Post by robin_reala »

bdahz wrote: post #112
eropple wrote: post #109

Earlier quoted context omitted.

Even if you don't care about that (and you should!), "you can't highlight text [without doing additional work that nobody will do because it wasn't an explicit KPI for them]" is itself really disappointing and bad. We escaped Flash. We shouldn't clamor to go back.

The reasons to escape Flash are the performance and power-consumption issues, rather than accessibility. If you take browser as a document viewer then accessibility is critical. However if you take browser as a universal application platform, then accessibility is not necessary, right?

No? Why shouldn’t apps be accessible?

Re: So you want to build a browser engine

#114

Post by PaulDavisThe1st »

GuB-42 wrote: post #86
amelius wrote: post #6

This makes writing a compiler or writing an OS kernel look like child's play.

I'd say a browser is an OS. It is, of course, higher level than a kernel like Linux that can run on the bare metal, but it has most of the aspects of a full OS. It manages memory, processes and security, it can run user-supplied arbitrary code. It has an API, not unlike system calls that allows programs to access the underlying hardware. It doesn't do thing like writing on the address bus directly, but it does have t…

Any application (or library, or framework) that can dynamically load files that lead to causal executable behavior meets your description above in substantial part.

Re: So you want to build a browser engine

#115

Post by PaulDavisThe1st »

Paul-Craft wrote: post #8
amelius wrote: post #6

This makes writing a compiler or writing an OS kernel look like child's play.

A browser engine is a compiler. Or, more properly, it's at least two compilers (HTML + CSS -- you can outsource JS to V8 or whatever).

Your use of the term "compiler" to mean "something which transforms an input into a (different kind of) output" seems a little broad here.

We do not typically call TeX a "compiler". We don't consider XSLT engines to be "compilers". dot(1) is not normally considered to be a "compiler". And so on.

Re: So you want to build a browser engine

#116

Post by ngrilly »

mike_hearn wrote: post #87
esprehn wrote: post #68

Engine diversity is really important for the ecosystem and continued innovation. While building something competitive with the big three engines is a monumental task there's still a lot of value in building alternative engines to try new ideas even if getting "the whole web" implemented is basically impossible. For example: - Servo vs Blink vs Cobalt do selector matching and style resolution very differently. - WebKi…

But none of those differences are especially interesting. They certainly don't matter much for the ecosystem, and have no impact on web developers. All the major engines have comparable performance. And the differences are dwarfed by what they must do the same, because the way web tech works basically only allows one implementation architecture. If you wanted to innovate in browser tech you'd really need to leave the…

> If you wanted to innovate in browser tech you'd really need to leave the specs behind.

This is pretty much what the author is suggesting by the end the article: "Instead of being a Web browser, you might want to initially try just being a faster, lighter or lower-power Electron or WebView. Then the Web compatibility barrier would be much less of an issue."

Re: So you want to build a browser engine

#117

Post by shepherdjerred »

mepian wrote: post #43
amelius wrote: post #6

This makes writing a compiler or writing an OS kernel look like child's play.

A compiler by itself is surprisingly easy, especially if you read Abdulaziz Ghuloum's or Jeremy Siek's tutorials. Making it competitive with state-of-the-art compilers like Clang or HotSpot is difficult, but this is true for every kind of software.

A compiler for a toy language is easy. 99% of professional programmers probably could not implement a compiler for C.

Re: So you want to build a browser engine

#118

Post by RussianCow »

bdahz wrote: post #112
eropple wrote: post #109

Earlier quoted context omitted.

Even if you don't care about that (and you should!), "you can't highlight text [without doing additional work that nobody will do because it wasn't an explicit KPI for them]" is itself really disappointing and bad. We escaped Flash. We shouldn't clamor to go back.

The reasons to escape Flash are the performance and power-consumption issues, rather than accessibility. If you take browser as a document viewer then accessibility is critical. However if you take browser as a universal application platform, then accessibility is not necessary, right?

> However if you take browser as a universal application platform, then accessibility is not necessary, right?

Are you really suggesting that people with disabilities shouldn't be able to use web apps?

Re: So you want to build a browser engine

#119

Post by bdahz »

bdahz wrote: post #112
eropple wrote: post #109

Earlier quoted context omitted.

Even if you don't care about that (and you should!), "you can't highlight text [without doing additional work that nobody will do because it wasn't an explicit KPI for them]" is itself really disappointing and bad. We escaped Flash. We shouldn't clamor to go back.

The reasons to escape Flash are the performance and power-consumption issues, rather than accessibility. If you take browser as a document viewer then accessibility is critical. However if you take browser as a universal application platform, then accessibility is not necessary, right?

Sorry, I was just raising my question. Because in my country most app maker does not care about accessibility. Now I know.

Re: So you want to build a browser engine

#120

Post by locallost »

bdahz wrote: post #92

Does anyone have the idea of escaping from HTML/CSS? As these specs are too complicated and not friendly for web developers as well. Maybe we could re-invent a browser engine without conforming to HTML/CSS specs? An (early) alternative spec/engine would be a Figma-compatible vector graphics spec[2] and its rendering engine[3]. It is called VeryGoodGraphics[1]. [1] https://verygoodgraphics.com/ , the website is built…

Lively Kernel was one such idea.

https://youtu.be/gGw09RZjQf8?feature=shared

Post reply on HN