As long as we're filling out our fantasy browser brackets, I'm hoping that the Servo engine and browser/s can become viable. Servo was started at Mozilla as a web rendering engine only, before they laid off the whole team and the Linux Foundation took over the project. Basically revived from the dead in 2023, the current project is working on an engine and a demonstration browser that uses it. It's years away from being a usable replacement for current browsers and the engine is certainly the main project. A separate browser which employs Servo as its engine is a more likely future than an actual Servo browser.
Still, you can download a demo build of the official browser from the web site. Currently, it's only usable for very simple web sites. Even Lemmy/Mbin display is a little broken, and I think of those as fairly basic. YouTube is out of the question. One of the sites that's been used to demonstrate its capability to render web pages is the web site for Space Jam (1996) if that gives you any idea of its current state.
Honest question, since I have no clue about web/browser engines other than being able to maybe name 4-5 of them (Ladybird, Servo, Webkit, Gecko, … shit, what was Chromium’s called again?):
What makes browsers/browser engines so difficult that they need millions upon millions of LOC?
Naively thinking, it’s “just” XML + CSS + JS, right? (Edit: and then the networking stack/hyperlinks)
So what am I missing? (Since I’m obviously either forgetting something and/or underestimating how difficult engines for the aforementioned three are to build…)
JavaScript alone is not a simple beast. It needs to be optimized to deal with modern JavaScript web apps so it needs JIT, it also needs sandboxing, and all of the standard web APIs it has to implement. All of this also needs to be robust. Browsers ingest the majority of what people see on the Internet and they have to handle every single edge case gracefully. Robust software is actually incredibly difficult and good error handling often adds a lot more code complexity. Security in a browser is also not easy, you're parsing a bunch of different untrusted HTML, CSS, and JavaScript. You're also executing untrusted code.
Then there is the monster that is CSS and layout. I can't imagine being the people that have to write code dealing with that it'd drive me crazy.
Then there are all of the image formats, HTML5 canvases, videos, PDFs, etc. These all have to be parsed safely and displayed correctly as well.
There is also the entire HTTP spec that I didn't even think to bring up. Yikes is that a monster too, you have to support all versions. Then there is all of that networking state and TLS + PKI.
There is likely so much that I'm still leaving out, like how all of this will also be cross platform and sometimes even cross architecture.
What makes implementation so difficult is that browsers cannot just "work", they need to be correct in what they do. And support all websites.
The standards of HTML, CSS and JS have developed over a long time, not only is the amount of stuff massive, over time sometimes strange features where implemented, that were then used by website developers, and now these all need to be handled correctly by all new browsers.
Emulating and reimplementing existing stuff is often more difficult, especially if you cannot leave out any feature, no matter how obscure, because that might break someone's website.
I'm never going to be one to dog on something before I try it. If it's good and can offer the same or better experience as Firefox then sign me up. The biggest sticking point for me, though, is potentially losing Firefox's massive add-in library. I really like my uBlock Origin and Restore YouTube Dislike and my VPN extension and Metamask and all the other crap I've got there.
Yes. Good filters and privacy/security are an absolutely vital requirement today. Unbreaking things and adding features via extensions or something are also good.
I don't understand why everyone wants to jump ship to a whole new browser, when the governance of a browser is the real issue to solve regardless of which browser is supported. A good stewardship model has to be established by people of integrity, technical skill, and funding. From there forking making a hard fork of Firefox is way cheaper and easier than trying to invest in one that's not even finished.
Okay, you do you. But it still doesn't make sense to try to rally everyone else behind a whole new unfinished browser, when an otherwise very good one just needs new leadership.
Not only C++ but also Swift, which just feels strange
Why build a new browser in C++ when safer and more modern languages are available?
Ladybird started as a component of the SerenityOS hobby project, which only allows C++. The choice of language was not so much a technical decision, but more one of personal convenience. Andreas was most comfortable with C++ when creating SerenityOS, and now we have almost half a million lines of modern C++ to maintain.
However, now that Ladybird has forked and become its own independent project, all constraints previously imposed by SerenityOS are no longer in effect.
We have evaluated a number of alternatives, and will begin incremental adoption of Swift as a successor language, once Swift version 6 is released.
Swift is a pretty fully fledged systems language at this point ... however, it's far from tried and tested for use cases like this and cross platform support is still garbage, so still a pretty questionable choice.
I’m OOTL. Are these actual issues people have with the project?
C++ might not be as memory-safe as Rust, but let’s not pretend a Rust code base wouldn’t be riddled with raw pointers.
BSD tells me the team probably wants Ladybird to become not just a standalone browser but also a new competing base for others to build a browser on top of – a Chromium competitor. Even though BSD wouldn’t force downstream projects to contribute back upstream, they probably would, since that’s far less resource-intensive than maintaining a fork. (Source: me, who works on proprietary software, can’t use GPL stuff, but contributes back to my open-source dependencies.)
I don't know if it's riddled with it or not, but what I (think to) know is that one of Rust's goal is to minimize them. No need for raw pointers when handling lists and buffers most of the time.
BSD tells me the team probably wants Ladybird to become not just a standalone browser but also a new competing base for others to build a browser on top of
Don’t have time to factcheck so going to take your word for it. Interesting bit of knowledge! Honestly wouldn’t have thought that. How else are Chrome, Edge, Brave, Arc, Vivaldi and co getting away with building proprietary layers on top of a copyleft dependency?
I’m no legal expert. All I know is that when I’m picking dependencies at work, if it’s copyleft, I leave it on the table. I love the spirit of GPL, but I don’t love the idea of failing an audit by potential investors because of avoidable liabilities.
If you cant tell from just looking at the relative successes of BSD and linux that copyleft licenses are better than I dont know how to convince you of anything
I don't like that "C++ isn't memory safe". It is. Users of that language are usually just not experienced or educated enough and therefore more mistakes happen.
I agree though, that other languages like Rust or Java can make it easier to prevent such mistakes.
In my experience, using smart pointers alone already solves 90% of memory issues I have to deal with. C++ improved a lot in that regard over the decades.
I agree that experienced users can write code that leaks less than in C, leaving aside the bottomless pit of despair that is undefined behaviour. But the the language isn't memory safe, it doesn't even prevent you from returning a reference to a local or helpnwitg iterator invalidation. you don't have to jump through any hoops to enable making that mistake.
I'm very experienced with C++and I still feel like I'm juggling chainsaws every time I use it. And I've personally run into into things like use after free errors while working in Chromium. It's a massive codebase full of multithreading, callbacks, and nonlocal effects. Managing memory may be easy in a simple codebase but it's a nightmare in Chromium. Tools like AddressSanitizer are a routine part of Chrome development for exactly that reason. And people who think memory management is easy in C++ are precisely the people I expect to introduce a lot of bugs.
with mandatory male pronouns for users in the documentation.
(and no politics allowed!)
note
this issue was resolved eventually by another dev; afaik the lead dev stopped commenting on it after he closed a PR and said people who wanted to remove the docs' implied assumption of users' maleness were "advertising personal politics".
edit: ok, i went and checked, here are the details:
This whole situation was a concern for me too, but with Ladybird being spun off into its own not for profit, these kind of things are much less likely to occur again going forward. The project is a lot more focused now.
Basically, it allows you to steal all the code and use it in your closed-source programs, giving a green light for corporations to use open-source code without giving anything back.
GPL doesn't allow that, forcing you to open-source anything that was produced using other GPL-licensed code. That's, for example, why so much of Linux software is open-source - it commonly relies on various dependencies that are GPL-licensed, so there is no other legal option other than sharing the code as well.
Apple, Sony, N*****do, Netflix all use BSD but they don't contribute any code to the BSD project itself, because of the BSD allow other people/company to close source their code when using with BSD
It's not a viral copyleft license, so you're free to use the source code without giving anything back.
This has pros and cons over something like GPL, but people like to circlejerk GPL and pretend it's always the best option 100% of the time.
For situations where you have to sign an NDA and are unable to release source code (eg; console game dev), MIT and BSD licensed projects are a godsend.
MIT/BSD also makes the most sense for small/minimal projects where GPL is likely overkill. A 100 line script does not need to be GPL'ed. A small static website does not need to be GPL'ed.
It's not really an issue for the end user. But it's basically made for companies to take advantage of free hobbyist developers without needing to give anything back in return.
So if you're the kind of person who runs to foss software to get away from corporate tech bull, having a license that benefits companies more than users just kinda feels scummy.
It's a monumental effort really, building a browser engine from scratch and taking it to daily driver usable is probably among the most difficult programming challenges. It's way easier to build a new Linux kernel from scratch than a browser engine lmao
Even Microshit tried and gave up because it was so hard
Good interview with the Dev for anyone who is interested in more of the details from this thread, like why Swift? What's so hard about browsers? Etc. https://youtu.be/z1Eq0xlVs3g
Is it that difficult to implement a CopyLeft licence ?
Well we do have Servo (A modular browser engine) in development & SeaMonkey is a thing too (Which is an entire internet-application suite)
That's false. Derivative software that doesn't use the BSD licence has no bearing on the BSD-licenced software itself. For example, Sony using FreeBSD for the PS3 operating system has zero impact on the freedom of a FreeBSD user. The GPL, on the other hand, directly infringes on the user's freedom to fork and redistribute the software.
Copyleft protects the freedom of the user, regardless of who is the developer, I think that is way more important if what we want is to make software for humanity rather than pragmatic business choices.
It is a point of what you regard as real freedom, do you wish to eventually lock in your users or let who might fork/take over your project do that?