akling

> 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.

Great read! This reminds me of a macOS app I made for my wife a few years back. It keeps track of the opening hours of all her favorite shops, and she can click a menu bar icon to see how long until each one closes today. It also warns if it's currently peak/rush hour for the shop, since she prefers to go when it's less crowded.

It's a simple Qt app that uses a text file for data storage. I wrote it after noticing that she had trouble remembering which shops are open when. I asked her what to call it, and she said "Gladiolus, like the flower" so I named it Gladiolus.

I can say for sure I've never had a more appreciative client as a programmer than the one user of Gladiolus :^)

Go for it OP, the more browsers the merrier! :^)

There’s a fun documentary that follows some folks inside Netscape during the rush to make Mozilla open source: https://youtu.be/4Q7FTjhvZ7Y

It depends on what you enjoy doing, and how much time you really have.

Good bug reports & reduced test cases are always amazingly valuable. Perhaps you have a home page of your own? You can open it in Ladybird and see if you hit some problems. Maybe we throw a surprising JavaScript exception. Maybe our CSS layout isn't quite right.

If you can then reduce the problem to a minimal HTML/CSS/JS example, that's often enough for someone working on the engine to go ahead and find a fix pretty easily. :)

Indeed! Mike has been really helpful :)

I've been broadcasting my programming sessions on YouTube since 2019. I have over 1000 videos here: https://www.youtube.com/@awesomekling

Over time, my audience grew, and some people really liked my videos, so I first made a Patreon and later a GitHub Sponsors for those who wanted to help me turn it into a full-time job someday.

Thanks to growing support, I was eventually able to make it a full-time job. For more details on this journey, I wrote about it here: https://awesomekling.substack.com/p/i-quit-my-job-to-focus-o...

Tobi (Shopify CEO) has been supporting my open source work via GitHub Sponsors since early 2022, so I reached out to him and said (very paraphrased) "I'm gonna start pushing harder on Ladybird, would Shopify want to be an official sponsor?"

I first spoke with Tobi about this in mid-May, so it's been in the works for a while longer. :)

That was a separate sponsor! This month has been weird, to say the least :)

Memory safety is absolutely on the long-term roadmap for Ladybird. But Jakt still needs time to mature before making it a dependency :)

It currently runs on SerenityOS, Linux and macOS. And Windows with WSL (I know, I know..)

We’ve also seen screenshots of Ladybird on FreeBSD, Haiku, and even Android at one point. Those are not maintained though, but we’ll come back to them eventually I’m sure :)

Thank you!

Indeed, all of these large sponsorships so far have been specifically for Ladybird development.

That’s also what I’ve been personally focusing on for many months already, so nothing really changes about my day-to-day.

The main new thing this enables is hiring more full-time engineers to work on the browser. (Still have details to figure out here though!)

That said, keep in mind that 99% of work on Ladybird also improves SerenityOS, since they are part of the same mega-project. :)

Hello friends! I’m really happy to have Shopify putting their faith in our little project like this :)

If you’d like a quick intro to the Ladybird project, I presented it at a conference earlier this month: https://youtu.be/De8N1zrQwRs

Huge thanks to Mike, Tobi and the other folks at Shopify who hooked this up. <3

Thank you! The sponsor has asked to remain anonymous for now. There are no strings attached, although we do stay in touch. :)

Hello friends! I am very excited about this indeed :)

If you’d like to know more about Ladybird, I did a presentation about it at the Web Engines Hackfest in Spain just two weeks ago: https://youtu.be/De8N1zrQwRs

We're building a new web browser (with a new engine) from scratch.

I believe the industry is heading down a dark path with even big companies like Microsoft and Opera hiding behind Chromium instead of continuing to develop their own engines. IMO we need more independent implementations of the web platform to ensure that it remains open and healthy.

Re: too ambitious, it's a commonly held belief that building browsers is impossible without a huge budget and hundreds of staff. We're doing it anyway, it just takes time. :)

Love the spirit of this, and really curious to see what comes of it!

I applied for a grant once but never heard back. My goals may be too ambitious for some though, so no hard feelings :^)

Because now you're holding a reference to `x` which is supposed to be protected by a mutex, even after the mutex is unlocked.

With the lambda-only API, it's much harder to make this mistake, since a temporary reference like this will still go out of scope at the end of the lambda expression.

After sketching this out, it's nice that this:

    auto x = state.with([](auto& state) { return state.x; });

Becomes this:

    auto x = state.locked()->x;

But it also creates this very accessible footgun:

    auto& x = state.locked()->x;

Where it's way too easy to bind a reference to something that should be protected by the lock, but now isn't. So I'm not sure this is a great idea anymore.

AFAIK if you use a templated type for the callback (as you should), it will be inlined by modern compilers at any optimization level other than -O0. :)

Yes, that's a great way to improve the ergonomics of MutexProtected in simple cases! We should totally add that as a complement to the lambda API. :)