The current browser engine landscape is a monoculture, so this is a very welcome addition IMO.

But why would reusing something be better? Reusing someone else code wouldn't be competing with them, it'd be depending on them.

I'd rather encourage promising "dreams" than have a web with only 2.5 usable browser engines.

He is doing this for fun and to be creative, is incredibly inspiring for a lot of people, and actually gets things done on top.

The epitome of a hacker, I want to be more like him.

So he is in a good position to decide on the approach and has proven he can finish things. I’d just trust him on this, if my opinion was even relevant.

But as it’s a for fun project, he can write a browser in Fortran and abandon it half-way ;-)

Maybe Ladybird is not usable right away, so what? It's getting impressively close to this point with barely 5 years of development, from scratch (and it goes much deeper than HTML, CSS and JS engine, they also re-implemented the whole networking stack, image/audio/video codecs, font...) and by a small team of mostly volunteers, but more importantly, it's a positive project not only for the developers, but also for their audience and for greater scale web standardization.

I hardly imagine a project such as the one you're describing getting as much traction as Ladybird / SerenityOS (in fact, there are many such of these, but I don't see nearly as much talk and interest for their development), the whole project isn't about the end product, it's explicitly about the process to get there.

Realising dreams is called progress.

The reason Chrome and Firefox exist is because people dreamt of having something better than the already "usable" Internet Explorer.

Take for example the JavaScript engine. Spidermonkey and V8 are much more prominent in browser engines, even the lesser known ones, compared to JavaScriptCore. Spidermonkey for example is used in Firefox, Servo and Flow (Eikoh's browser engine), while V8 is used in every chrome derivate and most javascript implementations outside of a browser. JavaScriptCore is literally used in only one browser engine, and while WebKit is rather popular, it doesn't change the fact that the browser-grade javascript engine market is dominated by only two engines.

Rebilding everything from scratch is such a fresh breath of air from all of those technological monopolies. I only wish the best for the SerenityOS team and contributors.

Re-inventing the wheel is not the problem. It's copying the wheel that is the problem.

Like yeah, the idea is that the wheel already works pretty well, so you wouldn't need a better one, but really now? First of all, how would we know that we've explored all the possible ways wheels can be? How do we know whether what we have is actually the most optimal way that wheels can exist? You won't know unless you try! You might fail, but I'd say that the learning opportunity is worth it.

Also, when it comes to people who criticise projects like Ladybird here for "reinventing the wheel", I feel that comparing software to wheels is a bit disingenuous. Because while manufacturing wheels does take skillful craftsmanship and such, most software is probably just a tad more complex than just the wheel. Call it a hunch.

So, the ethos that one shouldn't "waste effort in writing this stuff from scratch, but that off-the-shelf components should be used" is the kind of ethos that can be applied to a lot of things. And usually when that kind of ethos is adopted, it tends to lead to stuff like stagnation and lack of innovation. And we know this, because we have examples of entire countries doing this, which has usually lead to either reforming away from this sort of model, or the country just not existing anymore.

We should not let the web for example stagnate due to browser monoculture. We should have alternative implementations of stuff, actually.

I think the advice still has its place, but only in certain contexts. You can get a lot of work done very quickly by making good use of work that others have already done for you. It's why modules and libraries are so popular.

When you've got the time to try and and improve on existing code, or when you'd have to compromise too much on what you want by using something preexisting, or when you're just learning then reinventing the wheel is invaluable.

There's a time and place for both.

https://awesomekling.substack.com/p/i-quit-my-job-to-focus-o...

Why write Servo from scratch instead of porting Blink/Webkit? One could at least use the HTML/CSS layout manager. Seems like a waste of effort.

> Will SerenityOS support $THING? > Maybe. Maybe not. There is no plan.

1. https://github.com/SerenityOS/serenity/blob/master/Documenta...

If you think you are "pro open web" but don't see the value in new browser engines (rather than just Safari, Firefox, and endless Chrome skins), then you're not actually "pro open web" you're pro status quo.

But also, you're completely missing that the whole point of serenityos was to do everything from scratch, and simply porting an existing engine like webkit (which Andreas is extremely familiar with) isn't an interesting task. Porting something like servo (that doesn't even benefit from significant web compatibility) is even more pointless.

At least building a new engine from scratch has the potential to introduce a new non-gecko, non-webkit derived browser, even if it takes a while (though despite the size of modern web specs, it's in many respects easier[1] than doing it 10 or 20 years ago).

[1] It's still not easy, but prior to the immense work from the major browser developers in the late 2000s and 2010s to actually make the specifications accurate and complete, you could not do what serenity/ladybird has been doing and just implement the spec. Firstly often times the spec simply did not exist, but then the W3C specs were largely incomplete, often times ambiguous, and frequently just did not match reality. Even TC39/ECMAScript, which was much more constrained, had absurd amounts of ambiguity and incompleteness. Nowadays, you can go to most specs and be fairly assured that if you implement the spec as written the behaviour will actually be correct (maybe inefficient or slow), and the difficulty is the much more tractable problem of there being more features to implement.

Also calling the project a "waste of effort" seems a bit out of touch. Effort doesn't have to pay off in any way to be worthwhile. If the act of building is part of the motivation then taking shortcuts at building it defeats the purpose.

To compete on the actual end user experience. Most users do not care at all about the code of the project. They don't care if your layout engine code is completely unique, they care that it does layout for the sites they use correctly. Having a good browser engine to work off of lets people start delivering value to users immediately instead of having to spend a ton of time recreating the parts of a browser that users do not care about.

Then there are raccoon digging through dumpsters for free code.

I find this mindset (why aren’t you working on something that benefits me, Bender) rather toxic.