We're working on integrating with Swift, but despite the team's earnest efforts, Swift/C++ interop is still young and unstable.

On a personal note, I'm increasingly feeling like "C++ with a garbage collector" might actually be a reasonable tool for the task at hand. Watching the development of Fil-C in this space..

The Ladybird codebase is generally very defensive, but like every browser, our JavaScript engine is slightly less so (in the pursuit of performance.)

There are architectural lessons to learn here beyond just fixing the bugs found. We've since replaced these allocations (+ related ones) with callee-specific stack memory instead of trying to be clever with heap allocation reuse.

We're also migrating more and more of our memory management to garbage collection, which sidesteps a lot of the traditional C++ memory issues.

As others have mentioned, sandboxing & site isolation will make renderer exploitation a lot less powerful than what's demonstrated here. Even so, we obviously want to avoid it as much as possible!

Comments URL: https://news.ycombinator.com/item?id=43159541

Points: 5

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=41863713

Points: 15

# Comments: 1

(Hi Pavel, love the book!)

Comments URL: https://news.ycombinator.com/item?id=41530144

Points: 6

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=41112296

Points: 3

# Comments: 0

We are definitely a stripped down operation, and we will spend as much of our funding as possible on engineer salaries for the foreseeable future.

The best for a beginner is usually to start with some simple page you made yourself, since you know how it’s supposed to work, and can debug more easily.

And come join us on Discord, there are new people getting into the codebase all the time :)

I wish distros would not package pre-alpha software, since the only thing it accomplishes is giving people a bad first impression of something that isn't ready :(

If you want to mess with Ladybird, build it from the source at https://github.com/LadybirdBrowser/ladybird :)

Given the limitations of our funding model, we won't be building a huge team, but rather a small team that allows us to maintain a runway of at least 1.5 years. :)

At the moment, we are focusing primarily on our own use cases as developers, since those are the easiest to test and qualify. So websites like GitHub, web specifications, MDN, etc. are likely going to be very high fidelity before other parts of the web catch up ;)

> Also, do you already have any plans or ideas for how to improve the web browsing experience beyond what existing browsers provide or is your focus entirely on the engine catching up for now?

We are definitely focused on the engine catching up right now. There is an incredible amount of work to do, and we're doing the best we can :)

We benefit greatly from this of course, and we will do what we can to contribute when we’re mature enough!

That said, there will always be websites relying on bugs, and for that we will need a way to selectively emulate alternate behaviors in some cases. We are looking at a few different solutions for this but it’s not a huge priority right now as there are far lower hanging fruit in front of us.

Going forward, we want to support the open web as it exists, so you can actually use Ladybird to interact with all your websites. We may not agree that every web platform API is awesome and perfect, but we will honor the open standards to the best of our ability.