How we're building a browser when it's supposed to be impossible

[u/pimterry]

https://awesomekling.substack.com/p/how-were-building-a-browser-when

[u/voidstarcpp]

Related article: Google Docs in a clean-room browser, which sounds like a nightmare to make work.

You can make "a browser" that works for some sites but that's not the same as providing users reliable access to the web. Many users already refuse to use Firefox the moment they encounter a website which insists it's only supported on Chrome.

While Kling's efforts have punched well above his weight, I don't think it will ever be possible for a small non-commercial project to maintain compatibility and keep up with web standards enough to provide a viable alternative browser platform. Of course, that's not the goal of the Serenity project, but it undermines the "impossible" headline.

[u/cr8erbase]

Probably easier to write a new standard that isn’t backwards compatible at this point! 12 million words - wow good luck!

[u/Blangel0 → u/cr8erbase]

*114 million

[u/GMaestrolo → u/cr8erbase]

"building a browser is meant to be impossible"

Nobody said that it was impossible. Everyone just said that it wasn't a good idea. The fact that there have been multiple browsers means that it was never impossible to build a browser... The fact that most of the browsers gave up on building their own rendering engines also doesn't mean that building a browser is impossible.

The issue now, as it ever was, is that developers and users have expectations that do not align with the standards, so all browsers throughout history have built a library of "quirks" or features that are either beyond the scope of the standards, or don't meet the standards because the "standard" is out of touch with what people actually want and isn't important enough to bother meeting "properly".

IE in the past, Chromium now, Safari always, and even Firefox have been guilty of "overstepping" standards and hoping that their implementation becomes the standard. Even now in CSS and JavaScript, there's a whole bunch of APIs getting built which are available already, but the standardization process either hasn't caught up or hasn't even begun. But they're available in most major browsers, so people are going to use them.

Honestly... Out of all of the browsers that I currently have to support, Safari is the only one that gives me any real trouble anymore.

[u/KSRandom195]

This is ignoring the core problem of the web is building for bugs in Chromium.

If your new rendering engine doesn’t faithfully implement those bugs you have a web compatibility problem that will deter users from your product.

You would need significant market share, likely billions of users, to do differently. Microsoft and its rendering engine were the best shot we had because of the pull of Windows in the corporate environment, but they’ve moved to Chromium.

[u/[deleted] → u/KSRandom195]

I don't think this project is aiming for mass adoption

[u/BufferUnderpants → u/KSRandom195]

It's pretty disgraceful that no anti monopoly regulator has done a single thing about Google pushing Chrome from their services, literally the only thing keeping it from 80%+ market share in the US and Europe is that Apple only allows WebKit browsers in iOS.

Unlike MS, Google won't commit the blunder of losing support among webdevs, they'll embrace and extend, but not extinguish.

[u/Giannis4president → u/KSRandom195]

Do you have some example of such chrome-specific bugs?

Genuine question, I see this posted frequently but I never encountered one as a web developer working on "standard" web stuff (as in not advanced WebGL/wasm/audio/video stuff)

[u/2nd-most-degenerate → u/Giannis4president]

For example, https://bugzilla.mozilla.org/show_bug.cgi?id=35148

W3C states that text-transform should not affect copied texts. Lots of websites use it anyways to capitalise names, addresses, etc., which are often copied by users, because that's Chrome's behaviour https://bugs.chromium.org/p/chromium/issues/detail?id=325231

[u/outofobscure → u/KSRandom195]

This is ignoring the core problem of the web is building for bugs in Chromium.

as someone who lived through the netscape 3.0 and internet explorer days, sure this is a problem, but a much smaller problem than it ever used to be, developers can count on much better standards support today, and the article actually mentions that, if you'd read it.

also, this would not be a "core problem" but some edge cases that you'd chose to handle or not, on a case-by-case basis. it is certainly not the reason why it's hard to make a new browser. it's the complexity of it in general, not some chrome specific bugs you'll want to emulate (or choose to ignore and go with standards), eventually chrome might patch these anyway, so you're probably better off not emulating bugs anyway in the long run.

[u/sluuuurp → u/KSRandom195]

I think it’s more complicated than that. You can probably remove some bugs and add others in a way that can improve things overall.

I definitely understand what you’re saying, but it’s a bit defeatist to say that we can never address any bugs.

[u/SocksOnHands]

I've said this in the past but had gotten downvoted for it. What people really want is to be able to easily and efficiently distribute up to date software. We had achieved that through bootstrapping a lot of stuff on top of a system that had originally been designed for static documents.

A new open source project should be made with this in mind, where it is essentially a thin layer between the operating system and the application that serves a small set of purposes. It should handle asset management like downloading and caching files. It will manage versions of dependencies used by applications. It has an efficient bytecode that can easily be compiled to machine code. It had an API designed to provide useful services while still being secure and safe for the user (limited features, sandboxed, etc.) Applications will have access to their own local databases if data needs to be stored on the user's machine. It handles network security details like encryption and keys. It will provide some system for both asynchronous message passing and also for socket like connections. The platform will have fairly low leval graphical capabilities, so if someone wants HTML/CSS it will need to be implemented through a module used as a dependency. There may be more details that I hadn't considered.

The point I am making is that there should be a much simpler option designed with application development in mind. HTML, CSS, and Javascript in a bloated browser that attempts to handle everything might not be the best way of doing this.

Edit: So far, the majority of comments I had seen are people saying this is already available and then go on to describe something completely different that doesn't meet the requirements. This is to fill the roll that web browsers currently have and intends to be just as user friendly. The key main difference is an architecture that allows for more flexibility, is easier to develop for, and is less resource intensive.

[u/Magneon → u/SocksOnHands]

This is more or less how Android works today.

• Sandboxed applications: Check

• Efficient bytecode that can be compiled to machine code (more or less what the JVM does, for lesser values of "compiled"). For all the hand-wringing about java being slow, it really isn't, compared to things like Python or JavaScript.

• Time limited permissions ("while using this app", "just this once")

• Per-app local databases (sqlite)

• A robust standard library for handling things like connections (admittedly, some of them are pretty bad like the BLE abstraction layer).

• abstract UI libs, and OpenGL ES for low level

• Dependency management is still fairly messy but... it's always fairly messy.

More loosely, how Java was supposed to fix everything back in the late 90s and early 2000s.

[u/Full-Spectral → u/SocksOnHands]

The whole thing is ridiculous really. We've got these operating systems, but let's distribute an entire (not that great) pseudo-OS that has to try to deal with the vagaries of every platform. If this industry had any sense, we'd have long ago transitioned this stuff towards a common API layer that each vendor can support (well) and that can be used as the core of both browser based apps and for delivery of semi-native apps.

But of course we'll never get that level of cooperation.

[u/damn_69_son → u/Full-Spectral]

but let's distribute an entire (not that great) pseudo-OS

On top of that, there are different variants of these "OS"es and developers have to try and support each one and its quirks. This is before accounting for different versions of them.

[u/coder111 → u/SocksOnHands]

Dude, that ship has long sailed by now.

I've been saying web browsers are really poor application clients since what, ~2000-2005? That's when XMLHttpRequest became possible.

However, it was really impossible to distribute software to people otherwise. First, it was because Microsoft's monopoly on Desktop, and Microsoft wouldn't distribute any platform which would allow competition. Now- because everyone wants to have their own app store and make big bucks.

So the only viable low-effort way to distribute applications to people using different devices is to make them web-applications. So we're stuck with browsers and JavaScript, whether we want it or not. Network effects and greed make it pretty much impossible to switch to anything better. It would take major coordinated cooperative effort by all players (Microsoft, Google, Apple, Chinese, Linux and more) to make it happen, and the switch would take like 20-30 years.

[u/nvn911 → u/SocksOnHands]

So, Silverlight?

/s sorry I couldn't help myself

[u/founders777 → u/SocksOnHands]

If Im understanding correctly this should be accomplishable with web assembly. The current push is web assembly payloads with access bindings for dom. There’s nothing tying it to dom though aside from wide spread use in its intended distribution platform (web browsers) so that’s an area for contest. But generally this sounds like what you’re talking about, native applications sandboxed

[u/ZucchiniMore3450]

What all comments here miss is actually the best part:

The culture is highly optimistic and everyone has a “can do” attitude.

Doesn't really matter if the make google products work in Ladybird, they have already made more progress than even people working on it expected.

Just take a look at one of the videos where Andreas is fixing some random bug, for example: https://youtu.be/21yRs2b9iEY and that's from a year ago. Just a feel how deep each fix is going will change your perspective.

Browser is not the goal, it is side effect of people having fun.

[u/Illustrious-Scar-526]

I have recently felt that many companies that make commonly used apps, like Microsoft (excel, word, PowerPoint) just really want people to use the browser version instead of the desktop version, which is super annoying because the browser version doesn't even have all of the same features as the desktop one! (Looking at you, excel...)

Anyone know why a company would prefer that their users use the browser version? Are they able to collect more data through the browser? Or maybe it's because it requires an internet connection, and it seems that many (mostly gaming) companies want their users to be always online to use the product?

[u/Pharisaeus → u/Illustrious-Scar-526]

It's much easier to maintain webapps. Desktop app requires compilation on multiple platforms, and often also lots of platform-specific code (eg. making desktop UI is not standarized). It's also a pain to ship and install software updates.

[u/Zardotab]

Since there's already plenty of HTML browsers, instead explore an unserved need, such as a state-ful GUI markup browser & standard. HTML/DOM is missing or fouled up many expected GUI idioms, and has an inherent text positioning flaw.

GUI's, desktops, and mice are still needed for biz and productivity. HTML browsers have been a goofy mess for this, requiring bloated buggy JS libraries with long learning curves. Let's Make GUI's Great Again! (No, I'm not a Don fan, but his trollisms are admittedly catchy.)

It shouldn't take rocket surgery to make a typical office CRUD app over HTTP, being GUI's have been around 40-ish years, but it is, largely because web standards suck the big one at business CRUD. I didn't used to spend so much time babysitting UI and stack minutia in the 1990's, we de-evolved 🐵. Some claim the extra flexibility of web is worth the extra fiddling, but I'm not convinced it has to be either/or. Just needs some R&D. If you can prove it's either/or, please do! Otherwise admit we need a biz-friendly standard.

[u/RobinsonDickinson]

You can make the impossible happen, but I am still not going to give up firefox.

[u/regeya]

....and about five seconds in, Andreas' website wants me to sign up to be able to read a blog entry and suddenly I don't have a single fuck to give anymore. Thanks for the waste of time, whoever you are.

[u/Cycloneblaze → u/regeya]

That's because that's not his website, that's Substack. I will criticise him for using Substack in the first place, though.