I think adoption and maintenance will be the hardest parts of the project.
I'll switch from FF as soon as it's usable for my moderate needs.
We're building a browser when it's supposed to be impossible
71–80 of 349 posts
Re: We're building a browser when it's supposed to be impossible
#72> So instead of [building the browser one feature/spec at a time], we tend to focus on building “vertical slices” of functionality. This means setting practical, cross-cutting goals, such as “let’s get twitter.com/awesomekling to load”, “let’s get login working on discord.com”, and other similar objectives. Seems similar to how Wine is developed: instead of just going down the list of API functions to implement, the…
This approach works better for Wine where the Windows binaries are a fixed target. On the web, you may get Twitter's feed rendering acceptably, and then two days later they ship an insignificant redesign that happens to use sixteen CSS features you don't have and everything is totally broken again.
Depends on if your actual goal was getting twitter to work.
If Twitter rendered fine, chances are some other site render fine today. The same it was with Wine.
Re: We're building a browser when it's supposed to be impossible
#73I'm finding it weird that unlike other non-trivial projects like OSes or compilers, people often discourage building web browser engine because it is "hard" or something like that like... how is it different from building a compiler? You gotta build HTML parser, CSS parser, figure out a fancy structure to represent those concepts and modify at fly. Also there's difference between making it work and making state of th…
The main reason it's difficult is because the output criteria seem properly defined but they actually aren't at all. Yeah it's "just" building some parsers and figuring out live updates, but you have to keep in mind that this is ~the internet~. People have been uploading broken, against spec, webpages since forever. Coding a web browser as a serious project (so not as a flight of fancy) borders on the impossible most…
Last time I looked at, Widevine was not blocking the implementation of the other parts of a web browser stack.
Re: We're building a browser when it's supposed to be impossible
#74Chrome wasn't built in a day.
Tha fall of Chrome.
Re: We're building a browser when it's supposed to be impossible
#75Others have already mentioned performance is one of the hard part. Another aspect is that for any complex, large-scale project like browser, lots of, if not most of, effort is actually in the long tail: to make 90% or even 99% websites work probably is as hard as making the rest 1%. So while the team probably could cruise through when working on current gen spec and popular sites like Discord/Twitter, it's what left…
Is this something you know from experience or are you armchair guessing? If I recall correctly, the work Andreas did at Apple was mostly focused on performance, and Safari has long had a reputation for excellent performance. Maybe you’ve also done that type of work, but otherwise I’ll trust his judgement.
My experience with big projects would confirm this. Getting the basic things implemented is quite fast, but the devil is in the details and they can drag on for years, if you didn't account for all of them in the beginning.
And there are a hell lot of details with the plattform called the web.
But I would think in this case here, they have no intention of going to 100% by all means, to support all the broken pieces of web garbage out there. The goal is to implement the W3C specs. (they are even working on fixing the specs)
Oh and Kling specifically worked on browsers before, so that is a good base.
"I've had the opportunity to work on production browsers for many years (at Apple and Nokia)"
Re: We're building a browser when it's supposed to be impossible
#76Earlier quoted context omitted.
More specifically, Chrome used Safari's rendering engine, and Safari used Konqueror's rendering engine, because even in 2001, starting a browser engine from scratch seemed like too much work.
I would say that in 2001, starting a browser engine from scratch was more work than today, because (as other commenters have noted) since then the specifications have become more robust and the "tag soup" sites not following the specs have become fewer.
Moreover, tools are better too. Even if one is still using only vim on the terminal, plugins work better, screens are bigger, code compiles faster, and the internet has better resources for everything from programming and communicating with your team, to just finding music that helps you stay productive, for example.
Re: We're building a browser when it's supposed to be impossible
#77> So instead of [building the browser one feature/spec at a time], we tend to focus on building “vertical slices” of functionality. This means setting practical, cross-cutting goals, such as “let’s get twitter.com/awesomekling to load”, “let’s get login working on discord.com”, and other similar objectives. Seems similar to how Wine is developed: instead of just going down the list of API functions to implement, the…
This approach works better for Wine where the Windows binaries are a fixed target. On the web, you may get Twitter's feed rendering acceptably, and then two days later they ship an insignificant redesign that happens to use sixteen CSS features you don't have and everything is totally broken again.
You can then just set the same goal again. I don't see the problem.
Re: We're building a browser when it's supposed to be impossible
#78Earlier quoted context omitted.
Firefox has tons and tons of C++ to this day.
Yes, but they are replacing it bit by bit - I mean, they even started Rust for exactly that purpose. So (without being a huge fan of Rust) the decision to start a "greenfield" browser project in a memory-unsafe language is questionable IMHO...
It's not clear to me that they are replacing it bit-by-bit.
https://4e6.github.io/firefox-lang-stats/
I don't have an over-time series, but if you're willing to take my memory at its word Rust's percentage has hovered at around 10% for a while now. It seems to have actually gone down recently. Combine that with efforts like Servo being wound down and their team being let go, and it makes me wonder what the future of Rust looks like in Firefox.
If anyone can shed some light on this I'd be interesting to know.
Re: We're building a browser when it's supposed to be impossible
#79The fact there are better specs doesn’t help if a large part of the work is handling things that are outside the spec. You better show every “buggy” page similar to how the major browsers show them or the new browser will be considered defective. That’s the unfortunate reality of web tech (I wish every page with an js error or incorrectky closed tag would be a big fat error message but it isn’t). And that’s still a l…
All this "quirks mode" stuff is part of the specification, no? It makes it all a bit more complex than it has to be, but I do believe it's specified. I'm not really sure if "you need to be bug-compatible" is still true; it probably was 15 years ago, but Chrome, Firefox, and WebKit tend to be pretty decent these days.
Quitks mode is one thing, but most browsers have specific rules for specific websites, a manual process to update and handle those cases. Pretty sure chrome and safari have hundreds of these rules.
Re: We're building a browser when it's supposed to be impossible
#80Earlier quoted context omitted.
All this "quirks mode" stuff is part of the specification, no? It makes it all a bit more complex than it has to be, but I do believe it's specified. I'm not really sure if "you need to be bug-compatible" is still true; it probably was 15 years ago, but Chrome, Firefox, and WebKit tend to be pretty decent these days.
Quitks mode is one thing, but most browsers have specific rules for specific websites, a manual process to update and handle those cases. Pretty sure chrome and safari have hundreds of these rules.
Do you have any references? I'd be interested to see the list and what workarounds are needed