7 ms·

It's been so inspiring to see him and his crew of hackers build a new, independent browser from scratch. I must admit I didn't think it was possible on this sma

by jug 3y ago

It's been so inspiring to see him and his crew of hackers build a new, independent browser from scratch. I must admit I didn't think it was possible on this small scale in terms of man hours and funding. However, the thought has also crossed my mind if we're finally seeing fruits of browsers being better standardized on "95%"+ of the popular features -- and if writing a browser today is in fact easier than both writing AND maintaining a browser a decade back. While the web is of course still evolving, it feels more "settled in" than 10-15 years ago. There's also the factor that past developers didn't have the more complete roadmap set when they initially planned browser design, but now we have huge amounts of web standards already there AND also know how popular they got over time i.e. what to prioritize to support a modern web. One might superficially think there's simply more of everything, but I also think ideas that can be discarded. Just imagine that Internet Explorer had XSLT support, and FTP was common once upon a time! It would be interesting to hear more about their own thoughts on these topics! Edit: My bad; XSLT is still commonly supported and by all major browsers but a rarely used feature and stuck in limbo in XSLT 1.0. So it's probably among those things that can be safely omitted for quite some time.

nox101 3y ago
It also helps that there are tests https://web-platform-tests.org/ https://web-platform-tests.org/
- LeFantome 3y ago
  Indeed. These may be even more important... https://github.com/tc39/test262 https://github.com/tc39/test262
rjh29 3y ago
> if writing a browser today is in fact easier than both writing AND maintaining a browser a decade back. Probably not. Yeah we have web standards and some idea of how to architect it, but the total set of APIs and HTML/CSS features a browser supports is probably changing faster than the Ladybird team can actively implement it. The API surface is just impossibly large compared to 10 or 15 years ago. Look at all of these: https://developer.mozilla.org/en-US/docs/Web/API https://developer.mozilla.org/en-US/docs/Web/API And that doesn't include the updates to Javascript, MathML, SVG, HTTP-based security features, encryption or media support.
- jillesvangurp 3y ago
  It's a lot of work but most of it is very doable for several reasons: - standards are really detailed at this point and a large reason why the three remaining browser engines (chromium, safari, and firefox) largely do exactly the same things. - There are a lot of open source components. It's not necessary to start from scratch on things like wasm and javascript interpreters for example. There are some nice low level graphics libraries out there as well. And of course things like Rust are now pretty mature and there's a lot of rust code out there that does stuff that a browser would need. That being said, it's one hell of a hobby project to take on and I don't see much economical value in an independent implementation of something provided by free by three independent browsers already; two of which are open source. Which begs the question: why?!? Is there qualitative argument here of doing the exact same thing but somehow better?
  - rjh29 3y ago
    In the case of Ladybird they build everything from scratch (intentionally) so existing open source code cannot be used. The main argument for doing it is because it is fun, just as with SerenityOS. Having alternative implementations is never a bad thing for web diversity though.
    - shiroiuma 3y ago
      Of course, alternatives are almost never a bad thing, and devs should feel free to work on whatever floats their boat when they're volunteers, but developer resources are scarce, and there are other things in the FOSS realm that could use some attention where there really aren't great alternatives. But again, if these people prefer to work on this, that's OK. Just because the world could use a better X doesn't mean these devs have enough interest in X to be effective at building such a thing in a volunteer capacity: in my experience, having personal interest in a project makes you much more productive than working on something you really don't care about.
- jefozabuss 3y ago
  Not to mention the number of possible vulnerabilities that will be needed to be pentested and fixed.
sph 3y ago
It is not any easier, because we still have a monopoly running the show, only it's not called Microsoft anymore. If anyone threatens Google position, they can literally throw money at the problem, invent some overcomplicated standard, implement it in Blink, and have the competition chase them. It doesn't need to go through W3C either, if it works in Chrome, all web developers will adopt it and any smaller engine will necessarily have to support it or risk losing whatever little market share they have left. Having control of the internet now is of greater strategic importance than it was 20-30 years ago when Microsoft was king of the hill.
- pygy_ 3y ago
  This is where Apple'grip on the iOS browser engine choice paradoxically comes in clutch. It is conceptually despicable, especially for devs, but it prevents Google from completely running the show. Now the European Union is coming after Apple without trying to rein in Google's influence... This seems short-sighted.
  - Hrun0 3y ago
    The current dispute between the EU and Apple has nothing to do with Safari though and is about the Apple store, not sure how that's relevant?
    - pygy_ 3y ago
      It is my understanding that Apple losing here would prevent them from enforcing WebKit as the sole iOS browser engine. I may be mistaken.
    - naraic0o 3y ago
      no, they're also forcing Apple to allow other browser engines on iOS, which was previously banned. other, third party iOS browsers still used the safari webkit engine. > In addition, apps that use alternative browser engines — other than Apple’s WebKit — may negatively affect the user experience, including impacts to system performance and battery life. https://www.apple.com/newsroom/2024/01/apple-announces-changes-to-ios-safari-and-the-app-store-in-the-european-union/ https://www.apple.com/newsroom/2024/01/apple-announces-chang...
autoexec 3y ago
> if we're finally seeing fruits of browsers being better standardized on "95%"+ of the popular features -- and if writing a browser today is in fact easier than both writing AND maintaining a browser a decade back. A decade back, maybe... but decades ago the number of things you had to support was just so much smaller even if you only looked at HTML! Consider https://www.ietf.org/rfc/rfc1866.txt https://www.ietf.org/rfc/rfc1866.txt vs https://html.spec.whatwg.org/multipage/ https://html.spec.whatwg.org/multipage/ Writing a web browser was hard in the old days for a lot of reasons, but trying to write a full-featured one today is a huge undertaking and we're still adding a bunch of new features all the time and expecting browsers to support them
- Aeolun 3y ago
  > Consider https://www.ietf.org/rfc/rfc1866.txt https://www.ietf.org/rfc/rfc1866.txt vs https://html.spec.whatwg.org/multipage/ https://html.spec.whatwg.org/multipage/ I thought, oh, that's not so bad. Then I realized what I was looking at was a 10 page index.
awesomekling 3y ago
> It's been so inspiring to see him and his crew of hackers build a new, independent browser from scratch. I must admit I didn't think it was possible on this small scale in terms of man hours and funding. Thanks jug! I'm super proud of all the folks who have worked on it with me :^) > However, the thought has also crossed my mind if we're finally seeing fruits of browsers being better standardized on "95%"+ of the popular features -- and if writing a browser today is in fact easier than both writing AND maintaining a browser a decade back. While the web is of course still evolving, it feels more "settled in" than 10-15 years ago This is definitely true! I've worked on browsers on and off since 2006, and it's a very different landscape today. Specs are better than ever and there's a treasure trove of tests available.
chrisweekly 3y ago
The web as a platform keeps getting better. As someone who's been developing for it for a living since 1998, I'm delighted to see and to share things like "Interop 2024"^1 and Web Platform Tests ^2, which are improving the adoption pace and reliability of key platform features: 1. https://www.webkit.org/blog/14633/get-ready-for-interop-2024/ https://www.webkit.org/blog/14633/get-ready-for-interop-2024... 2. https://wpt.fyi https://wpt.fyi
grishka 3y ago
IMO most of the complexity of modern browsers is in all those strictly optional, app-like features. PWAs, service workers, JS JIT and all that stuff. If you want to build just a hypertext viewer, not a full-fledged OS/application environment, just leave them out and nothing of value will break. Things also become substantially simpler if you aren't looking to make your JS execution as performant as theoretically possible (and you don't really need to with how most websites actually use JS).
_heimdall 3y ago
It would be a bummer IMO to see XSLT abandoned. Its still a really interesting approach to the web and an alternative to today's JS-heavy client rendering. The idea of being able to ship an XML template with basic logic like for loops alongside the actual XML data source is really unique today. If people cared to use XML at all, that really does cover quite a few use cases that we current reach for JSON + client JS today.

by jug 3y ago

nox101 3y ago

It also helps that there are tests https://web-platform-tests.org/ https://web-platform-tests.org/

LeFantome 3y ago
Indeed. These may be even more important... https://github.com/tc39/test262 https://github.com/tc39/test262

rjh29 3y ago

> if writing a browser today is in fact easier than both writing AND maintaining a browser a decade back. Probably not. Yeah we have web standards and some idea of how to architect it, but the total set of APIs and HTML/CSS features a browser supports is probably changing faster than the Ladybird team can actively implement it. The API surface is just impossibly large compared to 10 or 15 years ago. Look at all of these: https://developer.mozilla.org/en-US/docs/Web/API https://developer.mozilla.org/en-US/docs/Web/API And that doesn't include the updates to Javascript, MathML, SVG, HTTP-based security features, encryption or media support.

jillesvangurp 3y ago
It's a lot of work but most of it is very doable for several reasons: - standards are really detailed at this point and a large reason why the three remaining browser engines (chromium, safari, and firefox) largely do exactly the same things. - There are a lot of open source components. It's not necessary to start from scratch on things like wasm and javascript interpreters for example. There are some nice low level graphics libraries out there as well. And of course things like Rust are now pretty mature and there's a lot of rust code out there that does stuff that a browser would need. That being said, it's one hell of a hobby project to take on and I don't see much economical value in an independent implementation of something provided by free by three independent browsers already; two of which are open source. Which begs the question: why?!? Is there qualitative argument here of doing the exact same thing but somehow better?
- rjh29 3y ago
  In the case of Ladybird they build everything from scratch (intentionally) so existing open source code cannot be used. The main argument for doing it is because it is fun, just as with SerenityOS. Having alternative implementations is never a bad thing for web diversity though.
  - shiroiuma 3y ago
    Of course, alternatives are almost never a bad thing, and devs should feel free to work on whatever floats their boat when they're volunteers, but developer resources are scarce, and there are other things in the FOSS realm that could use some attention where there really aren't great alternatives. But again, if these people prefer to work on this, that's OK. Just because the world could use a better X doesn't mean these devs have enough interest in X to be effective at building such a thing in a volunteer capacity: in my experience, having personal interest in a project makes you much more productive than working on something you really don't care about.
jefozabuss 3y ago
Not to mention the number of possible vulnerabilities that will be needed to be pentested and fixed.

sph 3y ago

It is not any easier, because we still have a monopoly running the show, only it's not called Microsoft anymore. If anyone threatens Google position, they can literally throw money at the problem, invent some overcomplicated standard, implement it in Blink, and have the competition chase them. It doesn't need to go through W3C either, if it works in Chrome, all web developers will adopt it and any smaller engine will necessarily have to support it or risk losing whatever little market share they have left. Having control of the internet now is of greater strategic importance than it was 20-30 years ago when Microsoft was king of the hill.

pygy_ 3y ago
This is where Apple'grip on the iOS browser engine choice paradoxically comes in clutch. It is conceptually despicable, especially for devs, but it prevents Google from completely running the show. Now the European Union is coming after Apple without trying to rein in Google's influence... This seems short-sighted.
- Hrun0 3y ago
  The current dispute between the EU and Apple has nothing to do with Safari though and is about the Apple store, not sure how that's relevant?
  - pygy_ 3y ago
    It is my understanding that Apple losing here would prevent them from enforcing WebKit as the sole iOS browser engine. I may be mistaken.
  - naraic0o 3y ago
    no, they're also forcing Apple to allow other browser engines on iOS, which was previously banned. other, third party iOS browsers still used the safari webkit engine. > In addition, apps that use alternative browser engines — other than Apple’s WebKit — may negatively affect the user experience, including impacts to system performance and battery life. https://www.apple.com/newsroom/2024/01/apple-announces-changes-to-ios-safari-and-the-app-store-in-the-european-union/ https://www.apple.com/newsroom/2024/01/apple-announces-chang...

autoexec 3y ago

> if we're finally seeing fruits of browsers being better standardized on "95%"+ of the popular features -- and if writing a browser today is in fact easier than both writing AND maintaining a browser a decade back. A decade back, maybe... but decades ago the number of things you had to support was just so much smaller even if you only looked at HTML! Consider https://www.ietf.org/rfc/rfc1866.txt https://www.ietf.org/rfc/rfc1866.txt vs https://html.spec.whatwg.org/multipage/ https://html.spec.whatwg.org/multipage/ Writing a web browser was hard in the old days for a lot of reasons, but trying to write a full-featured one today is a huge undertaking and we're still adding a bunch of new features all the time and expecting browsers to support them

Aeolun 3y ago
> Consider https://www.ietf.org/rfc/rfc1866.txt https://www.ietf.org/rfc/rfc1866.txt vs https://html.spec.whatwg.org/multipage/ https://html.spec.whatwg.org/multipage/ I thought, oh, that's not so bad. Then I realized what I was looking at was a 10 page index.

awesomekling 3y ago

> It's been so inspiring to see him and his crew of hackers build a new, independent browser from scratch. I must admit I didn't think it was possible on this small scale in terms of man hours and funding. Thanks jug! I'm super proud of all the folks who have worked on it with me :^) > However, the thought has also crossed my mind if we're finally seeing fruits of browsers being better standardized on "95%"+ of the popular features -- and if writing a browser today is in fact easier than both writing AND maintaining a browser a decade back. While the web is of course still evolving, it feels more "settled in" than 10-15 years ago This is definitely true! I've worked on browsers on and off since 2006, and it's a very different landscape today. Specs are better than ever and there's a treasure trove of tests available.

chrisweekly 3y ago

The web as a platform keeps getting better. As someone who's been developing for it for a living since 1998, I'm delighted to see and to share things like "Interop 2024"^1 and Web Platform Tests ^2, which are improving the adoption pace and reliability of key platform features: 1. https://www.webkit.org/blog/14633/get-ready-for-interop-2024/ https://www.webkit.org/blog/14633/get-ready-for-interop-2024... 2. https://wpt.fyi https://wpt.fyi

grishka 3y ago

IMO most of the complexity of modern browsers is in all those strictly optional, app-like features. PWAs, service workers, JS JIT and all that stuff. If you want to build just a hypertext viewer, not a full-fledged OS/application environment, just leave them out and nothing of value will break. Things also become substantially simpler if you aren't looking to make your JS execution as performant as theoretically possible (and you don't really need to with how most websites actually use JS).

_heimdall 3y ago

It would be a bummer IMO to see XSLT abandoned. Its still a really interesting approach to the web and an alternative to today's JS-heavy client rendering. The idea of being able to ship an XML template with basic logic like for loops alongside the actual XML data source is really unique today. If people cared to use XML at all, that really does cover quite a few use cases that we current reach for JSON + client JS today.