Live data from Hacker News

Early stages of Google Docs support in the Ladybird browser

twitter.com

61–70 of 89 posts

Re: Early stages of Google Docs support in the Ladybird browser

#61

Earlier quoted context omitted.

Mozilla wrote Gecko, with enough web compat to effectively take on IE6, in about 4 years. We made a couple of significant changes in years 4-6 right before Firefox launched, but Gecko was basically "there" about 4 years after Mozilla transitioned from the old Communicator engine to Gecko/NGLayout/Raptor/Magellen. Having said that, Gecko wasn't a Netscape start from scratch effort. They acquired and built on a very si…

> Mozilla wrote Gecko, with enough web compat to effectively take on IE6, in about 4 years. Yes, but web standards were at least an order of magnitude simpler back then.

How to build a browser is also a much more solved problem now.

Re: Early stages of Google Docs support in the Ladybird browser

#63

Earlier quoted context omitted.

Mozilla wrote Gecko, with enough web compat to effectively take on IE6, in about 4 years. We made a couple of significant changes in years 4-6 right before Firefox launched, but Gecko was basically "there" about 4 years after Mozilla transitioned from the old Communicator engine to Gecko/NGLayout/Raptor/Magellen. Having said that, Gecko wasn't a Netscape start from scratch effort. They acquired and built on a very si…

> Mozilla wrote Gecko, with enough web compat to effectively take on IE6, in about 4 years. Yes, but web standards were at least an order of magnitude simpler back then.

I noted that in the later sentences of my comment. Yes, the platform is larger. But in some cases, it's also more sensible now that standardization has had 20 years to work it over. When Gecko was being developed, it was half implementing standards and half reverse engineering Microsoft's undocumented web APIs. Still, I'm sure it's nevertheless harder today and that's why I said so near the end of my comment.

Re: Early stages of Google Docs support in the Ladybird browser

#64
post #20

Link is to a Nitter instance. Even though I prefer to use it as well, it should probably be pointed to the original Twitter instead? For deduplication purposes if nothing else.

To second this, many of the nitter instances and other twitter flattening sites are blocked by corporate security scanning proxies. For those in that situation, note that you can replace the domain name with twitter.com to get the original URL.

Side issue, but why do corporate security scanning proxies block nitter?

Re: Early stages of Google Docs support in the Ladybird browser

#65

Earlier quoted context omitted.

Mozilla wrote Gecko, with enough web compat to effectively take on IE6, in about 4 years. We made a couple of significant changes in years 4-6 right before Firefox launched, but Gecko was basically "there" about 4 years after Mozilla transitioned from the old Communicator engine to Gecko/NGLayout/Raptor/Magellen. Having said that, Gecko wasn't a Netscape start from scratch effort. They acquired and built on a very si…

> Mozilla wrote Gecko, with enough web compat to effectively take on IE6, in about 4 years. Yes, but web standards were at least an order of magnitude simpler back then.

Not really - there are certainly more of them, but - and this is extremely important - Mozilla, Apple, Google, and even MS spent the best part of a decade essentially rewriting the specifications that made up the web platform.

The DOM, etc through the work that eventually got labeled HTML5 made it possible to follow the spec and, as a super simple and "obvious" example, parse URLs in a way that worked. The existing specs of the era were often incomplete, semi-frequently what they did say did not match how browsers actually worked, and frequently ambiguous which meant that implementing anything required exhaustively testing what everyone else did to try and match it.

TC39 eventually recognized that the same issues existed in the ECMAScript spec, and recognized that ES4 did nothing to resolve those issues, while adding considerable complexity and more of the same issues. That's how we ended up with ES3.1 - it was an attempt to actually correctly and completely specify the language and runtime, ES5 continued/finished that catchup (ES3.1 did not resolve all the issues) while adding a few important features, but was still in the "make it possible for someone to implement the spec and be confident that they could run anything any other engine could run".

So in the modern browser there are many more specs, but those specs are much easier to confidently implement as you can get basic working behaviour by essentially translating the spec language into your environment.

Making the resulting engine fast, memory efficient, etc is of course another thing entirely (although even that is aided by removing ambiguity in the specs as the lack of ambiguity means that you can actually write tests now).

Re: Early stages of Google Docs support in the Ladybird browser

#66
post #49

Is this using Google Docs new(ish) canvas-based rendering? https://workspaceupdates.googleblog.com/2021/05/Google-Docs-... Honestly not sure if it's harder to support canvas or DOM based rendering.

What do you mean by harder to support? Supporting - in the sense that it works - canvas rendering is much simpler than even minor amounts of the DOM. The problem of course is that you're replacing compiled C++ that is doing the normal DOM/CSS layout and rendering with someone implementing the layout and rendering in JS (sans actual bitblitting, etc).

Re: Early stages of Google Docs support in the Ladybird browser

#67
post #56

Earlier quoted context omitted.

I'm actually pretty impressed with the Chromium source code. For such a huge, old and complex project, I think it is rather impressive. It's a lot better than the Linux kernel for example, another project of similar size/age/complexity.

I think a significant factor in this is that C++ simply has better abstractions for building large codebases than C does. Any big enough C project is gonna turn out a bit funky.

For quite a long time now I have said that the future for the Linux kernel could easily be C++ rather than rust.

Rust is very cool and have no issue with it in the kernel tree but C++ would prevent so many bugs and eliminate so many lines of code. It's just ego.

Re: Early stages of Google Docs support in the Ladybird browser

#68
post #60

I'm so impressed with the LadyBird / SerenityOS browser engine! It took Mozilla more than 25 years to write Firefox's HTML engine and here are a couple of geniuses who write a web browser from scratch in just a few years!! Including Javascript (however, as of yet lacking video and WebGL). And Google's Chromium is simply a convoluted mess, chockful with vulnerabilities and memory corruption errors.

> And Google's Chromium is simply a convoluted mess, chockful with vulnerabilities and memory corruption errors. I'm sorry, but Ladybird is written in C++. Therefore, it's inevitable that it will have vulnerabilities and memory corruption errors.

> Therefore, it's inevitable that it will have vulnerabilities and memory corruption errors.

Is it though?

Re: Early stages of Google Docs support in the Ladybird browser

#69

Building this for the first time on my laptop. Can I just say, they realy thought about the build. Even though they have non-trivial dependencies, the build for those just trying it out is really easy, just four commands.

As if... it's made to be build-able by third parties, eh?

I never managed to build Firefox nor Ungoogled-Chromium.

I'll give this new browser a try.

Re: Early stages of Google Docs support in the Ladybird browser

#70
post #69

Building this for the first time on my laptop. Can I just say, they realy thought about the build. Even though they have non-trivial dependencies, the build for those just trying it out is really easy, just four commands.

As if... it's made to be build-able by third parties, eh? I never managed to build Firefox nor Ungoogled-Chromium. I'll give this new browser a try.

I readily admit that cooking the mozconfig is some holy hell, but they do have real-world examples in the repo; did you experience problems at that stage, or it literally wouldn't compile?

And while I haven't tried Ungoogled-Chromium, for unrelated reasons I helped an OSS project build their Brave-derivative in a container, so that may interest you: https://github.com/imperviousinc/beacon/blob/main/Dockerfile The only reason it's not already GitHub Actions for them is the chromium_src is 38GB and GHA cache is capped at 10G, but while digging up the link to that Dockerfile, I was reminded that there is a GHA for the macos build: https://github.com/ungoogled-software/ungoogled-chromium-mac...

Post reply on HN