curl.md

curl --request POST \
  --url https://api.firecrawl.dev/v0/scrape \
  --header 'Authorization: Bearer fc-xxx' \
  --header 'Content-Type: application/json' \
  --data '{
	"url": "https://lwn.net/Articles/976822/",
	"pageOptions": {
		"includeHtml": true,
		"onlyMainContent": false
	}
}'

response.json

{
	"success": true,
	"data": {
		"content": " [![LWN.net Logo](https://static.lwn.net/images/logo/barepenguin-70.png) LWN  \\\n.net News from the source](/)\n [![LWN](https://static.lwn.net/images/lcorner-ss.png)](/)\n\n*   [**Content**](#t)\n    *   [Weekly Edition](/current/)\n        \n    *   [Archives](/Archives/)\n        \n    *   [Search](/Search/)\n        \n    *   [Kernel](/Kernel/)\n        \n    *   [Security](/Security/)\n        \n    *   [Events calendar](/Calendar/)\n        \n    *   [Unread comments](/Comments/unread)\n        \n    *   * * *\n        \n    *   [LWN FAQ](/op/FAQ.lwn)\n        \n    *   [Write for us](/op/AuthorGuide.lwn)\n        \n*   [**Edition**](#t)\n    *   [Return to the Front page](/Articles/977366/)\n        \n\n**User:**  **Password:**   \n\n|\n\n|\n\n[**Subscribe**](/subscribe/)\n / [**Log in**](/Login/)\n / [**New account**](/Login/newaccount)\n\nLadybird browser spreads its wings\n==================================\n\n**This article brought to you by LWN subscribers**\n\nSubscribers to LWN.net made this article — and everything that surrounds it — possible. If you appreciate our content, please [buy a subscription](/subscribe/)\n and make the next set of articles possible.\n\nBy **Joe Brockmeier**  \nJune 7, 2024\n\n[Ladybird](https://ladybird.dev/)\n is an open-source project aimed at building an independent web browser, rather than yet another browser based on Chrome. It is written in C++ and licensed under a two-clause BSD license. The effort began as part of the [SerenityOS](https://www.serenityos.org/)\n project, but developer Andreas Kling [announced](https://awesomekling.substack.com/p/forking-ladybird-and-stepping-down-serenityos)\n on June 3 that he was \"forking\" Ladybird as a separate project and stepping away from SerenityOS to focus his attention on the browser completely. Ladybird is not ready to replace Firefox or Chrome for regular use, but it is showing great promise.\n\nKling started working on SerenityOS in 2018 as a therapy project after completing a substance-abuse rehabilitation program. The SerenityOS name is a nod to the [serenity prayer](https://en.wikipedia.org/wiki/Serenity_Prayer)\n. Prior to working on the project, he had worked on WebKit-based browsers at Apple and Nokia. Eventually he [made SerenityOS his full-time job](https://awesomekling.github.io/I-quit-my-job-to-focus-on-SerenityOS-full-time/)\n, and funded the work through donations, sales of SerenityOS merchandise, and income from YouTube. (Kling posts monthly updates to his [YouTube channel](https://www.youtube.com/@awesomekling/videos)\n about Ladybird, as well as hacking videos where he walks through working on various components in the browser, such as the [JavaScript JIT compiler](https://www.youtube.com/watch?v=8mxubNQC5O8)\n.)\n\n#### Taking flight\n\nKling [announced](https://awesomekling.substack.com/p/ladybird-a-new-cross-platform-browser-project)\n the Ladybird project in September 2022. He said that the project started while creating a Qt GUI for SerenityOS's LibWeb browser engine. He decided to target Linux as well as SerenityOS so it would be easier for people to work on and debug while in Linux. In the post announcing his intent to work solely on Ladybird, he noted that he had been focusing all of his attention on the Linux version of Ladybird. With that realization, he decided to step down as \"benevolent dictator for life\" (BDFL) of SerenityOS so its development would not be held back:\n\n> Before anyone asks, there is no drama behind this change. It's simply recognizing that there have been two big projects packed uncomfortably into a single space for too long, and I'm doing what I believe will make life better for everyone involved.\n\nLadybird's governance is similar to SerenityOS. Kling is the BDFL, with a group of maintainers (currently ten) who can approve and merge pull requests. The [contributing](https://github.com/LadybirdWebBrowser/ladybird/blob/master/CONTRIBUTING.md)\n guide notes that maintainership is \"by invitation only and does not correlate with any particular metric\". Project development discussions are held on a [Discord server](https://discord.com/invite/nvfjVJ4Svh)\n (account required).\n\nNow independent, Ladybird has dropped SerenityOS as a development target, and has moved to [its own GitHub repository](https://github.com/LadybirdWebBrowser/ladybird)\n. In addition, Kling has relaxed his self-imposed policy of excluding \"not invented here\" (NIH) code that had applied to SerenityOS, which means that the Ladybird project will be able to make use of existing libraries rather than writing from scratch.\n\nComparing the [README](https://github.com/LadybirdWebBrowser/ladybird/blob/master/README.md)\n file in the standalone Ladybird repository against the [README](https://github.com/SerenityOS/serenity/blob/master/Ladybird/README.md)\n file in the SerenityOS repository, the goal has evolved from creating \"a standards-compliant, independent web browser with no third-party dependencies\" to developing an independent browser \"using a novel engine based on web standards\".\n\nThe changes to the section that enumerates the core libraries for Ladybird provide some hints about Kling's plans to use existing libraries rather than continuing to reinvent the wheel. The core support libraries for the project include homegrown libraries for cryptography, TLS, 2D-graphics rendering, archive-file format support, Unicode, as well as audio and video playback. In the pre-fork documentation, they are described as alternatives to other software. For example, Ladybird's TLS (LibTLS) and cryptography (LibCrypto) libraries are \"Cryptography primitives and Transport Layer Security (rather than OpenSSL)\". The \"rather than\" language has been removed in the journey to the standalone repository, and the LibSQL library from SerenityOS has [already been stripped out](https://github.com/LadybirdWebBrowser/ladybird/commit/8362c073f34f25ef2fbe800780f4b8790b3fffa8)\n in favor of sqlite3.\n\nIn a discussion in the project's Discord instance on June 5, Kling indicated that font rendering would likely be replaced with a third-party library. A user asked on June 6 what would determine whether a component would be developed in-house versus using a third-party library. Kling responded that if it implements a web standard, \"i.e DOM, HTML, JavaScript, CSS, Wasm, etc. then we build it in house.\" Otherwise, the project would look to alternatives \"unless we believe we can build something better ourselves\".\n\n#### Status\n\nLadybird is still in early development (\"pre-alpha\") today. It currently runs on Linux, macOS, and other UNIX-like operating systems. It's also possible to use on Windows with Windows Subsystem for Linux (WSL) version 2, but there appears to be no effort to target Windows independently at this time. At the moment, the project does not provide binaries for any platform. Interested users will need to grab the source and follow the [build instructions](https://github.com/LadybirdWebBrowser/ladybird/blob/master/Documentation/BuildInstructionsLadybird.md)\n. Users will need GCC 13+ or Clang 17, and Qt6 development packages to play along at home. Ladybird compiles and runs on, for example, Fedora 40 without a problem, but it is a long way from being suitable for regular use.\n\n> [![[Ladybird browser with inspector](https://static.lwn.net/images/2024/ladybird-sm.png \"Ladybird browser with inspector\")](/Articles/977492/)\n\nOne might expect that the browser would be more usable with sites with simpler layouts and little to no JavaScript (e.g. LWN) than those with complex layouts and a fair amount of JavaScript (e.g. GitHub). However, this isn't always the case—Ladybird rendered GitHub and many other sites well, if slowly. Browsing LWN anonymously worked well, but logging into LWN, however, consistently proved to be too much for the application. Each time, it basically froze on the front page and clicking links to articles did nothing.\n\nSomewhat ironically, it was not possible to log into Discord using Ladybird. It does a fair job of rendering pages, but speed and stability are still wanting. Each Ladybird tab has its own render process, which is sandboxed as a security measure to prevent any malicious pages from affecting the rest of the system. However, it doesn't seem to suffice to keep a single page from crashing the browser entirely. That's to be expected from a project that's still considered pre-alpha, though.\n\nThe current feature set is, not surprisingly, minimal. Ladybird has a URL/search bar, reload, tabs, can zoom in/out on content, take screenshots, and (of course) has backward and forward navigation. It does not, however, have bookmarks, a history display, extensions, password management, printing, or even the ability to save an image. WebRTC does not seem to be supported yet. CSS support seems relatively robust. Ladybird passes 100% of the CSS Selectors tests for levels 1-3, for example, using [this test](https://css4-selectors.com/browser-selector-test/)\n. It gets a 53% score for level 4, while Firefox gets 71%, so not a terrible showing at all. JavaScript support seems solid, but slow: the [examples here](https://www.w3schools.com/js/js_ex_browser.asp)\n work, but they load slowly.\n\nOn the other hand, Ladybird does have tools for developers, such as inspectors for the document object model (DOM) tree and accessibility trees, as well as the ability to create dumps of various things: the DOM tree and layout tree, computed styles, and so forth. It also has the ability to spoof the User-Agent sent by the browser so that testers can try to get around sites that refuse to work with \"unknown\" browsers. However, toggling the User-Agent wasn't enough to get past Google's gatekeeping to sign into Gmail—but it's unclear if that meant Ladybird wasn't sending the string correctly or if Google is using other means to fingerprint non-approved browsers.\n\nSuffice it to say, Ladybird is not ready for mainstream use but it _does_ show potential. In the past month, the project has had more than 880 commits from 49 authors. If the project maintains that kind of momentum, or picks up steam, it could become a usable alternative to mainstream browsers before too long.\n\n  \n\n* * *\n\n([Log in](https://lwn.net/Login/?target=/Articles/976822/)\n to post comments)\n\n### Congratulations\n\nPosted Jun 7, 2024 18:50 UTC (Fri) by **riking** (subscriber, #95706) \\[[Link](/Articles/977612/)\\\n\\]\n\nCongratulations on what sounds like will be a successful community split. Always tough to do1  \n\n### Where is this going to be 10 years from now?\n\nPosted Jun 7, 2024 19:04 UTC (Fri) by **python** (subscriber, #171317) \\[[Link](/Articles/977610/)\\\n\\] (14 responses)\n\nI am waiting for the day that we see a serious attempt at a browser written in rust. I fear that it might be uneconomical to develop a modern browser in \"lower level\" languages like C++. Valgrind/AddressSanitizer/UndefinedBehaviorSanitizer is no substitute for automated rigorous (mathematically proven) enforcement of program structure/logic/soundness by the compiler. Not to mention the friction posed by not having easy, immediate, access to the sort of ecosystem of third party libraries that we see with npm or cargo.  \n\nI looked at the source code for LadyBird and I am surprised that they are not using C++20 modules (it's been supported by clang for 5 years). I always found maintaining header files (eg. having to write the function definitions twice, once in the .h and once in the .cpp file, etc.) to be a great bother. I can only assume they have much more pressing issues like implementing missing features and trying to comply with all of the modern web standards.  \n\nAs I've watched Firefox, and Microsoft try to compete with Chrome - I find it progressively more difficult to get excited about attempts at new browsers when there appears to be nothing terribly new or innovative about how or what they are trying to achieve. It's a lot of work to build even a small portion of the machinery underlying a web browser like Firefox or Chrome. It will probably take a decade for something like LadyBird to be competitive (assuming that the web \"remains still enough\" to catch up). I fear that they might get mired down in the complexity of what they are trying to achieve (with their chosen tools, and limited manpower) before they ever reach that goal.  \n\n### Where is this going to be 10 years from now?\n\nPosted Jun 7, 2024 19:11 UTC (Fri) by **atai** (subscriber, #10977) \\[[Link](/Articles/977614/)\\\n\\] (1 responses)\n\nA suggestion for you: write a browser in Python. It is surprising in your comment that the world Python appeared only once: in your name  \n\n### Where is this going to be 10 years from now?\n\nPosted Jun 8, 2024 15:13 UTC (Sat) by **ejr** (subscriber, #51652) \\[[Link](/Articles/977659/)\\\n\\]\n\nThat would take Python full circle, particularly if you called it something related to Grail.  \n\n### Where is this going to be 10 years from now?\n\nPosted Jun 7, 2024 19:39 UTC (Fri) by **willy** (subscriber, #9762) \\[[Link](/Articles/977616/)\\\n\\] (2 responses)\n\nIt's funny you say that, given that Rust started as a Mozilla project.  \n\n[https://wiki.mozilla.org/Oxidation](https://wiki.mozilla.org/Oxidation)\n  \n\nis a bit outdated (not modified in 4 years) but clearly shows how Firefox is being gradually rewritten in Rust.  \n\n### Where is this going to be 10 years from now?\n\nPosted Jun 7, 2024 19:47 UTC (Fri) by **atnot** (subscriber, #124910) \\[[Link](/Articles/977618/)\\\n\\]\n\nThere's also servo, which is alive again now, albeit with new goals (serving as an embedded web engine for embedded devices and things people might use Electron for today)  \n\n### Where is this going to be 10 years from now?\n\nPosted Jun 9, 2024 7:23 UTC (Sun) by **dilinger** (subscriber, #2867) \\[[Link](/Articles/977688/)\\\n\\]\n\nChromium is also having components rewritten in rust. As of chromium 120, rustc is now required for building it, and they've started dropping c++ code.  \n\n### C++20 module misconception clearing\n\nPosted Jun 7, 2024 20:34 UTC (Fri) by **mathstuf** (subscriber, #69389) \\[[Link](/Articles/977621/)\\\n\\] (5 responses)\n\n\\> I looked at the source code for LadyBird and I am surprised that they are not using C++20 modules (it's been supported by clang for 5 years).  \n\nClang has not supported C++20 modules for 5 years. 2 is probably more accurate. MSVC is probably close to 3. You're thinking of \"Clang modules\", which served as a prototype for C++20's modules, but not what got standardized (standard modules scale far better according to (ISO-)reported benchmarks). Even with that, (released) build system support for C++20 modules only landed in CMake of October 2023 (FD: I'm the main developer of that support). Now that it does exist, I expect many issues to need fixing over the next few years before it is \"battle hardened\". Other build systems do have support (build2, xmake), but others are still pending (Meson) or have no known progress (autotools, Tup).  \n\nFWIW, I had a prototype that worked with CMake and GCC (both locally patched) in 2019, but what landed is a far better situation than what I had then.  \n\n\\> I always found maintaining header files (eg. having to write the function definitions twice, once in the .h and once in the .cpp file, etc.) to be a great bother.  \n\nSure, you \\*could\\* do one-file modules, but build performance will vastly prefer to continue having the split (just now between module interface and implementation units). The main benefit is that you're now in control of what interface you provide consumers via the \\`export\\` keyword instead of \"whatever the preprocessor happened to come across\" while you included headers for what you needed as well.  \n\n### C++20 module support in build systems\n\nPosted Jun 7, 2024 21:12 UTC (Fri) by **madscientist** (subscriber, #16861) \\[[Link](/Articles/977624/)\\\n\\] (4 responses)\n\nHave people decided on a model for supporting C++ modules in build tools? This is probably OT for this thread but last time I checked there were two models being considered: either some tool parses the module files and generates module description information, which can then be considered by the build system, which I think is the way CMake has gone (it's good for them because they already have a separate \"configure the build\" step).  \n\nThere was also an idea of using an LSP-like model, where a separate server process would keep the module dependency information and respond to requests from clients at runtime.  \n\nIt seems the first has the most momentum behind it. Maybe the second idea has fallen by the wayside.  \n\n### C++20 module support in build systems\n\nPosted Jun 7, 2024 21:45 UTC (Fri) by **NYKevin** (subscriber, #129325) \\[[Link](/Articles/977626/)\\\n\\] (1 responses)\n\nThe CMake approach you describe sounds a lot like something that already exists for the specific combination of Bazel+Go: [https://github.com/bazelbuild/bazel-gazelle](https://github.com/bazelbuild/bazel-gazelle)\n  \n\nThe README says it is extensible \"to support new languages and custom rule sets.\" I wonder if it can be extended for C++ modules? Then setting up a C++ project (that uses modules) in Bazel should be much easier.  \n\n### C++20 module support in build systems\n\nPosted Jun 8, 2024 3:23 UTC (Sat) by **mathstuf** (subscriber, #69389) \\[[Link](/Articles/977638/)\\\n\\]\n\nBazel support is here (I've given feedback and also managed to have Google reconsider external contributions for it instead of waiting for Google to solve it internally and codedump it on the community years from now): [https://github.com/bazelbuild/bazel/pull/19940](https://github.com/bazelbuild/bazel/pull/19940)\n  \n\nI can't say it with 100% confidence, but I don't think Gazelle can handle C++ modules reliably with the existing interfaces. See my other reply in this subthread for details on (CMake's) C++ module compilation strategy (to avoid splitting the discussion).  \n\n### C++20 module support in build systems\n\nPosted Jun 8, 2024 4:30 UTC (Sat) by **mathstuf** (subscriber, #69389) \\[[Link](/Articles/977639/)\\\n\\] (1 responses)\n\n\\> Have people decided on a model for supporting C++ modules in build tools?  \n\nThere are 2 plausible strategies AFAIK (\"explicit\" and \"implicit\"). I consider only 1 (\"explicit\") viable in the grand scheme of the state of the C++ ecosystem where even file extensions cannot be agreed upon. There are tradeoffs of each. For CMake, I chose the one that gives the most reliable results with the widest support because I detest tracking down heisenbuild bugs and CMake ends up having to support all kinds of things anyways.  \n\n\\> some tool parses the module files and generates module description information, which can then be considered by the build system, which can then be considered by the build system, which I think is the way CMake has gone (it's good for them because they already have a separate \"configure the build\" step).  \n\nThis is inaccurate. CMake does this during the build, not during \"configure\". If it were done during the configure step, any change to a C++ module-using or -providing source would require a rerun of the configure to update the build graph. Note that it must also be performed at build time in order to support generated sources (that don't exist to scan at configure time). This is obviously not optimal.  \n\nSome definitions (for clarity):  \n\n\\- build system: a model of a project that represents artifacts and the dependencies between them (e.g., CMake, Bazel, Meson)  \n\\- build tool: a tool which executes a DAG representing a build system's actions to perform the necessary (e.g., Bazel, make, ninja)  \n\\- BMI: \"binary module interface\"; a representation of a module interface that is used when importing the module  \n\\- CMI: \"compiled module interface\"; same as BMI; preferred by some because they might not be \"binary\", but ASCII  \n\\- module interface unit: a source file with \\`export module X;\\` or \\`\\[export\\] module X:partition;\\`; may be imported (assuming language and build system visibility rules allow it)  \n\\- module implementation unit: a source file with \\`module X;\\` that provides implementations for module interfaces that have \\`module X\\` (with or without a partition name; implementation units never mention partitions\\[0\\])  \n\\- explicit module build: the compiler is told the exact BMI file to use for each module it reads or writes  \n\\- implicit module build: the compiler is given search paths to look for or to create BMIs by name (note that this includes when a build system just uses the module name as a key to look them up rather than considering the context of the importing source file: is the requested module visible? is it the right configuration?)  \n\nFor background, this paper\\[1\\] I presented to ISO C++ which describes how CMake supports Fortran modules (which are isomorphic to C++ modules for build graph purposes). The core issue is that the module name has no (forced) relation to the filename on disk. So one needs to determine the dependencies between compilations \\*dynamically\\*. This is distinct from \"discovered\" dependencies reported by the likes of \\`-showIncludes\\` or \\`-MF\\` where the files that are discovered during the course of the tool's execution are reported so that if any change, the tool can be reexecuted. The main point here is that they can be discovered during the first execution (since the output doesn't exist, it needs to run anyways). Modules are different because at the point of \\`import M;\\` during translation we need the BMI of M to continue compilation as the next line might use a type from that module. The compiler needs to know where that BMI is and is the primary goal of the build system for modules: to provide BMI paths during compilation and ensure they're ready when compiling anything that needs them.  \n\nDynamic dependencies instead are dependencies between entities expressed in the \\*content\\* of the sources and nowhere else. To support this, the contents need to be \"scanned\" to report what is needed during compilation and generated during the compilation of the source itself. This is reported in the P1689R5\\[2\\] format that is meant to describe these things. These dependency files (CMake uses the \\`.ddi\\` extension: \"dynamic dependency information\") are then given to a \"collator\" that reads them, the collated information of any dependent libraries, and some details from the CMake, to do the following:  \n\n\\- see file X makes module P  \n\\- sees file Y needs module P  \n\\- writes out a snippet for the build tool (ninja, make) to learn that Y's object rule depends on X's object rule (this is what the details from CMake are needed for: the collator needs to know the paths ninja knows these things by to make a valid dyndep file)  \n\\- writes out a representation of this information for any dependent libraries so that they may be consumed in other targets as well  \n\\- writes out a \"modmap\" file for each TU saying \"I see you want modules E, F, G; here is the path for those modules \\*and no others\\*\" (this is important to avoid accidental/stale module usage; note that Fortran doesn't have this because module files are found via \\`-I\\` flags implicitly…I uncovered a lot of issues with that when enforcing C++ strictness on the Fortran stuff in CMake)  \n\\- (there are some other tasks\\[3\\], but they're not relevant to the build graph)  \n\nThere is some flexibility with this model (also covered in the paper):  \n\n\\- scan individually or scan in batches?  \n\\- collate separately or after scanning?  \n\nSmaller scans are better for incremental (developer) builds (e.g., if 20 files are scanned in a batch, changing any one will force scanning of all 20); batching is better for one-shot (CI) builds. Collating after scanning simplifies the tool (the collator doesn't need to understand $LANG syntax), but is probably slower (lots of tiny P1689 files flitting about). CMake currently has individual scans with separate collation. I don't forsee collation being merged into scanning, but an option to batch scans may make sense given performance measurements.  \n\nRestrictions can also be enforced here. CMake doesn't care about file extensions, basenames matching module names, or anything like that. If one wants to do that (I suspect Meson might do so), that's fine. Configure-time scanning is fine if the configure is fast enough and generated sources (module-providing sources for sure; module-consuming sources may be able to be deferred-scanned, but once you have that support…just simpler to scan everything at build time if you ask me) aren't of any concern.  \n\n\\> There was also an idea of using an LSP-like model, where a separate server process would keep the module dependency information and respond to requests from clients at runtime.  \n\nThis is, AFAIK, what build2 does (it is a build system and a build tool). It may implement it to the level of being an \"explicit\" build, but I've not dug in to know. There are patches to GNU Make to act as a module mapper as well. This patch only works with GCC today; Clang may add support for libcody in the future. Any \"implicit\" implementation has a major flaw in the generic case: I don't know how to meaningfully give visibility to modules. Note that the \"\\`-fmodule-directory=\\` Clang flag where Clang just reads and writes files in the given directory based on module names as this strategy as well (the filesystem is the \"module mapper\" here).  \n\nI find this to be problematic in practice because it means the state of the build graph depends on the runtime state of some running process, not just mtimes, content fingerprints (for tools which are hash-the-content-based rather than mtime-based), some metadata on disk (e.g., \\`.ninja\\_log\\`). I can't imagine how debugging this is expected to work when those not well-versed in build systems are on the front lines.  \n\nBeyond that, there are corner cases to consider:  \n\n\\- When a request to import module Q comes in, how many processes do we expect to launch before we find the rule that exports module Q is found? What if it lies beyond our \\`-j\\` limit? Do we suspend processes while we wait, doing job server shenanigans? What if it doesn't exist? What if we discover a module import cycle?  \n\\- The LSP-model must have some concept of module visibility in mind. Library L links to library K; K's sources should not be able to import any modules that are part of L. Even within L, if a module is not \"public\", it shouldn't be importable from outside of the library (including transitively by its own module interface files).  \n\\- With the filesystem-as-mapper model, stale files are a serious issue. If I rename module R to S, what is in charge of cleaning up R's BMI file? How do I say \"yes, you found it; it is radioactive\"? What remembers that the now-scanned S creator used to make R to clean it up?  \n\\- Duplicate module names. While C++ forbids multiple named modules within a program, nothing prevents \\`export module test;\\` from appearing in separate binaries. Related: if the build graph has release and debug variants, one now needs to track the debug version of module M separately from the release version.  \n\nThese are not easy questions to answer and that's on top of two-way communication with compilers you're launching.  \n\n\\[0\\] There is a wholly unnecessary MSVC extension where it is allowed (IIUC, due to a misreading of the standard that, TBF, we also had when starting CMake's implementation); easily avoided and made portable: drop the partition name.  \n\\[1\\] [https://mathstuf.fedorapeople.org/fortran-modules/fortran...](https://mathstuf.fedorapeople.org/fortran-modules/fortran-modules.html)\n  \n\\[2\\] [https://wg21.link/p1689r5](https://wg21.link/p1689r5)\n  \n\\[3\\] Namely writing install rules for the BMI files and CMake properties for exported targets.  \n\n### C++20 module support in build systems\n\nPosted Jun 9, 2024 0:58 UTC (Sun) by **buck** (subscriber, #55985) \\[[Link](/Articles/977680/)\\\n\\]\n\nThis was breathtaking.  \n\nYou should have saved it up for an LWN contributed article in its own right, though, maybe.  \n\n### Where is this going to be 10 years from now?\n\nPosted Jun 7, 2024 20:47 UTC (Fri) by **q3cpma** (subscriber, #120859) \\[[Link](/Articles/977622/)\\\n\\]\n\nPersonally, I'm still hyped about Nyxt. I plan on switching and donating to it once it supports WebExtensions or something similar to uBlock in advanced JS blocking mode; the modern web without it is just too painful.  \n\n### Where is this going to be 10 years from now?\n\nPosted Jun 8, 2024 12:42 UTC (Sat) by **vadim** (subscriber, #35271) \\[[Link](/Articles/977654/)\\\n\\]\n\nThere's Servo. It's still alive, just split off from Mozilla and now is its own thing.  \n\nWriting a web engine is an enormous project, I'm sure they could use more donations.  \n\n### Where is this going to be 10 years from now?\n\nPosted Jun 15, 2024 9:17 UTC (Sat) by **iteratedlateralus** (subscriber, #102183) \\[[Link](/Articles/978519/)\\\n\\]\n\nIt's fairly common to write header-only C++... which means you wouldn't have to write a function twice. But it definitely doesn't help compile times.  \n\n### Support Firefox instead\n\nPosted Jun 7, 2024 21:07 UTC (Fri) by **Cyberax** (**✭ supporter ✭**, #52523) \\[[Link](/Articles/977625/)\\\n\\] (8 responses)\n\nI don't believe new browsers make any sense today, except as research items.  \n\nIt would be much better to work with Mozilla to improve Firefox. One thing that's sorely missing is the embedding API. It's dead easy to embed Chromium, and this gives it so much advantage.  \n\n### Support Firefox instead\n\nPosted Jun 8, 2024 8:40 UTC (Sat) by **b7j0c** (subscriber, #27559) \\[[Link](/Articles/977646/)\\\n\\] (7 responses)\n\nI don't know how Kling feels about Mozilla but it is also irrelevant; he is not obligated to support Firefox.  \n\nMozilla as an organization is a spent force. They have jettisoned their primary means for making significant game-changing progress (Rust/Servo) and are instead just managing the inertia of their uncompetitive, aged, dying platform.  \n\nMozilla squandered their future in exchange for shallow activism. Did any of their activist goals actually achieve anything other than me-too virtue signalling? I see a decade+ of superficial, low/zero impact activism while Chrome basically ate their entire market share.  \n\nKling is doing us a favor by paving the way for a post-Mozilla future.  \n\n### Support Firefox instead\n\nPosted Jun 8, 2024 12:05 UTC (Sat) by **roc** (subscriber, #30627) \\[[Link](/Articles/977652/)\\\n\\] (6 responses)\n\nFrom a technical point of view Firefox is still very competitive with Chrome. Certainly far more competitive than Ladybird has any hope of ever being.  \n\nI just watched a video on a streaming service. That's basic functionality normal users require. To get that to work well you need a ton of stuff, including  \n\\-- <video> support, including the related DOM APIs  \n\\-- Integration with modern A/V codecs  \n\\-- Integration with hardware-accelerated decoding, where available  \n\\-- Support for Media Source Extensions  \n\\-- Support for EME  \n\\-- Reliable A/V sync  \n\\-- GPU-accelerated rendering  \n\\-- Off-main-thread compositing  \n\\-- Integration with the system compositor framework, where available (to minimize power usage)  \n(I'm sure I missed some stuff, it's been a while.)  \n\nTo be competitive with modern browsers on security you need to have the site JS+CSS+HTML in its own sandboxed process. GPU rendering and A/V decoding need to be in separate sandboxed processes (could be the same process in a pinch).  \n\nFirefox does this all very well. It took many talented engineers (and me) years to build and a lot more work to maintain since then. Maybe Mozilla is a spent force --- I hope not --- but don't underestimate what they had and still have, and how difficult it will be for a new project to even catch up to where they are now.  \n\n### Support Firefox instead\n\nPosted Jun 8, 2024 13:10 UTC (Sat) by **PengZheng** (subscriber, #108006) \\[[Link](/Articles/977656/)\\\n\\]\n\nAgree.  \n\n\\> A user asked on June 6 what would determine whether a component would be developed in-house versus using a third-party library. Kling responded that if it implements a web standard, \"i.e DOM, HTML, JavaScript, CSS, Wasm, etc. then we build it in house.\"  \n\nAs a developer familiar with multimedia streaming, I would say even re-implementing WebRTC alone will be a huge challenge for the small team.  \n\nSeriously, calling Firefox a dying platform will not add one's own value, it just pisses out faithful users of Firefox (there are a LOT here on LWN).  \n\n### Support Firefox instead\n\nPosted Jun 8, 2024 17:44 UTC (Sat) by **cytochrome** (subscriber, #58718) \\[[Link](/Articles/977662/)\\\n\\]\n\nI agree wholeheartedly. I find that Firefox (plus add-ons) satisfies all of my browsing and privacy needs. Thank you to @roc and the other talented software engineers for their hard work in developing and sustaining the application. I have tried to do my small part by donating to the cause several times.  \n\n### Support Firefox instead\n\nPosted Jun 9, 2024 8:55 UTC (Sun) by **roc** (subscriber, #30627) \\[[Link](/Articles/977690/)\\\n\\] (3 responses)\n\nThis inspired me to write a blog post about building a new browser engine. [https://robert.ocallahan.org/2024/06/browser-engine.html](https://robert.ocallahan.org/2024/06/browser-engine.html)\n  \n\n### Support Firefox instead\n\nPosted Jun 15, 2024 2:06 UTC (Sat) by **himi** (subscriber, #340) \\[[Link](/Articles/978509/)\\\n\\] (2 responses)\n\nNot that I'm planning to build a browser engine (for profit or itch-scratching - I'm not insane), but that's a nice description of the complexity of the modern browser environment - it's easily the most complex single piece of software on human-focused general purpose devices, and it's probably the most critical piece of software on those devices. The fact that Mozilla have been able to keep Firefox genuinely competitive with Chrome is a real achievement, anyone targeting that level of functionality from scratch is facing a truly massive battle just to get to the starting line.  \n\nThat said, something that targets the Electron niche (and does it well enough) likely has a lot of legs. Definitely still an uphill battle, but far less of one than targeting a full browser . . .  \n\n### Support Firefox instead\n\nPosted Jun 15, 2024 2:27 UTC (Sat) by **Cyberax** (**✭ supporter ✭**, #52523) \\[[Link](/Articles/978511/)\\\n\\]\n\nThere are projects in this area, like HTMLayout (now [https://sciter.com/](https://sciter.com/)\n ). It was done by a single person, and back in 2000-s quite a few widely used Windows programs had UI built using it.  \n\nSomething like this would be extremely useful. Not a full browser engine, but a subset for UIs.  \n\n### Support Firefox instead\n\nPosted Jun 15, 2024 14:02 UTC (Sat) by **Wol** (subscriber, #4433) \\[[Link](/Articles/978526/)\\\n\\]\n\nMy immediate reaction to this is the web browser is trying to be the new Emacs - all it needs is some hardware to run on, it does everything else.  \n\nBut seriously, to what extent is that the modern paradigm nowadays - the browser is the OS that runs your programs, and linux and Windows are just glorified hardware abstraction layers. For many people - especially at work - that is now not far from the reality ...  \n\nCheers,  \nWol  \n\n### Comparisons to Firefox/Chrome seem premature\n\nPosted Jun 7, 2024 21:19 UTC (Fri) by **flussence** (subscriber, #85566) \\[[Link](/Articles/977623/)\\\n\\]\n\nMost of these alternative browsers fall into a gravity well of being a clone of Firefox 0.6, both in terms of capability and UI, and usually give up there after a period of stagnation. I would like to see something break the curse some day but I've been disappointed too many times to get excited at this point.  \n\n### Quixotic\n\nPosted Jun 7, 2024 22:07 UTC (Fri) by **roc** (subscriber, #30627) \\[[Link](/Articles/977628/)\\\n\\] (1 responses)\n\nSounds like fun, but to build a browser engine that is useful to the masses is going to take them infinitely long. (Literally; the work that needs to be done is growing faster than a handful of developers can do it.)  \n\nAlso, if you're not just doing it for fun, then to justify starting from near-scratch you should make some fundamental decisions differently from the existing engines. Building with Rust would be a good one, but apparently that's not it. Building in site isolation from the ground up (i.e. IFRAMEs in their own processes) would be a good one, but they're not doing that AFAICT. Going all-in on parallelism would be another interesting one but I don't see that either. The only answer here that I can see in interviews with Kling is that Ladybird is designed to hew close to the architecture of the specifications, which is good but not much.  \n\n### Quixotic\n\nPosted Jun 10, 2024 3:23 UTC (Mon) by **raven667** (subscriber, #5198) \\[[Link](/Articles/977726/)\\\n\\]\n\nIt may be quixotic but having someone new attempt to re-implement this stuff from scratch may help better document the actual effort involved in making a working implementation of these standards and what is required to make them fast, which isn't necessarily visible when an existing browser maker with an existing browser engine architecture and existing expert developers, who may have helped write the standard, does it because so much of the surrounding work the standard depends on already exists. If they want to build this for fun and patrons want to fund it for the entertainment value, then so be it, I wish them the best of luck and most success.  \n\n### Crashing is not necessarily a bad omen\n\nPosted Jun 7, 2024 22:18 UTC (Fri) by **cesarb** (subscriber, #6266) \\[[Link](/Articles/977629/)\\\n\\] (8 responses)\n\n\\> However, it doesn't seem to suffice to keep a single page from crashing the browser entirely. That's to be expected from a project that's still considered pre-alpha, though.  \n\nI still remember using the single-digit milestone releases of Mozilla Suite (according to [https://en.wikipedia.org/wiki/History\\_of\\_Mozilla\\_Applicat...](https://en.wikipedia.org/wiki/History_of_Mozilla_Application_Suite)\n this was back in 1999). Each page I loaded had a chance of crashing the whole browser, and that chance increased dramatically if I used more than one browser window (there were no browser tabs back then). It was fun. I stuck with it, later switching to its descendant Phoenix/Firebird/Firefox, which I still use to this day.  \n\nThat is, history shows that crashing often, this early in the project's life, does not mean the project is going to fail.  \n\n### Crashing is not necessarily a bad omen\n\nPosted Jun 8, 2024 6:43 UTC (Sat) by **joib** (subscriber, #8541) \\[[Link](/Articles/977643/)\\\n\\]\n\nWell, back then netscape/mozilla/firefox was about the only decent(ish) alternative to IE, so you didn't have much alternative. Today you can switch to Firefox, Chrome, or a plethora of Chrome /webkit based browsers. So the bar for what people consider a MVP is much higher.  \n\n### Crashing is not necessarily a bad omen\n\nPosted Jun 10, 2024 7:16 UTC (Mon) by **edeloget** (subscriber, #88392) \\[[Link](/Articles/977728/)\\\n\\] (4 responses)\n\nAnd to be honest, this was a time when we routinely rebooted the whole PC multiple times per day, so having a crash on a web browser, while annoying, was kind of expected :)  \n\n### Crashing is not necessarily a bad omen\n\nPosted Jun 10, 2024 11:25 UTC (Mon) by **cesarb** (subscriber, #6266) \\[[Link](/Articles/977738/)\\\n\\] (3 responses)\n\n\\> And to be honest, this was a time when we routinely rebooted the whole PC multiple times per day,  \n\nThis was also a time when people bragged on slashdot about their Linux uptime. Rebooting the whole PC multiple times per day was IIRC more of a Windows thing back then; I was surprised when once I somehow managed to kernel panic Linux by doing something as simple as removing a floppy disk which was in use.  \n\n\\> so having a crash on a web browser, while annoying, was kind of expected :)  \n\nThis, on the other hand, was IIRC more common, even in non-alpha browsers like the pre-open-sourcing Netscape Navigator 4.x. But they were not so unstable that one would be afraid to open more than one window at the same time, for fear of a crash closing all open browser windows.  \n\n### Crashing is not necessarily a bad omen\n\nPosted Jun 10, 2024 12:25 UTC (Mon) by **geert** (subscriber, #98403) \\[[Link](/Articles/977741/)\\\n\\] (1 responses)\n\nexport MALLOC\\_CHECK=0  \nnetscape  \n\n### Crashing is not necessarily a bad omen\n\nPosted Jun 10, 2024 12:32 UTC (Mon) by **khim** (subscriber, #9252) \\[[Link](/Articles/977742/)\\\n\\]\n\nThere was a way to attach [Boehm GC](https://en.wikipedia.org/wiki/Boehm_garbage_collector)\n to it, if I remember correctly.\n\nThat was more stable.\n\n### Crashing is not necessarily a bad omen\n\nPosted Jun 14, 2024 23:28 UTC (Fri) by **ssmith32** (subscriber, #72404) \\[[Link](/Articles/978504/)\\\n\\]\n\nUptime on servers, sure.  \nUptime for the kernel was pretty good on desktops.  \n\nBut I remember being pretty handy with alt-shift-F1 and alt-shift-backspace, or whatever the hotkeys were to get to the virtual consoles and hard-kill X.  \n\nAnd X dying was almost as bad as a full reboot for a desktop where apps didn't do a terribly good job with checkpoints and session restores.  \n\nSo, while restarts and blue screens and corrupted data is what moved me off of Windows in the early 2000s, the Linux Desktop was not nearly as stable as it is today.  \n\nNowadays, I had one desktop issue in the past few years, and I had System76 support figure out the issue and send me a new driver (which weirdly was triggered by using Google Maps in Firefox). Worlds better than when I was running a Mandrake (RPM) Frankenstein where half the software was compiled from tarballs because the RPMs available were woefully out of date..  \n\n### Crashing is not necessarily a bad omen\n\nPosted Jun 10, 2024 19:56 UTC (Mon) by **parametricpoly** (subscriber, #143903) \\[[Link](/Articles/977829/)\\\n\\] (1 responses)\n\nProgramming languages have improved quite a bit since 1990s. It's really no wonder it crashes it they chose C++. Using C++ here again is a waste of talent. Heck they could have picked Java instead. Java 22 is already pretty decent and more goodies will arrive in the LTS 24 release.  \n\n### Crashing is not necessarily a bad omen\n\nPosted Jun 13, 2024 5:40 UTC (Thu) by **ceplm** (subscriber, #41334) \\[[Link](/Articles/978219/)\\\n\\]\n\nHow is Rhino doing these days? Is it already in the same speed rank as other major JavaScript engines?  \n\nActually, surprisingly, it is still alive. That’s more than I expected.  \n\n### Future?\n\nPosted Jun 8, 2024 15:45 UTC (Sat) by **drago01** (subscriber, #50715) \\[[Link](/Articles/977660/)\\\n\\]\n\nDoes this have any futute other than being a \"toy\" project?  \n\nIt doesn't do anything new or different to attract enough attention to compete with Chromium or Firefox.  \n\n### Why \\*not\\*?\n\nPosted Jun 8, 2024 16:45 UTC (Sat) by **rsidd** (subscriber, #2582) \\[[Link](/Articles/977661/)\\\n\\] (3 responses)\n\nI don't get all these comments about \"why work on this\". Because they want to, that's why. And SerenityOS seems much less relevant or useful to the wider world but that's where it started and that's an itch Kling wanted to scratch. Good for him. Both projects seem to have built a substantial community so it's not just him.  \n\nIt's pretty impressive what Ladybird has achieved, and there's no reason to think it won't be 10× more useful a year from now even if it lags Chrome and Firefox in some respects. But even if not, this is what they want to do, good luck to them.  \n\nAnd it's false logic to say they should just work on firefox. That's not how \"scratch an itch\" works.  \n\nActually, given the change in policy that they will not DIY everything but accept some NIH code where useful, I expect the next 12 months to be pretty interesting.  \n\n### Why \\*not\\*?\n\nPosted Jun 9, 2024 4:58 UTC (Sun) by **chris\\_se** (subscriber, #99706) \\[[Link](/Articles/977683/)\\\n\\] (2 responses)\n\nI completely agree with you.  \n\nFor that matter, I believe that the current browser ecosystem is not healthy at all: you have Chrome (+ all its derivatives), and Firefox (+ its derivatives), and then some niche projects. And while derivatives of Chrome make some changes, they will not diverge significantly from the actual browsing engine, so in the end, Google is the only one that determines what's next in terms of browser engine development, regardless of whether you use Edge, Chrome, Chromium, Opera, ... The only usable alternative right now is Firefox, but they are not the ones driving innovation in that space at the moment, unfortunately. (Which is a real shame, I like Firefox.)  \n\nSo in that sense I welcome people being excited and working on alternatives, such as Servo, Ladybird, and others. Because I don't want to be in the situation where the entire future of the web is basically in the hands of a single company, and even if I don't end up using them myself for whatever reason, if they do thrive, they will bring a breath of fresh air into the web ecosystem, which is sorely needed in my opinion.  \n\n### Why \\*not\\*?\n\nPosted Jun 9, 2024 14:44 UTC (Sun) by **rgmoore** (**✭ supporter ✭**, #75) \\[[Link](/Articles/977701/)\\\n\\] (1 responses)\n\nThe current browser ecosystem is unhealthy because Google sees Chrome as a means to maintain its dominant market position in the lucrative search and online advertising businesses. They use their money from search and ads to squeeze profits out of the browser market and make it effectively impossible for anyone to make money by developing a competing browser from scratch. It's basically the IE situation from the late '90s all over again, and it won't improve until some government steps up antitrust enforcement the way the USA did in the '90s.\n\n### Chromium is a browser consortium lead by Google\n\nPosted Jun 10, 2024 3:37 UTC (Mon) by **raven667** (subscriber, #5198) \\[[Link](/Articles/977727/)\\\n\\]\n\nOne important distinction from the bad old MSIE days is that Chromium is open source, not private/proprietary like MSIE, and acts as a reference implementation of a multi-vendor platform designed by consortium that includes competitors Google and MS (lead by Google) and separately with their own engines Apple and Mozilla, in some ways no different than Linux being developed as a shared project by many competing companies (although for Linux the consortium/trade org LF operates for \\_all\\_ vendors so there is no \\_one\\_ lead vendor) along side the similar BSDs with their own base OS funded by Apple and other vendors. The mechanisms and possibilities for \"lock-in\" are very different than before.  \n\n  \n\nCopyright © 2024, Eklektix, Inc.  \nThis article may be redistributed under the terms of the [Creative Commons CC BY-SA 4.0](http://creativecommons.org/licenses/by-sa/4.0/)\n license  \nComments and public postings are copyrighted by their creators.  \nLinux is a registered trademark of Linus Torvalds",
		"markdown": " [![LWN.net Logo](https://static.lwn.net/images/logo/barepenguin-70.png) LWN  \\\n.net News from the source](/)\n [![LWN](https://static.lwn.net/images/lcorner-ss.png)](/)\n\n*   [**Content**](#t)\n    *   [Weekly Edition](/current/)\n        \n    *   [Archives](/Archives/)\n        \n    *   [Search](/Search/)\n        \n    *   [Kernel](/Kernel/)\n        \n    *   [Security](/Security/)\n        \n    *   [Events calendar](/Calendar/)\n        \n    *   [Unread comments](/Comments/unread)\n        \n    *   * * *\n        \n    *   [LWN FAQ](/op/FAQ.lwn)\n        \n    *   [Write for us](/op/AuthorGuide.lwn)\n        \n*   [**Edition**](#t)\n    *   [Return to the Front page](/Articles/977366/)\n        \n\n**User:**  **Password:**   \n\n|\n\n|\n\n[**Subscribe**](/subscribe/)\n / [**Log in**](/Login/)\n / [**New account**](/Login/newaccount)\n\nLadybird browser spreads its wings\n==================================\n\n**This article brought to you by LWN subscribers**\n\nSubscribers to LWN.net made this article — and everything that surrounds it — possible. If you appreciate our content, please [buy a subscription](/subscribe/)\n and make the next set of articles possible.\n\nBy **Joe Brockmeier**  \nJune 7, 2024\n\n[Ladybird](https://ladybird.dev/)\n is an open-source project aimed at building an independent web browser, rather than yet another browser based on Chrome. It is written in C++ and licensed under a two-clause BSD license. The effort began as part of the [SerenityOS](https://www.serenityos.org/)\n project, but developer Andreas Kling [announced](https://awesomekling.substack.com/p/forking-ladybird-and-stepping-down-serenityos)\n on June 3 that he was \"forking\" Ladybird as a separate project and stepping away from SerenityOS to focus his attention on the browser completely. Ladybird is not ready to replace Firefox or Chrome for regular use, but it is showing great promise.\n\nKling started working on SerenityOS in 2018 as a therapy project after completing a substance-abuse rehabilitation program. The SerenityOS name is a nod to the [serenity prayer](https://en.wikipedia.org/wiki/Serenity_Prayer)\n. Prior to working on the project, he had worked on WebKit-based browsers at Apple and Nokia. Eventually he [made SerenityOS his full-time job](https://awesomekling.github.io/I-quit-my-job-to-focus-on-SerenityOS-full-time/)\n, and funded the work through donations, sales of SerenityOS merchandise, and income from YouTube. (Kling posts monthly updates to his [YouTube channel](https://www.youtube.com/@awesomekling/videos)\n about Ladybird, as well as hacking videos where he walks through working on various components in the browser, such as the [JavaScript JIT compiler](https://www.youtube.com/watch?v=8mxubNQC5O8)\n.)\n\n#### Taking flight\n\nKling [announced](https://awesomekling.substack.com/p/ladybird-a-new-cross-platform-browser-project)\n the Ladybird project in September 2022. He said that the project started while creating a Qt GUI for SerenityOS's LibWeb browser engine. He decided to target Linux as well as SerenityOS so it would be easier for people to work on and debug while in Linux. In the post announcing his intent to work solely on Ladybird, he noted that he had been focusing all of his attention on the Linux version of Ladybird. With that realization, he decided to step down as \"benevolent dictator for life\" (BDFL) of SerenityOS so its development would not be held back:\n\n> Before anyone asks, there is no drama behind this change. It's simply recognizing that there have been two big projects packed uncomfortably into a single space for too long, and I'm doing what I believe will make life better for everyone involved.\n\nLadybird's governance is similar to SerenityOS. Kling is the BDFL, with a group of maintainers (currently ten) who can approve and merge pull requests. The [contributing](https://github.com/LadybirdWebBrowser/ladybird/blob/master/CONTRIBUTING.md)\n guide notes that maintainership is \"by invitation only and does not correlate with any particular metric\". Project development discussions are held on a [Discord server](https://discord.com/invite/nvfjVJ4Svh)\n (account required).\n\nNow independent, Ladybird has dropped SerenityOS as a development target, and has moved to [its own GitHub repository](https://github.com/LadybirdWebBrowser/ladybird)\n. In addition, Kling has relaxed his self-imposed policy of excluding \"not invented here\" (NIH) code that had applied to SerenityOS, which means that the Ladybird project will be able to make use of existing libraries rather than writing from scratch.\n\nComparing the [README](https://github.com/LadybirdWebBrowser/ladybird/blob/master/README.md)\n file in the standalone Ladybird repository against the [README](https://github.com/SerenityOS/serenity/blob/master/Ladybird/README.md)\n file in the SerenityOS repository, the goal has evolved from creating \"a standards-compliant, independent web browser with no third-party dependencies\" to developing an independent browser \"using a novel engine based on web standards\".\n\nThe changes to the section that enumerates the core libraries for Ladybird provide some hints about Kling's plans to use existing libraries rather than continuing to reinvent the wheel. The core support libraries for the project include homegrown libraries for cryptography, TLS, 2D-graphics rendering, archive-file format support, Unicode, as well as audio and video playback. In the pre-fork documentation, they are described as alternatives to other software. For example, Ladybird's TLS (LibTLS) and cryptography (LibCrypto) libraries are \"Cryptography primitives and Transport Layer Security (rather than OpenSSL)\". The \"rather than\" language has been removed in the journey to the standalone repository, and the LibSQL library from SerenityOS has [already been stripped out](https://github.com/LadybirdWebBrowser/ladybird/commit/8362c073f34f25ef2fbe800780f4b8790b3fffa8)\n in favor of sqlite3.\n\nIn a discussion in the project's Discord instance on June 5, Kling indicated that font rendering would likely be replaced with a third-party library. A user asked on June 6 what would determine whether a component would be developed in-house versus using a third-party library. Kling responded that if it implements a web standard, \"i.e DOM, HTML, JavaScript, CSS, Wasm, etc. then we build it in house.\" Otherwise, the project would look to alternatives \"unless we believe we can build something better ourselves\".\n\n#### Status\n\nLadybird is still in early development (\"pre-alpha\") today. It currently runs on Linux, macOS, and other UNIX-like operating systems. It's also possible to use on Windows with Windows Subsystem for Linux (WSL) version 2, but there appears to be no effort to target Windows independently at this time. At the moment, the project does not provide binaries for any platform. Interested users will need to grab the source and follow the [build instructions](https://github.com/LadybirdWebBrowser/ladybird/blob/master/Documentation/BuildInstructionsLadybird.md)\n. Users will need GCC 13+ or Clang 17, and Qt6 development packages to play along at home. Ladybird compiles and runs on, for example, Fedora 40 without a problem, but it is a long way from being suitable for regular use.\n\n> [![[Ladybird browser with inspector](https://static.lwn.net/images/2024/ladybird-sm.png \"Ladybird browser with inspector\")](/Articles/977492/)\n\nOne might expect that the browser would be more usable with sites with simpler layouts and little to no JavaScript (e.g. LWN) than those with complex layouts and a fair amount of JavaScript (e.g. GitHub). However, this isn't always the case—Ladybird rendered GitHub and many other sites well, if slowly. Browsing LWN anonymously worked well, but logging into LWN, however, consistently proved to be too much for the application. Each time, it basically froze on the front page and clicking links to articles did nothing.\n\nSomewhat ironically, it was not possible to log into Discord using Ladybird. It does a fair job of rendering pages, but speed and stability are still wanting. Each Ladybird tab has its own render process, which is sandboxed as a security measure to prevent any malicious pages from affecting the rest of the system. However, it doesn't seem to suffice to keep a single page from crashing the browser entirely. That's to be expected from a project that's still considered pre-alpha, though.\n\nThe current feature set is, not surprisingly, minimal. Ladybird has a URL/search bar, reload, tabs, can zoom in/out on content, take screenshots, and (of course) has backward and forward navigation. It does not, however, have bookmarks, a history display, extensions, password management, printing, or even the ability to save an image. WebRTC does not seem to be supported yet. CSS support seems relatively robust. Ladybird passes 100% of the CSS Selectors tests for levels 1-3, for example, using [this test](https://css4-selectors.com/browser-selector-test/)\n. It gets a 53% score for level 4, while Firefox gets 71%, so not a terrible showing at all. JavaScript support seems solid, but slow: the [examples here](https://www.w3schools.com/js/js_ex_browser.asp)\n work, but they load slowly.\n\nOn the other hand, Ladybird does have tools for developers, such as inspectors for the document object model (DOM) tree and accessibility trees, as well as the ability to create dumps of various things: the DOM tree and layout tree, computed styles, and so forth. It also has the ability to spoof the User-Agent sent by the browser so that testers can try to get around sites that refuse to work with \"unknown\" browsers. However, toggling the User-Agent wasn't enough to get past Google's gatekeeping to sign into Gmail—but it's unclear if that meant Ladybird wasn't sending the string correctly or if Google is using other means to fingerprint non-approved browsers.\n\nSuffice it to say, Ladybird is not ready for mainstream use but it _does_ show potential. In the past month, the project has had more than 880 commits from 49 authors. If the project maintains that kind of momentum, or picks up steam, it could become a usable alternative to mainstream browsers before too long.\n\n  \n\n* * *\n\n([Log in](https://lwn.net/Login/?target=/Articles/976822/)\n to post comments)\n\n### Congratulations\n\nPosted Jun 7, 2024 18:50 UTC (Fri) by **riking** (subscriber, #95706) \\[[Link](/Articles/977612/)\\\n\\]\n\nCongratulations on what sounds like will be a successful community split. Always tough to do1  \n\n### Where is this going to be 10 years from now?\n\nPosted Jun 7, 2024 19:04 UTC (Fri) by **python** (subscriber, #171317) \\[[Link](/Articles/977610/)\\\n\\] (14 responses)\n\nI am waiting for the day that we see a serious attempt at a browser written in rust. I fear that it might be uneconomical to develop a modern browser in \"lower level\" languages like C++. Valgrind/AddressSanitizer/UndefinedBehaviorSanitizer is no substitute for automated rigorous (mathematically proven) enforcement of program structure/logic/soundness by the compiler. Not to mention the friction posed by not having easy, immediate, access to the sort of ecosystem of third party libraries that we see with npm or cargo.  \n\nI looked at the source code for LadyBird and I am surprised that they are not using C++20 modules (it's been supported by clang for 5 years). I always found maintaining header files (eg. having to write the function definitions twice, once in the .h and once in the .cpp file, etc.) to be a great bother. I can only assume they have much more pressing issues like implementing missing features and trying to comply with all of the modern web standards.  \n\nAs I've watched Firefox, and Microsoft try to compete with Chrome - I find it progressively more difficult to get excited about attempts at new browsers when there appears to be nothing terribly new or innovative about how or what they are trying to achieve. It's a lot of work to build even a small portion of the machinery underlying a web browser like Firefox or Chrome. It will probably take a decade for something like LadyBird to be competitive (assuming that the web \"remains still enough\" to catch up). I fear that they might get mired down in the complexity of what they are trying to achieve (with their chosen tools, and limited manpower) before they ever reach that goal.  \n\n### Where is this going to be 10 years from now?\n\nPosted Jun 7, 2024 19:11 UTC (Fri) by **atai** (subscriber, #10977) \\[[Link](/Articles/977614/)\\\n\\] (1 responses)\n\nA suggestion for you: write a browser in Python. It is surprising in your comment that the world Python appeared only once: in your name  \n\n### Where is this going to be 10 years from now?\n\nPosted Jun 8, 2024 15:13 UTC (Sat) by **ejr** (subscriber, #51652) \\[[Link](/Articles/977659/)\\\n\\]\n\nThat would take Python full circle, particularly if you called it something related to Grail.  \n\n### Where is this going to be 10 years from now?\n\nPosted Jun 7, 2024 19:39 UTC (Fri) by **willy** (subscriber, #9762) \\[[Link](/Articles/977616/)\\\n\\] (2 responses)\n\nIt's funny you say that, given that Rust started as a Mozilla project.  \n\n[https://wiki.mozilla.org/Oxidation](https://wiki.mozilla.org/Oxidation)\n  \n\nis a bit outdated (not modified in 4 years) but clearly shows how Firefox is being gradually rewritten in Rust.  \n\n### Where is this going to be 10 years from now?\n\nPosted Jun 7, 2024 19:47 UTC (Fri) by **atnot** (subscriber, #124910) \\[[Link](/Articles/977618/)\\\n\\]\n\nThere's also servo, which is alive again now, albeit with new goals (serving as an embedded web engine for embedded devices and things people might use Electron for today)  \n\n### Where is this going to be 10 years from now?\n\nPosted Jun 9, 2024 7:23 UTC (Sun) by **dilinger** (subscriber, #2867) \\[[Link](/Articles/977688/)\\\n\\]\n\nChromium is also having components rewritten in rust. As of chromium 120, rustc is now required for building it, and they've started dropping c++ code.  \n\n### C++20 module misconception clearing\n\nPosted Jun 7, 2024 20:34 UTC (Fri) by **mathstuf** (subscriber, #69389) \\[[Link](/Articles/977621/)\\\n\\] (5 responses)\n\n\\> I looked at the source code for LadyBird and I am surprised that they are not using C++20 modules (it's been supported by clang for 5 years).  \n\nClang has not supported C++20 modules for 5 years. 2 is probably more accurate. MSVC is probably close to 3. You're thinking of \"Clang modules\", which served as a prototype for C++20's modules, but not what got standardized (standard modules scale far better according to (ISO-)reported benchmarks). Even with that, (released) build system support for C++20 modules only landed in CMake of October 2023 (FD: I'm the main developer of that support). Now that it does exist, I expect many issues to need fixing over the next few years before it is \"battle hardened\". Other build systems do have support (build2, xmake), but others are still pending (Meson) or have no known progress (autotools, Tup).  \n\nFWIW, I had a prototype that worked with CMake and GCC (both locally patched) in 2019, but what landed is a far better situation than what I had then.  \n\n\\> I always found maintaining header files (eg. having to write the function definitions twice, once in the .h and once in the .cpp file, etc.) to be a great bother.  \n\nSure, you \\*could\\* do one-file modules, but build performance will vastly prefer to continue having the split (just now between module interface and implementation units). The main benefit is that you're now in control of what interface you provide consumers via the \\`export\\` keyword instead of \"whatever the preprocessor happened to come across\" while you included headers for what you needed as well.  \n\n### C++20 module support in build systems\n\nPosted Jun 7, 2024 21:12 UTC (Fri) by **madscientist** (subscriber, #16861) \\[[Link](/Articles/977624/)\\\n\\] (4 responses)\n\nHave people decided on a model for supporting C++ modules in build tools? This is probably OT for this thread but last time I checked there were two models being considered: either some tool parses the module files and generates module description information, which can then be considered by the build system, which I think is the way CMake has gone (it's good for them because they already have a separate \"configure the build\" step).  \n\nThere was also an idea of using an LSP-like model, where a separate server process would keep the module dependency information and respond to requests from clients at runtime.  \n\nIt seems the first has the most momentum behind it. Maybe the second idea has fallen by the wayside.  \n\n### C++20 module support in build systems\n\nPosted Jun 7, 2024 21:45 UTC (Fri) by **NYKevin** (subscriber, #129325) \\[[Link](/Articles/977626/)\\\n\\] (1 responses)\n\nThe CMake approach you describe sounds a lot like something that already exists for the specific combination of Bazel+Go: [https://github.com/bazelbuild/bazel-gazelle](https://github.com/bazelbuild/bazel-gazelle)\n  \n\nThe README says it is extensible \"to support new languages and custom rule sets.\" I wonder if it can be extended for C++ modules? Then setting up a C++ project (that uses modules) in Bazel should be much easier.  \n\n### C++20 module support in build systems\n\nPosted Jun 8, 2024 3:23 UTC (Sat) by **mathstuf** (subscriber, #69389) \\[[Link](/Articles/977638/)\\\n\\]\n\nBazel support is here (I've given feedback and also managed to have Google reconsider external contributions for it instead of waiting for Google to solve it internally and codedump it on the community years from now): [https://github.com/bazelbuild/bazel/pull/19940](https://github.com/bazelbuild/bazel/pull/19940)\n  \n\nI can't say it with 100% confidence, but I don't think Gazelle can handle C++ modules reliably with the existing interfaces. See my other reply in this subthread for details on (CMake's) C++ module compilation strategy (to avoid splitting the discussion).  \n\n### C++20 module support in build systems\n\nPosted Jun 8, 2024 4:30 UTC (Sat) by **mathstuf** (subscriber, #69389) \\[[Link](/Articles/977639/)\\\n\\] (1 responses)\n\n\\> Have people decided on a model for supporting C++ modules in build tools?  \n\nThere are 2 plausible strategies AFAIK (\"explicit\" and \"implicit\"). I consider only 1 (\"explicit\") viable in the grand scheme of the state of the C++ ecosystem where even file extensions cannot be agreed upon. There are tradeoffs of each. For CMake, I chose the one that gives the most reliable results with the widest support because I detest tracking down heisenbuild bugs and CMake ends up having to support all kinds of things anyways.  \n\n\\> some tool parses the module files and generates module description information, which can then be considered by the build system, which can then be considered by the build system, which I think is the way CMake has gone (it's good for them because they already have a separate \"configure the build\" step).  \n\nThis is inaccurate. CMake does this during the build, not during \"configure\". If it were done during the configure step, any change to a C++ module-using or -providing source would require a rerun of the configure to update the build graph. Note that it must also be performed at build time in order to support generated sources (that don't exist to scan at configure time). This is obviously not optimal.  \n\nSome definitions (for clarity):  \n\n\\- build system: a model of a project that represents artifacts and the dependencies between them (e.g., CMake, Bazel, Meson)  \n\\- build tool: a tool which executes a DAG representing a build system's actions to perform the necessary (e.g., Bazel, make, ninja)  \n\\- BMI: \"binary module interface\"; a representation of a module interface that is used when importing the module  \n\\- CMI: \"compiled module interface\"; same as BMI; preferred by some because they might not be \"binary\", but ASCII  \n\\- module interface unit: a source file with \\`export module X;\\` or \\`\\[export\\] module X:partition;\\`; may be imported (assuming language and build system visibility rules allow it)  \n\\- module implementation unit: a source file with \\`module X;\\` that provides implementations for module interfaces that have \\`module X\\` (with or without a partition name; implementation units never mention partitions\\[0\\])  \n\\- explicit module build: the compiler is told the exact BMI file to use for each module it reads or writes  \n\\- implicit module build: the compiler is given search paths to look for or to create BMIs by name (note that this includes when a build system just uses the module name as a key to look them up rather than considering the context of the importing source file: is the requested module visible? is it the right configuration?)  \n\nFor background, this paper\\[1\\] I presented to ISO C++ which describes how CMake supports Fortran modules (which are isomorphic to C++ modules for build graph purposes). The core issue is that the module name has no (forced) relation to the filename on disk. So one needs to determine the dependencies between compilations \\*dynamically\\*. This is distinct from \"discovered\" dependencies reported by the likes of \\`-showIncludes\\` or \\`-MF\\` where the files that are discovered during the course of the tool's execution are reported so that if any change, the tool can be reexecuted. The main point here is that they can be discovered during the first execution (since the output doesn't exist, it needs to run anyways). Modules are different because at the point of \\`import M;\\` during translation we need the BMI of M to continue compilation as the next line might use a type from that module. The compiler needs to know where that BMI is and is the primary goal of the build system for modules: to provide BMI paths during compilation and ensure they're ready when compiling anything that needs them.  \n\nDynamic dependencies instead are dependencies between entities expressed in the \\*content\\* of the sources and nowhere else. To support this, the contents need to be \"scanned\" to report what is needed during compilation and generated during the compilation of the source itself. This is reported in the P1689R5\\[2\\] format that is meant to describe these things. These dependency files (CMake uses the \\`.ddi\\` extension: \"dynamic dependency information\") are then given to a \"collator\" that reads them, the collated information of any dependent libraries, and some details from the CMake, to do the following:  \n\n\\- see file X makes module P  \n\\- sees file Y needs module P  \n\\- writes out a snippet for the build tool (ninja, make) to learn that Y's object rule depends on X's object rule (this is what the details from CMake are needed for: the collator needs to know the paths ninja knows these things by to make a valid dyndep file)  \n\\- writes out a representation of this information for any dependent libraries so that they may be consumed in other targets as well  \n\\- writes out a \"modmap\" file for each TU saying \"I see you want modules E, F, G; here is the path for those modules \\*and no others\\*\" (this is important to avoid accidental/stale module usage; note that Fortran doesn't have this because module files are found via \\`-I\\` flags implicitly…I uncovered a lot of issues with that when enforcing C++ strictness on the Fortran stuff in CMake)  \n\\- (there are some other tasks\\[3\\], but they're not relevant to the build graph)  \n\nThere is some flexibility with this model (also covered in the paper):  \n\n\\- scan individually or scan in batches?  \n\\- collate separately or after scanning?  \n\nSmaller scans are better for incremental (developer) builds (e.g., if 20 files are scanned in a batch, changing any one will force scanning of all 20); batching is better for one-shot (CI) builds. Collating after scanning simplifies the tool (the collator doesn't need to understand $LANG syntax), but is probably slower (lots of tiny P1689 files flitting about). CMake currently has individual scans with separate collation. I don't forsee collation being merged into scanning, but an option to batch scans may make sense given performance measurements.  \n\nRestrictions can also be enforced here. CMake doesn't care about file extensions, basenames matching module names, or anything like that. If one wants to do that (I suspect Meson might do so), that's fine. Configure-time scanning is fine if the configure is fast enough and generated sources (module-providing sources for sure; module-consuming sources may be able to be deferred-scanned, but once you have that support…just simpler to scan everything at build time if you ask me) aren't of any concern.  \n\n\\> There was also an idea of using an LSP-like model, where a separate server process would keep the module dependency information and respond to requests from clients at runtime.  \n\nThis is, AFAIK, what build2 does (it is a build system and a build tool). It may implement it to the level of being an \"explicit\" build, but I've not dug in to know. There are patches to GNU Make to act as a module mapper as well. This patch only works with GCC today; Clang may add support for libcody in the future. Any \"implicit\" implementation has a major flaw in the generic case: I don't know how to meaningfully give visibility to modules. Note that the \"\\`-fmodule-directory=\\` Clang flag where Clang just reads and writes files in the given directory based on module names as this strategy as well (the filesystem is the \"module mapper\" here).  \n\nI find this to be problematic in practice because it means the state of the build graph depends on the runtime state of some running process, not just mtimes, content fingerprints (for tools which are hash-the-content-based rather than mtime-based), some metadata on disk (e.g., \\`.ninja\\_log\\`). I can't imagine how debugging this is expected to work when those not well-versed in build systems are on the front lines.  \n\nBeyond that, there are corner cases to consider:  \n\n\\- When a request to import module Q comes in, how many processes do we expect to launch before we find the rule that exports module Q is found? What if it lies beyond our \\`-j\\` limit? Do we suspend processes while we wait, doing job server shenanigans? What if it doesn't exist? What if we discover a module import cycle?  \n\\- The LSP-model must have some concept of module visibility in mind. Library L links to library K; K's sources should not be able to import any modules that are part of L. Even within L, if a module is not \"public\", it shouldn't be importable from outside of the library (including transitively by its own module interface files).  \n\\- With the filesystem-as-mapper model, stale files are a serious issue. If I rename module R to S, what is in charge of cleaning up R's BMI file? How do I say \"yes, you found it; it is radioactive\"? What remembers that the now-scanned S creator used to make R to clean it up?  \n\\- Duplicate module names. While C++ forbids multiple named modules within a program, nothing prevents \\`export module test;\\` from appearing in separate binaries. Related: if the build graph has release and debug variants, one now needs to track the debug version of module M separately from the release version.  \n\nThese are not easy questions to answer and that's on top of two-way communication with compilers you're launching.  \n\n\\[0\\] There is a wholly unnecessary MSVC extension where it is allowed (IIUC, due to a misreading of the standard that, TBF, we also had when starting CMake's implementation); easily avoided and made portable: drop the partition name.  \n\\[1\\] [https://mathstuf.fedorapeople.org/fortran-modules/fortran...](https://mathstuf.fedorapeople.org/fortran-modules/fortran-modules.html)\n  \n\\[2\\] [https://wg21.link/p1689r5](https://wg21.link/p1689r5)\n  \n\\[3\\] Namely writing install rules for the BMI files and CMake properties for exported targets.  \n\n### C++20 module support in build systems\n\nPosted Jun 9, 2024 0:58 UTC (Sun) by **buck** (subscriber, #55985) \\[[Link](/Articles/977680/)\\\n\\]\n\nThis was breathtaking.  \n\nYou should have saved it up for an LWN contributed article in its own right, though, maybe.  \n\n### Where is this going to be 10 years from now?\n\nPosted Jun 7, 2024 20:47 UTC (Fri) by **q3cpma** (subscriber, #120859) \\[[Link](/Articles/977622/)\\\n\\]\n\nPersonally, I'm still hyped about Nyxt. I plan on switching and donating to it once it supports WebExtensions or something similar to uBlock in advanced JS blocking mode; the modern web without it is just too painful.  \n\n### Where is this going to be 10 years from now?\n\nPosted Jun 8, 2024 12:42 UTC (Sat) by **vadim** (subscriber, #35271) \\[[Link](/Articles/977654/)\\\n\\]\n\nThere's Servo. It's still alive, just split off from Mozilla and now is its own thing.  \n\nWriting a web engine is an enormous project, I'm sure they could use more donations.  \n\n### Where is this going to be 10 years from now?\n\nPosted Jun 15, 2024 9:17 UTC (Sat) by **iteratedlateralus** (subscriber, #102183) \\[[Link](/Articles/978519/)\\\n\\]\n\nIt's fairly common to write header-only C++... which means you wouldn't have to write a function twice. But it definitely doesn't help compile times.  \n\n### Support Firefox instead\n\nPosted Jun 7, 2024 21:07 UTC (Fri) by **Cyberax** (**✭ supporter ✭**, #52523) \\[[Link](/Articles/977625/)\\\n\\] (8 responses)\n\nI don't believe new browsers make any sense today, except as research items.  \n\nIt would be much better to work with Mozilla to improve Firefox. One thing that's sorely missing is the embedding API. It's dead easy to embed Chromium, and this gives it so much advantage.  \n\n### Support Firefox instead\n\nPosted Jun 8, 2024 8:40 UTC (Sat) by **b7j0c** (subscriber, #27559) \\[[Link](/Articles/977646/)\\\n\\] (7 responses)\n\nI don't know how Kling feels about Mozilla but it is also irrelevant; he is not obligated to support Firefox.  \n\nMozilla as an organization is a spent force. They have jettisoned their primary means for making significant game-changing progress (Rust/Servo) and are instead just managing the inertia of their uncompetitive, aged, dying platform.  \n\nMozilla squandered their future in exchange for shallow activism. Did any of their activist goals actually achieve anything other than me-too virtue signalling? I see a decade+ of superficial, low/zero impact activism while Chrome basically ate their entire market share.  \n\nKling is doing us a favor by paving the way for a post-Mozilla future.  \n\n### Support Firefox instead\n\nPosted Jun 8, 2024 12:05 UTC (Sat) by **roc** (subscriber, #30627) \\[[Link](/Articles/977652/)\\\n\\] (6 responses)\n\nFrom a technical point of view Firefox is still very competitive with Chrome. Certainly far more competitive than Ladybird has any hope of ever being.  \n\nI just watched a video on a streaming service. That's basic functionality normal users require. To get that to work well you need a ton of stuff, including  \n\\-- <video> support, including the related DOM APIs  \n\\-- Integration with modern A/V codecs  \n\\-- Integration with hardware-accelerated decoding, where available  \n\\-- Support for Media Source Extensions  \n\\-- Support for EME  \n\\-- Reliable A/V sync  \n\\-- GPU-accelerated rendering  \n\\-- Off-main-thread compositing  \n\\-- Integration with the system compositor framework, where available (to minimize power usage)  \n(I'm sure I missed some stuff, it's been a while.)  \n\nTo be competitive with modern browsers on security you need to have the site JS+CSS+HTML in its own sandboxed process. GPU rendering and A/V decoding need to be in separate sandboxed processes (could be the same process in a pinch).  \n\nFirefox does this all very well. It took many talented engineers (and me) years to build and a lot more work to maintain since then. Maybe Mozilla is a spent force --- I hope not --- but don't underestimate what they had and still have, and how difficult it will be for a new project to even catch up to where they are now.  \n\n### Support Firefox instead\n\nPosted Jun 8, 2024 13:10 UTC (Sat) by **PengZheng** (subscriber, #108006) \\[[Link](/Articles/977656/)\\\n\\]\n\nAgree.  \n\n\\> A user asked on June 6 what would determine whether a component would be developed in-house versus using a third-party library. Kling responded that if it implements a web standard, \"i.e DOM, HTML, JavaScript, CSS, Wasm, etc. then we build it in house.\"  \n\nAs a developer familiar with multimedia streaming, I would say even re-implementing WebRTC alone will be a huge challenge for the small team.  \n\nSeriously, calling Firefox a dying platform will not add one's own value, it just pisses out faithful users of Firefox (there are a LOT here on LWN).  \n\n### Support Firefox instead\n\nPosted Jun 8, 2024 17:44 UTC (Sat) by **cytochrome** (subscriber, #58718) \\[[Link](/Articles/977662/)\\\n\\]\n\nI agree wholeheartedly. I find that Firefox (plus add-ons) satisfies all of my browsing and privacy needs. Thank you to @roc and the other talented software engineers for their hard work in developing and sustaining the application. I have tried to do my small part by donating to the cause several times.  \n\n### Support Firefox instead\n\nPosted Jun 9, 2024 8:55 UTC (Sun) by **roc** (subscriber, #30627) \\[[Link](/Articles/977690/)\\\n\\] (3 responses)\n\nThis inspired me to write a blog post about building a new browser engine. [https://robert.ocallahan.org/2024/06/browser-engine.html](https://robert.ocallahan.org/2024/06/browser-engine.html)\n  \n\n### Support Firefox instead\n\nPosted Jun 15, 2024 2:06 UTC (Sat) by **himi** (subscriber, #340) \\[[Link](/Articles/978509/)\\\n\\] (2 responses)\n\nNot that I'm planning to build a browser engine (for profit or itch-scratching - I'm not insane), but that's a nice description of the complexity of the modern browser environment - it's easily the most complex single piece of software on human-focused general purpose devices, and it's probably the most critical piece of software on those devices. The fact that Mozilla have been able to keep Firefox genuinely competitive with Chrome is a real achievement, anyone targeting that level of functionality from scratch is facing a truly massive battle just to get to the starting line.  \n\nThat said, something that targets the Electron niche (and does it well enough) likely has a lot of legs. Definitely still an uphill battle, but far less of one than targeting a full browser . . .  \n\n### Support Firefox instead\n\nPosted Jun 15, 2024 2:27 UTC (Sat) by **Cyberax** (**✭ supporter ✭**, #52523) \\[[Link](/Articles/978511/)\\\n\\]\n\nThere are projects in this area, like HTMLayout (now [https://sciter.com/](https://sciter.com/)\n ). It was done by a single person, and back in 2000-s quite a few widely used Windows programs had UI built using it.  \n\nSomething like this would be extremely useful. Not a full browser engine, but a subset for UIs.  \n\n### Support Firefox instead\n\nPosted Jun 15, 2024 14:02 UTC (Sat) by **Wol** (subscriber, #4433) \\[[Link](/Articles/978526/)\\\n\\]\n\nMy immediate reaction to this is the web browser is trying to be the new Emacs - all it needs is some hardware to run on, it does everything else.  \n\nBut seriously, to what extent is that the modern paradigm nowadays - the browser is the OS that runs your programs, and linux and Windows are just glorified hardware abstraction layers. For many people - especially at work - that is now not far from the reality ...  \n\nCheers,  \nWol  \n\n### Comparisons to Firefox/Chrome seem premature\n\nPosted Jun 7, 2024 21:19 UTC (Fri) by **flussence** (subscriber, #85566) \\[[Link](/Articles/977623/)\\\n\\]\n\nMost of these alternative browsers fall into a gravity well of being a clone of Firefox 0.6, both in terms of capability and UI, and usually give up there after a period of stagnation. I would like to see something break the curse some day but I've been disappointed too many times to get excited at this point.  \n\n### Quixotic\n\nPosted Jun 7, 2024 22:07 UTC (Fri) by **roc** (subscriber, #30627) \\[[Link](/Articles/977628/)\\\n\\] (1 responses)\n\nSounds like fun, but to build a browser engine that is useful to the masses is going to take them infinitely long. (Literally; the work that needs to be done is growing faster than a handful of developers can do it.)  \n\nAlso, if you're not just doing it for fun, then to justify starting from near-scratch you should make some fundamental decisions differently from the existing engines. Building with Rust would be a good one, but apparently that's not it. Building in site isolation from the ground up (i.e. IFRAMEs in their own processes) would be a good one, but they're not doing that AFAICT. Going all-in on parallelism would be another interesting one but I don't see that either. The only answer here that I can see in interviews with Kling is that Ladybird is designed to hew close to the architecture of the specifications, which is good but not much.  \n\n### Quixotic\n\nPosted Jun 10, 2024 3:23 UTC (Mon) by **raven667** (subscriber, #5198) \\[[Link](/Articles/977726/)\\\n\\]\n\nIt may be quixotic but having someone new attempt to re-implement this stuff from scratch may help better document the actual effort involved in making a working implementation of these standards and what is required to make them fast, which isn't necessarily visible when an existing browser maker with an existing browser engine architecture and existing expert developers, who may have helped write the standard, does it because so much of the surrounding work the standard depends on already exists. If they want to build this for fun and patrons want to fund it for the entertainment value, then so be it, I wish them the best of luck and most success.  \n\n### Crashing is not necessarily a bad omen\n\nPosted Jun 7, 2024 22:18 UTC (Fri) by **cesarb** (subscriber, #6266) \\[[Link](/Articles/977629/)\\\n\\] (8 responses)\n\n\\> However, it doesn't seem to suffice to keep a single page from crashing the browser entirely. That's to be expected from a project that's still considered pre-alpha, though.  \n\nI still remember using the single-digit milestone releases of Mozilla Suite (according to [https://en.wikipedia.org/wiki/History\\_of\\_Mozilla\\_Applicat...](https://en.wikipedia.org/wiki/History_of_Mozilla_Application_Suite)\n this was back in 1999). Each page I loaded had a chance of crashing the whole browser, and that chance increased dramatically if I used more than one browser window (there were no browser tabs back then). It was fun. I stuck with it, later switching to its descendant Phoenix/Firebird/Firefox, which I still use to this day.  \n\nThat is, history shows that crashing often, this early in the project's life, does not mean the project is going to fail.  \n\n### Crashing is not necessarily a bad omen\n\nPosted Jun 8, 2024 6:43 UTC (Sat) by **joib** (subscriber, #8541) \\[[Link](/Articles/977643/)\\\n\\]\n\nWell, back then netscape/mozilla/firefox was about the only decent(ish) alternative to IE, so you didn't have much alternative. Today you can switch to Firefox, Chrome, or a plethora of Chrome /webkit based browsers. So the bar for what people consider a MVP is much higher.  \n\n### Crashing is not necessarily a bad omen\n\nPosted Jun 10, 2024 7:16 UTC (Mon) by **edeloget** (subscriber, #88392) \\[[Link](/Articles/977728/)\\\n\\] (4 responses)\n\nAnd to be honest, this was a time when we routinely rebooted the whole PC multiple times per day, so having a crash on a web browser, while annoying, was kind of expected :)  \n\n### Crashing is not necessarily a bad omen\n\nPosted Jun 10, 2024 11:25 UTC (Mon) by **cesarb** (subscriber, #6266) \\[[Link](/Articles/977738/)\\\n\\] (3 responses)\n\n\\> And to be honest, this was a time when we routinely rebooted the whole PC multiple times per day,  \n\nThis was also a time when people bragged on slashdot about their Linux uptime. Rebooting the whole PC multiple times per day was IIRC more of a Windows thing back then; I was surprised when once I somehow managed to kernel panic Linux by doing something as simple as removing a floppy disk which was in use.  \n\n\\> so having a crash on a web browser, while annoying, was kind of expected :)  \n\nThis, on the other hand, was IIRC more common, even in non-alpha browsers like the pre-open-sourcing Netscape Navigator 4.x. But they were not so unstable that one would be afraid to open more than one window at the same time, for fear of a crash closing all open browser windows.  \n\n### Crashing is not necessarily a bad omen\n\nPosted Jun 10, 2024 12:25 UTC (Mon) by **geert** (subscriber, #98403) \\[[Link](/Articles/977741/)\\\n\\] (1 responses)\n\nexport MALLOC\\_CHECK=0  \nnetscape  \n\n### Crashing is not necessarily a bad omen\n\nPosted Jun 10, 2024 12:32 UTC (Mon) by **khim** (subscriber, #9252) \\[[Link](/Articles/977742/)\\\n\\]\n\nThere was a way to attach [Boehm GC](https://en.wikipedia.org/wiki/Boehm_garbage_collector)\n to it, if I remember correctly.\n\nThat was more stable.\n\n### Crashing is not necessarily a bad omen\n\nPosted Jun 14, 2024 23:28 UTC (Fri) by **ssmith32** (subscriber, #72404) \\[[Link](/Articles/978504/)\\\n\\]\n\nUptime on servers, sure.  \nUptime for the kernel was pretty good on desktops.  \n\nBut I remember being pretty handy with alt-shift-F1 and alt-shift-backspace, or whatever the hotkeys were to get to the virtual consoles and hard-kill X.  \n\nAnd X dying was almost as bad as a full reboot for a desktop where apps didn't do a terribly good job with checkpoints and session restores.  \n\nSo, while restarts and blue screens and corrupted data is what moved me off of Windows in the early 2000s, the Linux Desktop was not nearly as stable as it is today.  \n\nNowadays, I had one desktop issue in the past few years, and I had System76 support figure out the issue and send me a new driver (which weirdly was triggered by using Google Maps in Firefox). Worlds better than when I was running a Mandrake (RPM) Frankenstein where half the software was compiled from tarballs because the RPMs available were woefully out of date..  \n\n### Crashing is not necessarily a bad omen\n\nPosted Jun 10, 2024 19:56 UTC (Mon) by **parametricpoly** (subscriber, #143903) \\[[Link](/Articles/977829/)\\\n\\] (1 responses)\n\nProgramming languages have improved quite a bit since 1990s. It's really no wonder it crashes it they chose C++. Using C++ here again is a waste of talent. Heck they could have picked Java instead. Java 22 is already pretty decent and more goodies will arrive in the LTS 24 release.  \n\n### Crashing is not necessarily a bad omen\n\nPosted Jun 13, 2024 5:40 UTC (Thu) by **ceplm** (subscriber, #41334) \\[[Link](/Articles/978219/)\\\n\\]\n\nHow is Rhino doing these days? Is it already in the same speed rank as other major JavaScript engines?  \n\nActually, surprisingly, it is still alive. That’s more than I expected.  \n\n### Future?\n\nPosted Jun 8, 2024 15:45 UTC (Sat) by **drago01** (subscriber, #50715) \\[[Link](/Articles/977660/)\\\n\\]\n\nDoes this have any futute other than being a \"toy\" project?  \n\nIt doesn't do anything new or different to attract enough attention to compete with Chromium or Firefox.  \n\n### Why \\*not\\*?\n\nPosted Jun 8, 2024 16:45 UTC (Sat) by **rsidd** (subscriber, #2582) \\[[Link](/Articles/977661/)\\\n\\] (3 responses)\n\nI don't get all these comments about \"why work on this\". Because they want to, that's why. And SerenityOS seems much less relevant or useful to the wider world but that's where it started and that's an itch Kling wanted to scratch. Good for him. Both projects seem to have built a substantial community so it's not just him.  \n\nIt's pretty impressive what Ladybird has achieved, and there's no reason to think it won't be 10× more useful a year from now even if it lags Chrome and Firefox in some respects. But even if not, this is what they want to do, good luck to them.  \n\nAnd it's false logic to say they should just work on firefox. That's not how \"scratch an itch\" works.  \n\nActually, given the change in policy that they will not DIY everything but accept some NIH code where useful, I expect the next 12 months to be pretty interesting.  \n\n### Why \\*not\\*?\n\nPosted Jun 9, 2024 4:58 UTC (Sun) by **chris\\_se** (subscriber, #99706) \\[[Link](/Articles/977683/)\\\n\\] (2 responses)\n\nI completely agree with you.  \n\nFor that matter, I believe that the current browser ecosystem is not healthy at all: you have Chrome (+ all its derivatives), and Firefox (+ its derivatives), and then some niche projects. And while derivatives of Chrome make some changes, they will not diverge significantly from the actual browsing engine, so in the end, Google is the only one that determines what's next in terms of browser engine development, regardless of whether you use Edge, Chrome, Chromium, Opera, ... The only usable alternative right now is Firefox, but they are not the ones driving innovation in that space at the moment, unfortunately. (Which is a real shame, I like Firefox.)  \n\nSo in that sense I welcome people being excited and working on alternatives, such as Servo, Ladybird, and others. Because I don't want to be in the situation where the entire future of the web is basically in the hands of a single company, and even if I don't end up using them myself for whatever reason, if they do thrive, they will bring a breath of fresh air into the web ecosystem, which is sorely needed in my opinion.  \n\n### Why \\*not\\*?\n\nPosted Jun 9, 2024 14:44 UTC (Sun) by **rgmoore** (**✭ supporter ✭**, #75) \\[[Link](/Articles/977701/)\\\n\\] (1 responses)\n\nThe current browser ecosystem is unhealthy because Google sees Chrome as a means to maintain its dominant market position in the lucrative search and online advertising businesses. They use their money from search and ads to squeeze profits out of the browser market and make it effectively impossible for anyone to make money by developing a competing browser from scratch. It's basically the IE situation from the late '90s all over again, and it won't improve until some government steps up antitrust enforcement the way the USA did in the '90s.\n\n### Chromium is a browser consortium lead by Google\n\nPosted Jun 10, 2024 3:37 UTC (Mon) by **raven667** (subscriber, #5198) \\[[Link](/Articles/977727/)\\\n\\]\n\nOne important distinction from the bad old MSIE days is that Chromium is open source, not private/proprietary like MSIE, and acts as a reference implementation of a multi-vendor platform designed by consortium that includes competitors Google and MS (lead by Google) and separately with their own engines Apple and Mozilla, in some ways no different than Linux being developed as a shared project by many competing companies (although for Linux the consortium/trade org LF operates for \\_all\\_ vendors so there is no \\_one\\_ lead vendor) along side the similar BSDs with their own base OS funded by Apple and other vendors. The mechanisms and possibilities for \"lock-in\" are very different than before.  \n\n  \n\nCopyright © 2024, Eklektix, Inc.  \nThis article may be redistributed under the terms of the [Creative Commons CC BY-SA 4.0](http://creativecommons.org/licenses/by-sa/4.0/)\n license  \nComments and public postings are copyrighted by their creators.  \nLinux is a registered trademark of Linus Torvalds",
		"html": "<!DOCTYPE html><html lang=\"en\">\n        <body>\n        <a name=\"t\"></a>\n<div id=\"menu\"><a href=\"/\"><img src=\"https://static.lwn.net/images/logo/barepenguin-70.png\" class=\"logo\" border=\"0\" alt=\"LWN.net Logo\">\n           <span class=\"logo\">LWN<br>.net</span>\n           <span class=\"logobl\">News from the source</span></a>\n           <a href=\"/\"><img src=\"https://static.lwn.net/images/lcorner-ss.png\" class=\"sslogo\" border=\"0\" alt=\"LWN\"></a><div class=\"navmenu-container\">\n           <ul class=\"navmenu\">\n        <li><a class=\"navmenu\" href=\"#t\"><b>Content</b></a><ul><li><a href=\"/current/\">Weekly Edition</a></li><li><a href=\"/Archives/\">Archives</a></li><li><a href=\"/Search/\">Search</a></li><li><a href=\"/Kernel/\">Kernel</a></li><li><a href=\"/Security/\">Security</a></li><li><a href=\"/Calendar/\">Events calendar</a></li><li><a href=\"/Comments/unread\">Unread comments</a></li><li><hr></li><li><a href=\"/op/FAQ.lwn\">LWN FAQ</a></li><li><a href=\"/op/AuthorGuide.lwn\">Write for us</a></li></ul></li>\n<li><a class=\"navmenu\" href=\"#t\"><b>Edition</b></a><ul><li><a href=\"/Articles/977366/\">Return to the Front page</a></li></ul></li>\n</ul></div>\n</div> <!-- menu -->\n<div class=\"not-handset\" style=\"margin-left: 10.5em; display: block;\">\n                   <div class=\"not-print\"> <div id=\"azk13321_leaderboard\"></div> </div>\n                </div>\n            <div class=\"topnav-container\">\n<div class=\"not-handset\"><form action=\"https://lwn.net/Login/\" method=\"post\" name=\"loginform\" class=\"loginform\">\n        <label><b>User:</b> <input type=\"text\" name=\"Username\" value=\"\" size=\"8\" id=\"uc\"></label> \n\t\t<label><b>Password:</b> <input type=\"password\" name=\"Password\" size=\"8\" id=\"pc\"></label> <input type=\"hidden\" name=\"target\" value=\"/Articles/976822/\"> <input type=\"submit\" name=\"submit\" value=\"Log in\"></form> |\n           <form action=\"https://lwn.net/subscribe/\" method=\"post\" class=\"loginform\">\n           <input type=\"submit\" name=\"submit\" value=\"Subscribe\">\n           </form> |\n           <form action=\"https://lwn.net/Login/newaccount\" method=\"post\" class=\"loginform\">\n           <input type=\"submit\" name=\"submit\" value=\"Register\">\n           </form>\n        </div>\n               <div class=\"handset-only\">\n               <a href=\"/subscribe/\"><b>Subscribe</b></a> /\n               <a href=\"/Login/\"><b>Log in</b></a> /\n               <a href=\"/Login/newaccount\"><b>New account</b></a>\n               </div>\n               </div><div class=\"maincolumn flexcol\">\n<div class=\"middlecolumn\">\n<div class=\"PageHeadline\">\n<h1>Ladybird browser spreads its wings</h1>\n</div>\n<div class=\"ArticleText\">\n<center>\n           <table class=\"Form\" width=\"60%\">\n           <tbody><tr><td><b>This article brought to you by LWN subscribers</b><p>Subscribers to LWN.net made this article — and everything that\n       surrounds it — possible.  If you appreciate our content, please\n       <a href=\"/subscribe/\">buy a subscription</a> and make the next\n       set of articles possible.</p></td></tr>\n           </tbody></table>\n           </center>\n           <p>\n           </p><div class=\"FeatureByline\">\n           By <b>Joe Brockmeier</b><br>June 7, 2024\n           </div>\n<p><a href=\"https://ladybird.dev/\">Ladybird</a> is an open-source\nproject aimed at building an independent web browser, rather than\nyet another browser based on Chrome. It is written in C++ and licensed under a\ntwo-clause BSD license. The effort \nbegan as part of the <a href=\"https://www.serenityos.org/\">SerenityOS</a> project, but\ndeveloper Andreas Kling <a href=\"https://awesomekling.substack.com/p/forking-ladybird-and-stepping-down-serenityos\">announced</a>\non June&nbsp;3 that he was \"forking\" Ladybird as a separate project and stepping away from\nSerenityOS to focus his attention on the browser completely. Ladybird\nis not ready to replace Firefox or Chrome for regular use, but it is showing\ngreat promise.</p>\n\n<p>Kling started working on SerenityOS in 2018 as a therapy project\nafter completing a substance-abuse rehabilitation program. The SerenityOS name is a\nnod to the <a href=\"https://en.wikipedia.org/wiki/Serenity_Prayer\">serenity\nprayer</a>. Prior to working on the project, he had worked on\nWebKit-based browsers at Apple and Nokia. Eventually he <a href=\"https://awesomekling.github.io/I-quit-my-job-to-focus-on-SerenityOS-full-time/\">made\nSerenityOS his full-time job</a>, and funded the work through\ndonations, sales of SerenityOS merchandise, and income from\nYouTube. (Kling posts monthly updates to his <a href=\"https://www.youtube.com/@awesomekling/videos\">YouTube\nchannel</a> about Ladybird, as well as hacking videos where he walks\nthrough working on various components in the browser, such as the <a href=\"https://www.youtube.com/watch?v=8mxubNQC5O8\">JavaScript JIT\ncompiler</a>.)</p>\n\n<h4>Taking flight</h4>\n\n<p>Kling <a href=\"https://awesomekling.substack.com/p/ladybird-a-new-cross-platform-browser-project\">announced</a>\nthe Ladybird project in September 2022. He said that the project\nstarted while creating a Qt GUI for SerenityOS's LibWeb browser\nengine. He decided to target Linux as well as SerenityOS so it would be easier for\npeople to work on and debug while in Linux. In the post announcing his\nintent to work solely on Ladybird, he noted that he had been focusing\nall of his attention on the Linux version of Ladybird. With that\nrealization, he decided to step down as \"benevolent dictator for\nlife\" (BDFL) of SerenityOS so its development would not be held back:</p>\n\n<blockquote class=\"bq\">\nBefore anyone asks, there is no drama behind this change. It's simply\nrecognizing that there have been two big projects packed uncomfortably\ninto a single space for too long, and I'm doing what I believe will\nmake life better for everyone involved.\n</blockquote>\n\n<p>Ladybird's governance is similar to SerenityOS. Kling is the\nBDFL, with a group of maintainers (currently ten) who can\napprove and merge pull requests. The <a href=\"https://github.com/LadybirdWebBrowser/ladybird/blob/master/CONTRIBUTING.md\">contributing</a>\nguide notes that maintainership is \"<q>by invitation only and does not\ncorrelate with any particular metric</q>\". Project development\ndiscussions are held on a <a href=\"https://discord.com/invite/nvfjVJ4Svh\">Discord server</a>\n(account required).</p>\n\n<p>Now independent, Ladybird has dropped SerenityOS as a development\ntarget, and has moved to <a href=\"https://github.com/LadybirdWebBrowser/ladybird\">its own GitHub\nrepository</a>. In addition, Kling has relaxed his self-imposed policy\nof excluding \"not invented here\" (NIH) code that had applied to SerenityOS, which\nmeans that the Ladybird project will be able to make use of existing\nlibraries rather than writing from scratch.</p>\n\n<p>Comparing the <a href=\"https://github.com/LadybirdWebBrowser/ladybird/blob/master/README.md\">README</a> file in the standalone Ladybird repository\nagainst the <a href=\"https://github.com/SerenityOS/serenity/blob/master/Ladybird/README.md\">README</a>\nfile in the SerenityOS repository, the goal has\nevolved from creating \"<q>a standards-compliant, independent web browser with\nno third-party dependencies</q>\" to developing an independent browser \"<q>using a\nnovel engine based on web standards</q>\".</p>\n\n<p>The changes to the section that enumerates the core libraries for Ladybird \nprovide some hints about Kling's plans\nto use existing libraries rather than continuing to reinvent the\nwheel. The core support libraries for the project include homegrown\nlibraries for cryptography, TLS, 2D-graphics rendering, archive-file\nformat support, Unicode, as well as audio and video playback.\nIn the pre-fork documentation, they are described\nas alternatives to other software. For example, Ladybird's TLS (LibTLS)\nand cryptography (LibCrypto) libraries are \"<q>Cryptography primitives\nand Transport Layer Security (rather than OpenSSL)</q>\". The \"rather\nthan\" language has been removed in the journey to the standalone\nrepository, and the LibSQL library from SerenityOS has <a href=\"https://github.com/LadybirdWebBrowser/ladybird/commit/8362c073f34f25ef2fbe800780f4b8790b3fffa8\">already\nbeen stripped out</a> in favor of sqlite3.</p>\n\n<p>In a discussion in the project's Discord instance on June&nbsp;5, Kling indicated that font rendering\nwould likely be replaced with a third-party library. A user asked on\nJune&nbsp;6 what would determine whether a component would be developed in-house versus\nusing a third-party library. Kling responded that if it implements a web\nstandard, \"i.e DOM, HTML, JavaScript, CSS, Wasm, etc. then we build it\nin house.\" Otherwise, the project would look to alternatives \"unless we\nbelieve we can build something better ourselves\".</p>\n\n<h4>Status</h4>\n\n<p>Ladybird is still in early development (\"pre-alpha\") today. It\ncurrently runs on Linux, macOS, and other\nUNIX-like operating systems. It's also possible to use on Windows with\nWindows Subsystem for Linux (WSL) version&nbsp;2, but there appears to\nbe no effort to target Windows independently at this time. At the\nmoment, the project does not provide binaries for any\nplatform. Interested users will need to grab the source and follow the\n<a href=\"https://github.com/LadybirdWebBrowser/ladybird/blob/master/Documentation/BuildInstructionsLadybird.md\">build\ninstructions</a>. Users will need GCC&nbsp;13+ or Clang&nbsp;17, and Qt6\ndevelopment packages to play along at home. Ladybird compiles and runs\non, for example, Fedora&nbsp;40 without a problem, but it is a long\nway from being suitable for regular use.</p>\n\n<blockquote>\n<a href=\"/Articles/977492/\"><img src=\"https://static.lwn.net/images/2024/ladybird-sm.png\" alt=\"[Ladybird browser with inspector]\" title=\"Ladybird browser with inspector\" class=\"photo\"></a>\n</blockquote>\n\n<p>One might expect that the browser\nwould be more usable with sites with simpler layouts and little to no JavaScript\n(e.g. LWN) than those with complex layouts and a fair amount of\nJavaScript (e.g. GitHub). However, this isn't always the case—Ladybird\nrendered GitHub and many other sites well, if slowly. Browsing\nLWN anonymously worked well, but logging into LWN,\nhowever, consistently proved to be too much for the\napplication. Each time, it basically froze on the front page and clicking links to\narticles did nothing.</p>\n\n<p>Somewhat ironically, it was not possible to log\ninto Discord using Ladybird. It does a fair\njob of rendering pages, but speed and stability are\nstill wanting. Each Ladybird tab has its own render process, which is\nsandboxed as a security measure to prevent any malicious pages from\naffecting the rest of the system. However, it doesn't seem to suffice\nto keep a single page from crashing the browser entirely. That's to be\nexpected from a project that's still considered pre-alpha, though.</p>\n\n<p>The current feature set is, not surprisingly, minimal. Ladybird has\na URL/search bar, reload, tabs, can zoom in/out on content, take\nscreenshots, and (of course) has backward and forward navigation. It\ndoes not, however, have bookmarks, a history display, extensions,\npassword management, printing, or even the ability to save an\nimage. WebRTC does not seem to be supported yet. CSS support seems\nrelatively robust. Ladybird passes 100% of the CSS Selectors tests for\nlevels 1-3, for example, using <a href=\"https://css4-selectors.com/browser-selector-test/\">this\ntest</a>. It gets a 53% score for level 4, while Firefox gets 71%, so\nnot a terrible showing at all. JavaScript support seems solid, but\nslow: the <a href=\"https://www.w3schools.com/js/js_ex_browser.asp\">examples\nhere</a> work, but they load slowly.</p>\n\n<p>On the other hand, Ladybird does have tools for developers, such as\ninspectors for the document object model (DOM) tree and accessibility\ntrees, as well as the ability to create dumps of various things:\nthe DOM tree and layout tree, computed styles, and so forth. It also\nhas the ability to spoof the User-Agent sent by the browser so that testers\ncan try to get around sites that refuse to work with \"unknown\"\nbrowsers. However, toggling the User-Agent wasn't enough to get\npast Google's gatekeeping to sign into Gmail—but it's unclear if\nthat meant Ladybird wasn't sending the string correctly or if Google\nis using other means to fingerprint non-approved browsers.</p>\n\n<p>Suffice it to say, Ladybird is not ready for mainstream use but it\n<em>does</em> show potential. In the past month, the project has had\nmore than 880 commits from 49 authors. If the project maintains that\nkind of momentum, or picks up steam, it could become a usable\nalternative to mainstream browsers before too long.</p><br clear=\"all\"><hr width=\"60%\" align=\"left\">\n           (<a href=\"https://lwn.net/Login/?target=/Articles/976822/\">Log in</a> to post comments)\n           <p>\n           \n</p></div> <!-- ArticleText -->\n<p><a name=\"Comments\"></a>\n<a name=\"CommAnchor977612\"></a>\n    </p><details class=\"CommentBox\" open=\"\">\n      <summary><h3 class=\"CommentTitle\">Congratulations</h3>\n      <p class=\"CommentPoster\"> Posted Jun 7, 2024 18:50 UTC (Fri)\n                               by <b>riking</b> (subscriber, #95706)\n                              [<a href=\"/Articles/977612/\">Link</a>] \n      </p></summary>\n     <div class=\"FormattedComment\">\nCongratulations on what sounds like will be a successful community split. Always tough to do1<br>\n</div>\n\n     \n  <div class=\"CommentReplyButton\">\n    <form action=\"/Articles/977612/comment\" method=\"post\">\n      <input type=\"submit\" value=\"Reply to this comment\">\n    </form>\n  </div>\n\n     <p>\n     \n    </p></details>\n<a name=\"CommAnchor977610\"></a>\n    <details class=\"CommentBox\" open=\"\">\n      <summary><h3 class=\"CommentTitle\">Where is this going to be 10 years from now?</h3>\n      <p class=\"CommentPoster\"> Posted Jun 7, 2024 19:04 UTC (Fri)\n                               by <b>python</b> (subscriber, #171317)\n                              [<a href=\"/Articles/977610/\">Link</a>] (14 responses)\n      </p></summary>\n     <div class=\"FormattedComment\">\nI am waiting for the day that we see a serious attempt at a browser written in rust. I fear that it might be uneconomical to develop a modern browser in \"lower level\" languages like C++. Valgrind/AddressSanitizer/UndefinedBehaviorSanitizer is no substitute for automated rigorous (mathematically proven) enforcement of program structure/logic/soundness by the compiler. Not to mention the friction posed by not having easy, immediate, access to the sort of ecosystem of third party libraries that we see with npm or cargo.<br>\n<p>\nI looked at the source code for LadyBird and I am surprised that they are not using C++20 modules (it's been supported by clang for 5 years). I always found maintaining header files (eg. having to write the function definitions twice, once in the .h and once in the .cpp file, etc.) to be a great bother. I can only assume they have much more pressing issues like implementing missing features and trying to comply with all of the modern web standards.<br>\n</p><p>\nAs I've watched Firefox, and Microsoft try to compete with Chrome - I find it progressively more difficult to get excited about attempts at new browsers when there appears to be nothing terribly new or innovative about how or what they are trying to achieve. It's a lot of work to build even a small portion of the machinery underlying a web browser like Firefox or Chrome. It will probably take a decade for something like LadyBird to be competitive (assuming that the web \"remains still enough\" to catch up). I fear that they might get mired down in the complexity of what they are trying to achieve (with their chosen tools, and limited manpower) before they ever reach that goal.<br>\n</p></div>\n\n     \n  <div class=\"CommentReplyButton\">\n    <form action=\"/Articles/977610/comment\" method=\"post\">\n      <input type=\"submit\" value=\"Reply to this comment\">\n    </form>\n  </div>\n\n     <p>\n     \n    <a name=\"CommAnchor977614\"></a>\n    </p><details class=\"CommentBox\" open=\"\">\n      <summary><h3 class=\"CommentTitle\">Where is this going to be 10 years from now?</h3>\n      <p class=\"CommentPoster\"> Posted Jun 7, 2024 19:11 UTC (Fri)\n                               by <b>atai</b> (subscriber, #10977)\n                              [<a href=\"/Articles/977614/\">Link</a>] (1 responses)\n      </p></summary>\n     <div class=\"FormattedComment\">\nA suggestion for you: write a browser in Python.   It is surprising in your comment that the world Python appeared only once: in your name<br>\n</div>\n\n     \n  <div class=\"CommentReplyButton\">\n    <form action=\"/Articles/977614/comment\" method=\"post\">\n      <input type=\"submit\" value=\"Reply to this comment\">\n    </form>\n  </div>\n\n     <p>\n     \n    <a name=\"CommAnchor977659\"></a>\n    </p><details class=\"CommentBox\" open=\"\">\n      <summary><h3 class=\"CommentTitle\">Where is this going to be 10 years from now?</h3>\n      <p class=\"CommentPoster\"> Posted Jun 8, 2024 15:13 UTC (Sat)\n                               by <b>ejr</b> (subscriber, #51652)\n                              [<a href=\"/Articles/977659/\">Link</a>] \n      </p></summary>\n     <div class=\"FormattedComment\">\nThat would take Python full circle, particularly if you called it something related to Grail.<br>\n</div>\n\n     \n  <div class=\"CommentReplyButton\">\n    <form action=\"/Articles/977659/comment\" method=\"post\">\n      <input type=\"submit\" value=\"Reply to this comment\">\n    </form>\n  </div>\n\n     <p>\n     \n    </p></details>\n</details>\n<a name=\"CommAnchor977616\"></a>\n    <details class=\"CommentBox\" open=\"\">\n      <summary><h3 class=\"CommentTitle\">Where is this going to be 10 years from now?</h3>\n      <p class=\"CommentPoster\"> Posted Jun 7, 2024 19:39 UTC (Fri)\n                               by <b>willy</b> (subscriber, #9762)\n                              [<a href=\"/Articles/977616/\">Link</a>] (2 responses)\n      </p></summary>\n     <div class=\"FormattedComment\">\nIt's funny you say that, given that Rust started as a Mozilla project.<br>\n<p>\n<a href=\"https://wiki.mozilla.org/Oxidation\">https://wiki.mozilla.org/Oxidation</a><br>\n</p><p>\nis a bit outdated (not modified in 4 years) but clearly shows how Firefox is being gradually rewritten in Rust.<br>\n</p></div>\n\n     \n  <div class=\"CommentReplyButton\">\n    <form action=\"/Articles/977616/comment\" method=\"post\">\n      <input type=\"submit\" value=\"Reply to this comment\">\n    </form>\n  </div>\n\n     <p>\n     \n    <a name=\"CommAnchor977618\"></a>\n    </p><details class=\"CommentBox\" open=\"\">\n      <summary><h3 class=\"CommentTitle\">Where is this going to be 10 years from now?</h3>\n      <p class=\"CommentPoster\"> Posted Jun 7, 2024 19:47 UTC (Fri)\n                               by <b>atnot</b> (subscriber, #124910)\n                              [<a href=\"/Articles/977618/\">Link</a>] \n      </p></summary>\n     <div class=\"FormattedComment\">\nThere's also servo, which is alive again now, albeit with new goals (serving as an embedded web engine for embedded devices and things people might use Electron for today)<br>\n</div>\n\n     \n  <div class=\"CommentReplyButton\">\n    <form action=\"/Articles/977618/comment\" method=\"post\">\n      <input type=\"submit\" value=\"Reply to this comment\">\n    </form>\n  </div>\n\n     <p>\n     \n    </p></details>\n<a name=\"CommAnchor977688\"></a>\n    <details class=\"CommentBox\" open=\"\">\n      <summary><h3 class=\"CommentTitle\">Where is this going to be 10 years from now?</h3>\n      <p class=\"CommentPoster\"> Posted Jun 9, 2024 7:23 UTC (Sun)\n                               by <b>dilinger</b> (subscriber, #2867)\n                              [<a href=\"/Articles/977688/\">Link</a>] \n      </p></summary>\n     <div class=\"FormattedComment\">\nChromium is also having components rewritten in rust. As of chromium 120, rustc is now required for building it, and they've started dropping c++ code.<br>\n</div>\n\n     \n  <div class=\"CommentReplyButton\">\n    <form action=\"/Articles/977688/comment\" method=\"post\">\n      <input type=\"submit\" value=\"Reply to this comment\">\n    </form>\n  </div>\n\n     <p>\n     \n    </p></details>\n</details>\n<a name=\"CommAnchor977621\"></a>\n    <details class=\"CommentBox\" open=\"\">\n      <summary><h3 class=\"CommentTitle\">C++20 module misconception clearing</h3>\n      <p class=\"CommentPoster\"> Posted Jun 7, 2024 20:34 UTC (Fri)\n                               by <b>mathstuf</b> (subscriber, #69389)\n                              [<a href=\"/Articles/977621/\">Link</a>] (5 responses)\n      </p></summary>\n     <div class=\"FormattedComment\">\n<span class=\"QuotedText\">&gt; I looked at the source code for LadyBird and I am surprised that they are not using C++20 modules (it's been supported by clang for 5 years).</span><br>\n<p>\nClang has not supported C++20 modules for 5 years. 2 is probably more accurate. MSVC is probably close to 3. You're thinking of \"Clang modules\", which served as a prototype for C++20's modules, but not what got standardized (standard modules scale far better according to (ISO-)reported benchmarks). Even with that, (released) build system support for C++20 modules only landed in CMake of October 2023 (FD: I'm the main developer of that support). Now that it does exist, I expect many issues to need fixing over the next few years before it is \"battle hardened\". Other build systems do have support (build2, xmake), but others are still pending (Meson) or have no known progress (autotools, Tup).<br>\n</p><p>\nFWIW, I had a prototype that worked with CMake and GCC (both locally patched) in 2019, but what landed is a far better situation than what I had then.<br>\n</p><p>\n<span class=\"QuotedText\">&gt; I always found maintaining header files (eg. having to write the function definitions twice, once in the .h and once in the .cpp file, etc.) to be a great bother.</span><br>\n</p><p>\nSure, you *could* do one-file modules, but build performance will vastly prefer to continue having the split (just now between module interface and implementation units). The main benefit is that you're now in control of what interface you provide consumers via the `export` keyword instead of \"whatever the preprocessor happened to come across\" while you included headers for what you needed as well.<br>\n</p></div>\n\n     \n  <div class=\"CommentReplyButton\">\n    <form action=\"/Articles/977621/comment\" method=\"post\">\n      <input type=\"submit\" value=\"Reply to this comment\">\n    </form>\n  </div>\n\n     <p>\n     \n    <a name=\"CommAnchor977624\"></a>\n    </p><details class=\"CommentBox\" open=\"\">\n      <summary><h3 class=\"CommentTitle\">C++20 module support in build systems</h3>\n      <p class=\"CommentPoster\"> Posted Jun 7, 2024 21:12 UTC (Fri)\n                               by <b>madscientist</b> (subscriber, #16861)\n                              [<a href=\"/Articles/977624/\">Link</a>] (4 responses)\n      </p></summary>\n     <div class=\"FormattedComment\">\nHave people decided on a model for supporting C++ modules in build tools?  This is probably OT for this thread but last time I checked there were two models being considered: either some tool parses the module files and generates module description information, which can then be considered by the build system, which I think is the way CMake has gone (it's good for them because they already have a separate \"configure the build\" step).<br>\n<p>\nThere was also an idea of using an LSP-like model, where a separate server process would keep the module dependency information and respond to requests from clients at runtime.<br>\n</p><p>\nIt seems the first has the most momentum behind it.  Maybe the second idea has fallen by the wayside.<br>\n</p></div>\n\n     \n  <div class=\"CommentReplyButton\">\n    <form action=\"/Articles/977624/comment\" method=\"post\">\n      <input type=\"submit\" value=\"Reply to this comment\">\n    </form>\n  </div>\n\n     <p>\n     \n    <a name=\"CommAnchor977626\"></a>\n    </p><details class=\"CommentBox\" open=\"\">\n      <summary><h3 class=\"CommentTitle\">C++20 module support in build systems</h3>\n      <p class=\"CommentPoster\"> Posted Jun 7, 2024 21:45 UTC (Fri)\n                               by <b>NYKevin</b> (subscriber, #129325)\n                              [<a href=\"/Articles/977626/\">Link</a>] (1 responses)\n      </p></summary>\n     <div class=\"FormattedComment\">\nThe CMake approach you describe sounds a lot like something that already exists for the specific combination of Bazel+Go: <a href=\"https://github.com/bazelbuild/bazel-gazelle\">https://github.com/bazelbuild/bazel-gazelle</a><br>\n<p>\nThe README says it is extensible \"to support new languages and custom rule sets.\" I wonder if it can be extended for C++ modules? Then setting up a C++ project (that uses modules) in Bazel should be much easier.<br>\n</p></div>\n\n     \n  <div class=\"CommentReplyButton\">\n    <form action=\"/Articles/977626/comment\" method=\"post\">\n      <input type=\"submit\" value=\"Reply to this comment\">\n    </form>\n  </div>\n\n     <p>\n     \n    <a name=\"CommAnchor977638\"></a>\n    </p><details class=\"CommentBox\" open=\"\">\n      <summary><h3 class=\"CommentTitle\">C++20 module support in build systems</h3>\n      <p class=\"CommentPoster\"> Posted Jun 8, 2024 3:23 UTC (Sat)\n                               by <b>mathstuf</b> (subscriber, #69389)\n                              [<a href=\"/Articles/977638/\">Link</a>] \n      </p></summary>\n     <div class=\"FormattedComment\">\nBazel support is here (I've given feedback and also managed to have Google reconsider external contributions for it instead of waiting for Google to solve it internally and codedump it on the community years from now): <a href=\"https://github.com/bazelbuild/bazel/pull/19940\">https://github.com/bazelbuild/bazel/pull/19940</a><br>\n<p>\nI can't say it with 100% confidence, but I don't think Gazelle can handle C++ modules reliably with the existing interfaces. See my other reply in this subthread for details on (CMake's) C++ module compilation strategy (to avoid splitting the discussion).<br>\n</p></div>\n\n     \n  <div class=\"CommentReplyButton\">\n    <form action=\"/Articles/977638/comment\" method=\"post\">\n      <input type=\"submit\" value=\"Reply to this comment\">\n    </form>\n  </div>\n\n     <p>\n     \n    </p></details>\n</details>\n<a name=\"CommAnchor977639\"></a>\n    <details class=\"CommentBox\" open=\"\">\n      <summary><h3 class=\"CommentTitle\">C++20 module support in build systems</h3>\n      <p class=\"CommentPoster\"> Posted Jun 8, 2024 4:30 UTC (Sat)\n                               by <b>mathstuf</b> (subscriber, #69389)\n                              [<a href=\"/Articles/977639/\">Link</a>] (1 responses)\n      </p></summary>\n     <div class=\"FormattedComment\">\n<span class=\"QuotedText\">&gt; Have people decided on a model for supporting C++ modules in build tools?</span><br>\n<p>\nThere are 2 plausible strategies AFAIK (\"explicit\" and \"implicit\"). I consider only 1 (\"explicit\") viable in the grand scheme of the state of the C++ ecosystem where even file extensions cannot be agreed upon. There are tradeoffs of each. For CMake, I chose the one that gives the most reliable results with the widest support because I detest tracking down heisenbuild bugs and CMake ends up having to support all kinds of things anyways.<br>\n</p><p>\n<span class=\"QuotedText\">&gt; some tool parses the module files and generates module description information, which can then be considered by the build system, which can then be considered by the build system, which I think is the way CMake has gone (it's good for them because they already have a separate \"configure the build\" step).</span><br>\n</p><p>\nThis is inaccurate. CMake does this during the build, not during \"configure\". If it were done during the configure step, any change to a C++ module-using or -providing source would require a rerun of the configure to update the build graph. Note that it must also be performed at build time in order to support generated sources (that don't exist to scan at configure time). This is obviously not optimal.<br>\n</p><p>\nSome definitions (for clarity):<br>\n</p><p>\n- build system: a model of a project that represents artifacts and the dependencies between them (e.g., CMake, Bazel, Meson)<br>\n- build tool: a tool which executes a DAG representing a build system's actions to perform the necessary (e.g., Bazel, make, ninja)<br>\n- BMI: \"binary module interface\"; a representation of a module interface that is used when importing the module<br>\n- CMI: \"compiled module interface\"; same as BMI; preferred by some because they might not be \"binary\", but ASCII<br>\n- module interface unit: a source file with `export module X;` or `[export] module X:partition;`; may be imported (assuming language and build system visibility rules allow it)<br>\n- module implementation unit: a source file with `module X;` that provides implementations for module interfaces that have `module X` (with or without a partition name; implementation units never mention partitions[0])<br>\n- explicit module build: the compiler is told the exact BMI file to use for each module it reads or writes<br>\n- implicit module build: the compiler is given search paths to look for or to create BMIs by name (note that this includes when a build system just uses the module name as a key to look them up rather than considering the context of the importing source file: is the requested module visible? is it the right configuration?)<br>\n</p><p>\nFor background, this paper[1] I presented to ISO C++ which describes how CMake supports Fortran modules (which are isomorphic to C++ modules for build graph purposes). The core issue is that the module name has no (forced) relation to the filename on disk. So one needs to determine the dependencies between compilations *dynamically*. This is distinct from \"discovered\" dependencies reported by the likes of `-showIncludes` or `-MF` where the files that are discovered during the course of the tool's execution are reported so that if any change, the tool can be reexecuted. The main point here is that they can be discovered during the first execution (since the output doesn't exist, it needs to run anyways). Modules are different because at the point of `import M;` during translation we need the BMI of M to continue compilation as the next line might use a type from that module. The compiler needs to know where that BMI is and is the primary goal of the build system for modules: to provide BMI paths during compilation and ensure they're ready when compiling anything that needs them.<br>\n</p><p>\nDynamic dependencies instead are dependencies between entities expressed in the *content* of the sources and nowhere else. To support this, the contents need to be \"scanned\" to report what is needed during compilation and generated during the compilation of the source itself. This is reported in the P1689R5[2] format that is meant to describe these things. These dependency files (CMake uses the `.ddi` extension: \"dynamic dependency information\") are then given to a \"collator\" that reads them, the collated information of any dependent libraries, and some details from the CMake, to do the following:<br>\n</p><p>\n- see file X makes module P<br>\n- sees file Y needs module P<br>\n- writes out a snippet for the build tool (ninja, make) to learn that Y's object rule depends on X's object rule (this is what the details from CMake are needed for: the collator needs to know the paths ninja knows these things by to make a valid dyndep file)<br>\n- writes out a representation of this information for any dependent libraries so that they may be consumed in other targets as well<br>\n- writes out a \"modmap\" file for each TU saying \"I see you want modules E, F, G; here is the path for those modules *and no others*\" (this is important to avoid accidental/stale module usage; note that Fortran doesn't have this because module files are found via `-I` flags implicitly…I uncovered a lot of issues with that when enforcing C++ strictness on the Fortran stuff in CMake)<br>\n- (there are some other tasks[3], but they're not relevant to the build graph)<br>\n</p><p>\nThere is some flexibility with this model (also covered in the paper):<br>\n</p><p>\n- scan individually or scan in batches?<br>\n- collate separately or after scanning?<br>\n</p><p>\nSmaller scans are better for incremental (developer) builds (e.g., if 20 files are scanned in a batch, changing any one will force scanning of all 20); batching is better for one-shot (CI) builds. Collating after scanning simplifies the tool (the collator doesn't need to understand $LANG syntax), but is probably slower (lots of tiny P1689 files flitting about). CMake currently has individual scans with separate collation. I don't forsee collation being merged into scanning, but an option to batch scans may make sense given performance measurements.<br>\n</p><p>\nRestrictions can also be enforced here. CMake doesn't care about file extensions, basenames matching module names, or anything like that. If one wants to do that (I suspect Meson might do so), that's fine. Configure-time scanning is fine if the configure is fast enough and generated sources (module-providing sources for sure; module-consuming sources may be able to be deferred-scanned, but once you have that support…just simpler to scan everything at build time if you ask me) aren't of any concern.<br>\n</p><p>\n<span class=\"QuotedText\">&gt; There was also an idea of using an LSP-like model, where a separate server process would keep the module dependency information and respond to requests from clients at runtime.</span><br>\n</p><p>\nThis is, AFAIK, what build2 does (it is a build system and a build tool). It may implement it to the level of being an \"explicit\" build, but I've not dug in to know. There are patches to GNU Make to act as a module mapper as well. This patch only works with GCC today; Clang may add support for libcody in the future. Any \"implicit\" implementation has a major flaw in the generic case: I don't know how to meaningfully give visibility to modules. Note that the \"`-fmodule-directory=` Clang flag where Clang just reads and writes files in the given directory based on module names as this strategy as well (the filesystem is the \"module mapper\" here).<br>\n</p><p>\nI find this to be problematic in practice because it means the state of the build graph depends on the runtime state of some running process, not just mtimes, content fingerprints (for tools which are hash-the-content-based rather than mtime-based), some metadata on disk (e.g., `.ninja_log`). I can't imagine how debugging this is expected to work when those not well-versed in build systems are on the front lines.<br>\n</p><p>\nBeyond that, there are corner cases to consider:<br>\n</p><p>\n- When a request to import module Q comes in, how many processes do we expect to launch before we find the rule that exports module Q is found? What if it lies beyond our `-j` limit? Do we suspend processes while we wait, doing job server shenanigans? What if it doesn't exist? What if we discover a module import cycle?<br>\n- The LSP-model must have some concept of module visibility in mind. Library L links to library K; K's sources should not be able to import any modules that are part of L. Even within L, if a module is not \"public\", it shouldn't be importable from outside of the library (including transitively by its own module interface files).<br>\n- With the filesystem-as-mapper model, stale files are a serious issue. If I rename module R to S, what is in charge of cleaning up R's BMI file? How do I say \"yes, you found it; it is radioactive\"? What remembers that the now-scanned S creator used to make R to clean it up?<br>\n- Duplicate module names. While C++ forbids multiple named modules within a program, nothing prevents `export module test;` from appearing in separate binaries. Related: if the build graph has release and debug variants, one now needs to track the debug version of module M separately from the release version.<br>\n</p><p>\nThese are not easy questions to answer and that's on top of two-way communication with compilers you're launching.<br>\n</p><p>\n[0] There is a wholly unnecessary MSVC extension where it is allowed (IIUC, due to a misreading of the standard that, TBF, we also had when starting CMake's implementation); easily avoided and made portable: drop the partition name.<br>\n[1] <a href=\"https://mathstuf.fedorapeople.org/fortran-modules/fortran-modules.html\">https://mathstuf.fedorapeople.org/fortran-modules/fortran...</a><br>\n[2] <a href=\"https://wg21.link/p1689r5\">https://wg21.link/p1689r5</a><br>\n[3] Namely writing install rules for the BMI files and CMake properties for exported targets.<br>\n</p></div>\n\n     \n  <div class=\"CommentReplyButton\">\n    <form action=\"/Articles/977639/comment\" method=\"post\">\n      <input type=\"submit\" value=\"Reply to this comment\">\n    </form>\n  </div>\n\n     <p>\n     \n    <a name=\"CommAnchor977680\"></a>\n    </p><details class=\"CommentBox\" open=\"\">\n      <summary><h3 class=\"CommentTitle\">C++20 module support in build systems</h3>\n      <p class=\"CommentPoster\"> Posted Jun 9, 2024 0:58 UTC (Sun)\n                               by <b>buck</b> (subscriber, #55985)\n                              [<a href=\"/Articles/977680/\">Link</a>] \n      </p></summary>\n     <div class=\"FormattedComment\">\nThis was breathtaking.<br>\n<p>\nYou should have saved it up for an LWN contributed article in its own right, though, maybe.<br>\n</p></div>\n\n     \n  <div class=\"CommentReplyButton\">\n    <form action=\"/Articles/977680/comment\" method=\"post\">\n      <input type=\"submit\" value=\"Reply to this comment\">\n    </form>\n  </div>\n\n     <p>\n     \n    </p></details>\n</details>\n</details>\n</details>\n<a name=\"CommAnchor977622\"></a>\n    <details class=\"CommentBox\" open=\"\">\n      <summary><h3 class=\"CommentTitle\">Where is this going to be 10 years from now?</h3>\n      <p class=\"CommentPoster\"> Posted Jun 7, 2024 20:47 UTC (Fri)\n                               by <b>q3cpma</b> (subscriber, #120859)\n                              [<a href=\"/Articles/977622/\">Link</a>] \n      </p></summary>\n     <div class=\"FormattedComment\">\nPersonally, I'm still hyped about Nyxt. I plan on switching and donating to it once it supports WebExtensions or something similar to uBlock in advanced JS blocking mode; the modern web without it is just too painful.<br>\n</div>\n\n     \n  <div class=\"CommentReplyButton\">\n    <form action=\"/Articles/977622/comment\" method=\"post\">\n      <input type=\"submit\" value=\"Reply to this comment\">\n    </form>\n  </div>\n\n     <p>\n     \n    </p></details>\n<a name=\"CommAnchor977654\"></a>\n    <details class=\"CommentBox\" open=\"\">\n      <summary><h3 class=\"CommentTitle\">Where is this going to be 10 years from now?</h3>\n      <p class=\"CommentPoster\"> Posted Jun 8, 2024 12:42 UTC (Sat)\n                               by <b>vadim</b> (subscriber, #35271)\n                              [<a href=\"/Articles/977654/\">Link</a>] \n      </p></summary>\n     <div class=\"FormattedComment\">\nThere's Servo. It's still alive, just split off from Mozilla and now is its own thing.<br>\n<p>\nWriting a web engine is an enormous project, I'm sure they could use more donations.<br>\n</p></div>\n\n     \n  <div class=\"CommentReplyButton\">\n    <form action=\"/Articles/977654/comment\" method=\"post\">\n      <input type=\"submit\" value=\"Reply to this comment\">\n    </form>\n  </div>\n\n     <p>\n     \n    </p></details>\n<a name=\"CommAnchor978519\"></a>\n    <details class=\"CommentBox\" open=\"\">\n      <summary><h3 class=\"CommentTitle\">Where is this going to be 10 years from now?</h3>\n      <p class=\"CommentPoster\"> Posted Jun 15, 2024 9:17 UTC (Sat)\n                               by <b>iteratedlateralus</b> (subscriber, #102183)\n                              [<a href=\"/Articles/978519/\">Link</a>] \n      </p></summary>\n     <div class=\"FormattedComment\">\nIt's fairly common to write header-only C++... which means you wouldn't have to write a function twice. But it definitely doesn't help compile times. <br>\n</div>\n\n     \n  <div class=\"CommentReplyButton\">\n    <form action=\"/Articles/978519/comment\" method=\"post\">\n      <input type=\"submit\" value=\"Reply to this comment\">\n    </form>\n  </div>\n\n     <p>\n     \n    </p></details>\n</details>\n<a name=\"CommAnchor977625\"></a>\n    <details class=\"CommentBox\" open=\"\">\n      <summary><h3 class=\"CommentTitle\">Support Firefox instead</h3>\n      <p class=\"CommentPoster\"> Posted Jun 7, 2024 21:07 UTC (Fri)\n                               by <b>Cyberax</b> (<b>✭ supporter ✭</b>, #52523)\n                              [<a href=\"/Articles/977625/\">Link</a>] (8 responses)\n      </p></summary>\n     <div class=\"FormattedComment\">\nI don't believe new browsers make any sense today, except as research items.<br>\n<p>\nIt would be much better to work with Mozilla to improve Firefox. One thing that's sorely missing is the embedding API. It's dead easy to embed Chromium, and this gives it so much advantage.<br>\n</p></div>\n\n     \n  <div class=\"CommentReplyButton\">\n    <form action=\"/Articles/977625/comment\" method=\"post\">\n      <input type=\"submit\" value=\"Reply to this comment\">\n    </form>\n  </div>\n\n     <p>\n     \n    <a name=\"CommAnchor977646\"></a>\n    </p><details class=\"CommentBox\" open=\"\">\n      <summary><h3 class=\"CommentTitle\">Support Firefox instead</h3>\n      <p class=\"CommentPoster\"> Posted Jun 8, 2024 8:40 UTC (Sat)\n                               by <b>b7j0c</b> (subscriber, #27559)\n                              [<a href=\"/Articles/977646/\">Link</a>] (7 responses)\n      </p></summary>\n     <div class=\"FormattedComment\">\nI don't know how Kling feels about Mozilla but it is also irrelevant; he is not obligated to support Firefox.<br>\n<p>\nMozilla as an organization is a spent force. They have jettisoned their primary means for making significant game-changing progress (Rust/Servo) and are instead just managing the inertia of their uncompetitive, aged, dying platform.<br>\n</p><p>\nMozilla squandered their future in exchange for shallow activism. Did any of their activist goals actually achieve anything other than me-too virtue signalling? I see a decade+ of superficial, low/zero impact activism while Chrome basically ate their entire market share. <br>\n</p><p>\nKling is doing us a favor by paving the way for a post-Mozilla future.<br>\n</p></div>\n\n     \n  <div class=\"CommentReplyButton\">\n    <form action=\"/Articles/977646/comment\" method=\"post\">\n      <input type=\"submit\" value=\"Reply to this comment\">\n    </form>\n  </div>\n\n     <p>\n     \n    <a name=\"CommAnchor977652\"></a>\n    </p><details class=\"CommentBox\" open=\"\">\n      <summary><h3 class=\"CommentTitle\">Support Firefox instead</h3>\n      <p class=\"CommentPoster\"> Posted Jun 8, 2024 12:05 UTC (Sat)\n                               by <b>roc</b> (subscriber, #30627)\n                              [<a href=\"/Articles/977652/\">Link</a>] (6 responses)\n      </p></summary>\n     <div class=\"FormattedComment\">\nFrom a technical point of view Firefox is still very competitive with Chrome. Certainly far more competitive than Ladybird has any hope of ever being.<br>\n<p>\nI just watched a video on a streaming service. That's basic functionality normal users require. To get that to work well you need a ton of stuff, including<br>\n-- &lt;video&gt; support, including the related DOM APIs<br>\n-- Integration with modern A/V codecs<br>\n-- Integration with hardware-accelerated decoding, where available<br>\n-- Support for Media Source Extensions<br>\n-- Support for EME<br>\n-- Reliable A/V sync<br>\n-- GPU-accelerated rendering<br>\n-- Off-main-thread compositing<br>\n-- Integration with the system compositor framework, where available (to minimize power usage)<br>\n(I'm sure I missed some stuff, it's been a while.)<br>\n</p><p>\nTo be competitive with modern browsers on security you need to have the site JS+CSS+HTML in its own sandboxed process. GPU rendering and A/V decoding need to be in separate sandboxed processes (could be the same process in a pinch).<br>\n</p><p>\nFirefox does this all very well. It took many talented engineers (and me) years to build and a lot more work to maintain since then. Maybe Mozilla is a spent force --- I hope not --- but don't underestimate what they had and still have, and how difficult it will be for a new project to even catch up to where they are now.<br>\n</p></div>\n\n     \n  <div class=\"CommentReplyButton\">\n    <form action=\"/Articles/977652/comment\" method=\"post\">\n      <input type=\"submit\" value=\"Reply to this comment\">\n    </form>\n  </div>\n\n     <p>\n     \n    <a name=\"CommAnchor977656\"></a>\n    </p><details class=\"CommentBox\" open=\"\">\n      <summary><h3 class=\"CommentTitle\">Support Firefox instead</h3>\n      <p class=\"CommentPoster\"> Posted Jun 8, 2024 13:10 UTC (Sat)\n                               by <b>PengZheng</b> (subscriber, #108006)\n                              [<a href=\"/Articles/977656/\">Link</a>] \n      </p></summary>\n     <div class=\"FormattedComment\">\nAgree.<br>\n<p>\n<span class=\"QuotedText\">&gt; A user asked on June 6 what would determine whether a component would be developed in-house versus using a third-party library. Kling responded that if it implements a web standard, \"i.e DOM, HTML, JavaScript, CSS, Wasm, etc. then we build it in house.\" </span><br>\n</p><p>\nAs a developer familiar with multimedia streaming, I would say even re-implementing WebRTC alone will be a huge challenge for the small team.<br>\n</p><p>\nSeriously, calling Firefox a dying platform will not add one's own value, it just pisses out faithful users of Firefox (there are a LOT here on LWN).<br>\n</p></div>\n\n     \n  <div class=\"CommentReplyButton\">\n    <form action=\"/Articles/977656/comment\" method=\"post\">\n      <input type=\"submit\" value=\"Reply to this comment\">\n    </form>\n  </div>\n\n     <p>\n     \n    </p></details>\n<a name=\"CommAnchor977662\"></a>\n    <details class=\"CommentBox\" open=\"\">\n      <summary><h3 class=\"CommentTitle\">Support Firefox instead</h3>\n      <p class=\"CommentPoster\"> Posted Jun 8, 2024 17:44 UTC (Sat)\n                               by <b>cytochrome</b> (subscriber, #58718)\n                              [<a href=\"/Articles/977662/\">Link</a>] \n      </p></summary>\n     <div class=\"FormattedComment\">\nI agree wholeheartedly. I find that Firefox (plus add-ons) satisfies all of my browsing and privacy needs. Thank you to @roc and the other talented software engineers for their hard work in developing and sustaining the application.  I have tried to do my small part by donating to the cause several times. <br>\n</div>\n\n     \n  <div class=\"CommentReplyButton\">\n    <form action=\"/Articles/977662/comment\" method=\"post\">\n      <input type=\"submit\" value=\"Reply to this comment\">\n    </form>\n  </div>\n\n     <p>\n     \n    </p></details>\n<a name=\"CommAnchor977690\"></a>\n    <details class=\"CommentBox\" open=\"\">\n      <summary><h3 class=\"CommentTitle\">Support Firefox instead</h3>\n      <p class=\"CommentPoster\"> Posted Jun 9, 2024 8:55 UTC (Sun)\n                               by <b>roc</b> (subscriber, #30627)\n                              [<a href=\"/Articles/977690/\">Link</a>] (3 responses)\n      </p></summary>\n     <div class=\"FormattedComment\">\nThis inspired me to write a blog post about building a new browser engine. <a href=\"https://robert.ocallahan.org/2024/06/browser-engine.html\">https://robert.ocallahan.org/2024/06/browser-engine.html</a><br>\n</div>\n\n     \n  <div class=\"CommentReplyButton\">\n    <form action=\"/Articles/977690/comment\" method=\"post\">\n      <input type=\"submit\" value=\"Reply to this comment\">\n    </form>\n  </div>\n\n     <p>\n     \n    <a name=\"CommAnchor978509\"></a>\n    </p><details class=\"CommentBox\" open=\"\">\n      <summary><h3 class=\"CommentTitle\">Support Firefox instead</h3>\n      <p class=\"CommentPoster\"> Posted Jun 15, 2024 2:06 UTC (Sat)\n                               by <b>himi</b> (subscriber, #340)\n                              [<a href=\"/Articles/978509/\">Link</a>] (2 responses)\n      </p></summary>\n     <div class=\"FormattedComment\">\nNot that I'm planning to build a browser engine (for profit or itch-scratching - I'm not insane), but that's a nice description of the complexity of the modern browser environment - it's easily the most complex single piece of software on human-focused general purpose devices, and it's probably the most critical piece of software on those devices. The fact that Mozilla have been able to keep Firefox genuinely competitive with Chrome is a real achievement, anyone targeting that level of functionality from scratch is facing a truly massive battle just to get to the starting line.<br>\n<p>\nThat said, something that targets the Electron niche (and does it well enough) likely has a lot of legs. Definitely still an uphill battle, but far less of one than targeting a full browser . . .<br>\n</p></div>\n\n     \n  <div class=\"CommentReplyButton\">\n    <form action=\"/Articles/978509/comment\" method=\"post\">\n      <input type=\"submit\" value=\"Reply to this comment\">\n    </form>\n  </div>\n\n     <p>\n     \n    <a name=\"CommAnchor978511\"></a>\n    </p><details class=\"CommentBox\" open=\"\">\n      <summary><h3 class=\"CommentTitle\">Support Firefox instead</h3>\n      <p class=\"CommentPoster\"> Posted Jun 15, 2024 2:27 UTC (Sat)\n                               by <b>Cyberax</b> (<b>✭ supporter ✭</b>, #52523)\n                              [<a href=\"/Articles/978511/\">Link</a>] \n      </p></summary>\n     <div class=\"FormattedComment\">\nThere are projects in this area, like HTMLayout (now <a href=\"https://sciter.com/\">https://sciter.com/</a> ). It was done by a single person, and back in 2000-s quite a few widely used Windows programs had UI built using it.<br>\n<p>\nSomething like this would be extremely useful. Not a full browser engine, but a subset for UIs.<br>\n</p></div>\n\n     \n  <div class=\"CommentReplyButton\">\n    <form action=\"/Articles/978511/comment\" method=\"post\">\n      <input type=\"submit\" value=\"Reply to this comment\">\n    </form>\n  </div>\n\n     <p>\n     \n    </p></details>\n<a name=\"CommAnchor978526\"></a>\n    <details class=\"CommentBox\" open=\"\">\n      <summary><h3 class=\"CommentTitle\">Support Firefox instead</h3>\n      <p class=\"CommentPoster\"> Posted Jun 15, 2024 14:02 UTC (Sat)\n                               by <b>Wol</b> (subscriber, #4433)\n                              [<a href=\"/Articles/978526/\">Link</a>] \n      </p></summary>\n     <div class=\"FormattedComment\">\nMy immediate reaction to this is the web browser is trying to be the new Emacs - all it needs is some hardware to run on, it does everything else.<br>\n<p>\nBut seriously, to what extent is that the modern paradigm nowadays - the browser is the OS that runs your programs, and linux and Windows are just glorified hardware abstraction layers. For many people - especially at work - that is now not far from the reality ...<br>\n</p><p>\nCheers,<br>\nWol<br>\n</p></div>\n\n     \n  <div class=\"CommentReplyButton\">\n    <form action=\"/Articles/978526/comment\" method=\"post\">\n      <input type=\"submit\" value=\"Reply to this comment\">\n    </form>\n  </div>\n\n     <p>\n     \n    </p></details>\n</details>\n</details>\n</details>\n</details>\n</details>\n<a name=\"CommAnchor977623\"></a>\n    <details class=\"CommentBox\" open=\"\">\n      <summary><h3 class=\"CommentTitle\">Comparisons to Firefox/Chrome seem premature</h3>\n      <p class=\"CommentPoster\"> Posted Jun 7, 2024 21:19 UTC (Fri)\n                               by <b>flussence</b> (subscriber, #85566)\n                              [<a href=\"/Articles/977623/\">Link</a>] \n      </p></summary>\n     <div class=\"FormattedComment\">\nMost of these alternative browsers fall into a gravity well of being a clone of Firefox 0.6, both in terms of capability and UI, and usually give up there after a period of stagnation. I would like to see something break the curse some day but I've been disappointed too many times to get excited at this point.<br>\n</div>\n\n     \n  <div class=\"CommentReplyButton\">\n    <form action=\"/Articles/977623/comment\" method=\"post\">\n      <input type=\"submit\" value=\"Reply to this comment\">\n    </form>\n  </div>\n\n     <p>\n     \n    </p></details>\n<a name=\"CommAnchor977628\"></a>\n    <details class=\"CommentBox\" open=\"\">\n      <summary><h3 class=\"CommentTitle\">Quixotic</h3>\n      <p class=\"CommentPoster\"> Posted Jun 7, 2024 22:07 UTC (Fri)\n                               by <b>roc</b> (subscriber, #30627)\n                              [<a href=\"/Articles/977628/\">Link</a>] (1 responses)\n      </p></summary>\n     <div class=\"FormattedComment\">\nSounds like fun, but to build a browser engine that is useful to the masses is going to take them infinitely long. (Literally; the work that needs to be done is growing faster than a handful of developers can do it.)<br>\n<p>\nAlso, if you're not just doing it for fun, then to justify starting from near-scratch you should make some fundamental decisions differently from the existing engines. Building with Rust would be a good one, but apparently that's not it. Building in site isolation from the ground up (i.e. IFRAMEs in their own processes) would be a good one, but they're not doing that AFAICT. Going all-in on parallelism would be another interesting one but I don't see that either. The only answer here that I can see in interviews with Kling is that Ladybird is designed to hew close to the architecture of the specifications, which is good but not much.<br>\n</p></div>\n\n     \n  <div class=\"CommentReplyButton\">\n    <form action=\"/Articles/977628/comment\" method=\"post\">\n      <input type=\"submit\" value=\"Reply to this comment\">\n    </form>\n  </div>\n\n     <p>\n     \n    <a name=\"CommAnchor977726\"></a>\n    </p><details class=\"CommentBox\" open=\"\">\n      <summary><h3 class=\"CommentTitle\">Quixotic</h3>\n      <p class=\"CommentPoster\"> Posted Jun 10, 2024 3:23 UTC (Mon)\n                               by <b>raven667</b> (subscriber, #5198)\n                              [<a href=\"/Articles/977726/\">Link</a>] \n      </p></summary>\n     <div class=\"FormattedComment\">\nIt may be quixotic but having someone new attempt to re-implement this stuff from scratch may help better document the actual effort involved in making a working implementation of these standards and what is required to make them fast, which isn't necessarily visible when an existing browser maker with an existing browser engine architecture and existing expert developers, who may have helped write the standard, does it because so much of the surrounding work the standard depends on already exists.  If they want to build this for fun and patrons want to fund it for the entertainment value, then so be it, I wish them the best of luck and most success.<br>\n</div>\n\n     \n  <div class=\"CommentReplyButton\">\n    <form action=\"/Articles/977726/comment\" method=\"post\">\n      <input type=\"submit\" value=\"Reply to this comment\">\n    </form>\n  </div>\n\n     <p>\n     \n    </p></details>\n</details>\n<a name=\"CommAnchor977629\"></a>\n    <details class=\"CommentBox\" open=\"\">\n      <summary><h3 class=\"CommentTitle\">Crashing is not necessarily a bad omen</h3>\n      <p class=\"CommentPoster\"> Posted Jun 7, 2024 22:18 UTC (Fri)\n                               by <b>cesarb</b> (subscriber, #6266)\n                              [<a href=\"/Articles/977629/\">Link</a>] (8 responses)\n      </p></summary>\n     <div class=\"FormattedComment\">\n<span class=\"QuotedText\">&gt; However, it doesn't seem to suffice to keep a single page from crashing the browser entirely. That's to be expected from a project that's still considered pre-alpha, though.</span><br>\n<p>\nI still remember using the single-digit milestone releases of Mozilla Suite (according to <a href=\"https://en.wikipedia.org/wiki/History_of_Mozilla_Application_Suite\">https://en.wikipedia.org/wiki/History_of_Mozilla_Applicat...</a> this was back in 1999). Each page I loaded had a chance of crashing the whole browser, and that chance increased dramatically if I used more than one browser window (there were no browser tabs back then). It was fun. I stuck with it, later switching to its descendant Phoenix/Firebird/Firefox, which I still use to this day.<br>\n</p><p>\nThat is, history shows that crashing often, this early in the project's life, does not mean the project is going to fail.<br>\n</p></div>\n\n     \n  <div class=\"CommentReplyButton\">\n    <form action=\"/Articles/977629/comment\" method=\"post\">\n      <input type=\"submit\" value=\"Reply to this comment\">\n    </form>\n  </div>\n\n     <p>\n     \n    <a name=\"CommAnchor977643\"></a>\n    </p><details class=\"CommentBox\" open=\"\">\n      <summary><h3 class=\"CommentTitle\">Crashing is not necessarily a bad omen</h3>\n      <p class=\"CommentPoster\"> Posted Jun 8, 2024 6:43 UTC (Sat)\n                               by <b>joib</b> (subscriber, #8541)\n                              [<a href=\"/Articles/977643/\">Link</a>] \n      </p></summary>\n     <div class=\"FormattedComment\">\nWell, back then netscape/mozilla/firefox was about the only decent(ish) alternative to IE, so you didn't have much alternative. Today you can switch to Firefox, Chrome, or a plethora of Chrome /webkit based browsers. So the bar for what people consider a MVP is much higher. <br>\n</div>\n\n     \n  <div class=\"CommentReplyButton\">\n    <form action=\"/Articles/977643/comment\" method=\"post\">\n      <input type=\"submit\" value=\"Reply to this comment\">\n    </form>\n  </div>\n\n     <p>\n     \n    </p></details>\n<a name=\"CommAnchor977728\"></a>\n    <details class=\"CommentBox\" open=\"\">\n      <summary><h3 class=\"CommentTitle\">Crashing is not necessarily a bad omen</h3>\n      <p class=\"CommentPoster\"> Posted Jun 10, 2024 7:16 UTC (Mon)\n                               by <b>edeloget</b> (subscriber, #88392)\n                              [<a href=\"/Articles/977728/\">Link</a>] (4 responses)\n      </p></summary>\n     <div class=\"FormattedComment\">\nAnd to be honest, this was a time when we routinely rebooted the whole PC multiple times per day, so having a crash on a web browser, while annoying, was kind of expected :)<br>\n</div>\n\n     \n  <div class=\"CommentReplyButton\">\n    <form action=\"/Articles/977728/comment\" method=\"post\">\n      <input type=\"submit\" value=\"Reply to this comment\">\n    </form>\n  </div>\n\n     <p>\n     \n    <a name=\"CommAnchor977738\"></a>\n    </p><details class=\"CommentBox\" open=\"\">\n      <summary><h3 class=\"CommentTitle\">Crashing is not necessarily a bad omen</h3>\n      <p class=\"CommentPoster\"> Posted Jun 10, 2024 11:25 UTC (Mon)\n                               by <b>cesarb</b> (subscriber, #6266)\n                              [<a href=\"/Articles/977738/\">Link</a>] (3 responses)\n      </p></summary>\n     <div class=\"FormattedComment\">\n<span class=\"QuotedText\">&gt; And to be honest, this was a time when we routinely rebooted the whole PC multiple times per day,</span><br>\n<p>\nThis was also a time when people bragged on slashdot about their Linux uptime. Rebooting the whole PC multiple times per day was IIRC more of a Windows thing back then; I was surprised when once I somehow managed to kernel panic Linux by doing something as simple as removing a floppy disk which was in use.<br>\n</p><p>\n<span class=\"QuotedText\">&gt; so having a crash on a web browser, while annoying, was kind of expected :)</span><br>\n</p><p>\nThis, on the other hand, was IIRC more common, even in non-alpha browsers like the pre-open-sourcing Netscape Navigator 4.x. But they were not so unstable that one would be afraid to open more than one window at the same time, for fear of a crash closing all open browser windows.<br>\n</p></div>\n\n     \n  <div class=\"CommentReplyButton\">\n    <form action=\"/Articles/977738/comment\" method=\"post\">\n      <input type=\"submit\" value=\"Reply to this comment\">\n    </form>\n  </div>\n\n     <p>\n     \n    <a name=\"CommAnchor977741\"></a>\n    </p><details class=\"CommentBox\" open=\"\">\n      <summary><h3 class=\"CommentTitle\">Crashing is not necessarily a bad omen</h3>\n      <p class=\"CommentPoster\"> Posted Jun 10, 2024 12:25 UTC (Mon)\n                               by <b>geert</b> (subscriber, #98403)\n                              [<a href=\"/Articles/977741/\">Link</a>] (1 responses)\n      </p></summary>\n     <div class=\"FormattedComment\">\nexport MALLOC_CHECK=0<br>\nnetscape<br>\n<p>\n</p></div>\n\n     \n  <div class=\"CommentReplyButton\">\n    <form action=\"/Articles/977741/comment\" method=\"post\">\n      <input type=\"submit\" value=\"Reply to this comment\">\n    </form>\n  </div>\n\n     <p>\n     \n    <a name=\"CommAnchor977742\"></a>\n    </p><details class=\"CommentBox\" open=\"\">\n      <summary><h3 class=\"CommentTitle\">Crashing is not necessarily a bad omen</h3>\n      <p class=\"CommentPoster\"> Posted Jun 10, 2024 12:32 UTC (Mon)\n                               by <b>khim</b> (subscriber, #9252)\n                              [<a href=\"/Articles/977742/\">Link</a>] \n      </p></summary>\n     <p>There was a way to attach <a href=\"https://en.wikipedia.org/wiki/Boehm_garbage_collector\">Boehm GC</a> to it, if I remember correctly.</p>\n\n<p>That was more stable.</p>\n\n\n     \n  <div class=\"CommentReplyButton\">\n    <form action=\"/Articles/977742/comment\" method=\"post\">\n      <input type=\"submit\" value=\"Reply to this comment\">\n    </form>\n  </div>\n\n     <p>\n     \n    </p></details>\n</details>\n<a name=\"CommAnchor978504\"></a>\n    <details class=\"CommentBox\" open=\"\">\n      <summary><h3 class=\"CommentTitle\">Crashing is not necessarily a bad omen</h3>\n      <p class=\"CommentPoster\"> Posted Jun 14, 2024 23:28 UTC (Fri)\n                               by <b>ssmith32</b> (subscriber, #72404)\n                              [<a href=\"/Articles/978504/\">Link</a>] \n      </p></summary>\n     <div class=\"FormattedComment\">\nUptime on servers, sure.<br>\nUptime for the kernel was pretty good on desktops.<br>\n<p>\nBut I remember being pretty handy with alt-shift-F1 and alt-shift-backspace, or whatever the hotkeys were to get to the virtual consoles and hard-kill X.<br>\n</p><p>\nAnd X dying was almost as bad as a full reboot for a desktop where apps didn't do a terribly good job with checkpoints and session restores.<br>\n</p><p>\nSo, while restarts and blue screens and corrupted data is what moved me off of Windows in the early 2000s, the Linux Desktop was not nearly as stable as it is today.<br>\n</p><p>\nNowadays, I had one desktop issue in the past few years, and I had System76 support figure out the issue and send me a new driver (which weirdly was triggered by using Google Maps in Firefox). Worlds better than when I was running a Mandrake (RPM) Frankenstein where half the software was compiled from tarballs because the RPMs available were woefully out of date..<br>\n</p></div>\n\n     \n  <div class=\"CommentReplyButton\">\n    <form action=\"/Articles/978504/comment\" method=\"post\">\n      <input type=\"submit\" value=\"Reply to this comment\">\n    </form>\n  </div>\n\n     <p>\n     \n    </p></details>\n</details>\n</details>\n<a name=\"CommAnchor977829\"></a>\n    <details class=\"CommentBox\" open=\"\">\n      <summary><h3 class=\"CommentTitle\">Crashing is not necessarily a bad omen</h3>\n      <p class=\"CommentPoster\"> Posted Jun 10, 2024 19:56 UTC (Mon)\n                               by <b>parametricpoly</b> (subscriber, #143903)\n                              [<a href=\"/Articles/977829/\">Link</a>] (1 responses)\n      </p></summary>\n     <div class=\"FormattedComment\">\nProgramming languages have improved quite a bit since 1990s. It's really no wonder it crashes it they chose C++. Using C++ here again is a waste of talent. Heck they could have picked Java instead. Java 22 is already pretty decent and more goodies will arrive in the LTS 24 release.<br>\n</div>\n\n     \n  <div class=\"CommentReplyButton\">\n    <form action=\"/Articles/977829/comment\" method=\"post\">\n      <input type=\"submit\" value=\"Reply to this comment\">\n    </form>\n  </div>\n\n     <p>\n     \n    <a name=\"CommAnchor978219\"></a>\n    </p><details class=\"CommentBox\" open=\"\">\n      <summary><h3 class=\"CommentTitle\">Crashing is not necessarily a bad omen</h3>\n      <p class=\"CommentPoster\"> Posted Jun 13, 2024 5:40 UTC (Thu)\n                               by <b>ceplm</b> (subscriber, #41334)\n                              [<a href=\"/Articles/978219/\">Link</a>] \n      </p></summary>\n     <div class=\"FormattedComment\">\nHow is Rhino doing these days? Is it already in the same speed rank as other major JavaScript engines?<br>\n<p>\nActually, surprisingly, it is still alive. That’s more than I expected.<br>\n</p></div>\n\n     \n  <div class=\"CommentReplyButton\">\n    <form action=\"/Articles/978219/comment\" method=\"post\">\n      <input type=\"submit\" value=\"Reply to this comment\">\n    </form>\n  </div>\n\n     <p>\n     \n    </p></details>\n</details>\n</details>\n<a name=\"CommAnchor977660\"></a>\n    <details class=\"CommentBox\" open=\"\">\n      <summary><h3 class=\"CommentTitle\">Future?</h3>\n      <p class=\"CommentPoster\"> Posted Jun 8, 2024 15:45 UTC (Sat)\n                               by <b>drago01</b> (subscriber, #50715)\n                              [<a href=\"/Articles/977660/\">Link</a>] \n      </p></summary>\n     <div class=\"FormattedComment\">\nDoes this have any futute other than being a \"toy\" project?<br>\n<p>\nIt doesn't do anything new or different to attract enough attention to compete with Chromium or Firefox.<br>\n</p></div>\n\n     \n  <div class=\"CommentReplyButton\">\n    <form action=\"/Articles/977660/comment\" method=\"post\">\n      <input type=\"submit\" value=\"Reply to this comment\">\n    </form>\n  </div>\n\n     <p>\n     \n    </p></details>\n<a name=\"CommAnchor977661\"></a>\n    <details class=\"CommentBox\" open=\"\">\n      <summary><h3 class=\"CommentTitle\">Why *not*?</h3>\n      <p class=\"CommentPoster\"> Posted Jun 8, 2024 16:45 UTC (Sat)\n                               by <b>rsidd</b> (subscriber, #2582)\n                              [<a href=\"/Articles/977661/\">Link</a>] (3 responses)\n      </p></summary>\n     <div class=\"FormattedComment\">\nI don't get all these comments about \"why work on this\". Because they want to, that's why. And SerenityOS seems much less relevant or useful to the wider world but that's where it started and that's an itch Kling wanted to scratch. Good for him.  Both projects seem to have built a substantial community so it's not just him. <br>\n<p>\nIt's pretty impressive what Ladybird has achieved, and there's no reason to think it won't be 10× more useful a year from now even if it lags Chrome and Firefox in some respects. But even if not, this is what they want to do, good luck to them. <br>\n</p><p>\nAnd it's false logic to say they should just work on firefox. That's not how \"scratch an itch\" works. <br>\n</p><p>\nActually, given the change in policy that they will not DIY everything but accept some NIH code where useful, I expect the next 12 months to be pretty interesting. <br>\n</p></div>\n\n     \n  <div class=\"CommentReplyButton\">\n    <form action=\"/Articles/977661/comment\" method=\"post\">\n      <input type=\"submit\" value=\"Reply to this comment\">\n    </form>\n  </div>\n\n     <p>\n     \n    <a name=\"CommAnchor977683\"></a>\n    </p><details class=\"CommentBox\" open=\"\">\n      <summary><h3 class=\"CommentTitle\">Why *not*?</h3>\n      <p class=\"CommentPoster\"> Posted Jun 9, 2024 4:58 UTC (Sun)\n                               by <b>chris_se</b> (subscriber, #99706)\n                              [<a href=\"/Articles/977683/\">Link</a>] (2 responses)\n      </p></summary>\n     <div class=\"FormattedComment\">\nI completely agree with you.<br>\n<p>\nFor that matter, I believe that the current browser ecosystem is not healthy at all: you have Chrome (+ all its derivatives), and Firefox (+ its derivatives), and then some niche projects. And while derivatives of Chrome make some changes, they will not diverge significantly from the actual browsing engine, so in the end, Google is the only one that determines what's next in terms of browser engine development, regardless of whether you use Edge, Chrome, Chromium, Opera, ... The only usable alternative right now is Firefox, but they are not the ones driving innovation in that space at the moment, unfortunately. (Which is a real shame, I like Firefox.)<br>\n</p><p>\nSo in that sense I welcome people being excited and working on alternatives, such as Servo, Ladybird, and others. Because I don't want to be in the situation where the entire future of the web is basically in the hands of a single company, and even if I don't end up using them myself for whatever reason, if they do thrive, they will bring a breath of fresh air into the web ecosystem, which is sorely needed in my opinion.<br>\n</p></div>\n\n     \n  <div class=\"CommentReplyButton\">\n    <form action=\"/Articles/977683/comment\" method=\"post\">\n      <input type=\"submit\" value=\"Reply to this comment\">\n    </form>\n  </div>\n\n     <p>\n     \n    <a name=\"CommAnchor977701\"></a>\n    </p><details class=\"CommentBox\" open=\"\">\n      <summary><h3 class=\"CommentTitle\">Why *not*?</h3>\n      <p class=\"CommentPoster\"> Posted Jun 9, 2024 14:44 UTC (Sun)\n                               by <b>rgmoore</b> (<b>✭ supporter ✭</b>, #75)\n                              [<a href=\"/Articles/977701/\">Link</a>] (1 responses)\n      </p></summary>\n     <p>The current browser ecosystem is unhealthy because Google sees Chrome as a means to maintain its dominant market position in the lucrative search and online advertising businesses.  They use their money from search and ads to squeeze profits out of the browser market and make it effectively impossible for anyone to make money by developing a competing browser from scratch.  It's basically the IE situation from the late '90s all over again, and it won't improve until some government steps up antitrust enforcement the way the USA did in the '90s.\n\n\n\n     \n  </p><div class=\"CommentReplyButton\">\n    <form action=\"/Articles/977701/comment\" method=\"post\">\n      <input type=\"submit\" value=\"Reply to this comment\">\n    </form>\n  </div>\n\n     <p>\n     \n    <a name=\"CommAnchor977727\"></a>\n    </p><details class=\"CommentBox\" open=\"\">\n      <summary><h3 class=\"CommentTitle\">Chromium is a browser consortium lead by Google</h3>\n      <p class=\"CommentPoster\"> Posted Jun 10, 2024 3:37 UTC (Mon)\n                               by <b>raven667</b> (subscriber, #5198)\n                              [<a href=\"/Articles/977727/\">Link</a>] \n      </p></summary>\n     <div class=\"FormattedComment\">\nOne important distinction from the bad old MSIE days is that Chromium is open source, not private/proprietary like MSIE, and acts as a reference implementation of a multi-vendor platform designed by consortium that includes competitors Google and MS (lead by Google) and separately with their own engines Apple and Mozilla, in some ways no different than Linux being developed as a shared project by many competing companies (although for Linux the consortium/trade org LF operates for _all_ vendors so there is no _one_ lead vendor) along side the similar BSDs with their own base OS funded by Apple and other vendors.  The mechanisms and possibilities for \"lock-in\" are very different than before.<br>\n</div>\n\n     \n  <div class=\"CommentReplyButton\">\n    <form action=\"/Articles/977727/comment\" method=\"post\">\n      <input type=\"submit\" value=\"Reply to this comment\">\n    </form>\n  </div>\n\n     <p>\n     \n    </p></details>\n</details>\n</details>\n</details>\n</div> <!-- middlecolumn -->\n<div class=\"rightcol not-print\">\n<div id=\"azk93271_right_zone\"></div>\n</div>\n</div> <!-- maincolumn -->\n\n            <br clear=\"all\">\n            <center>\n            <p>\n            <span class=\"ReallySmall\">\n            Copyright © 2024, Eklektix, Inc.<br>\n            This article may be redistributed under the terms of the\n              <a href=\"http://creativecommons.org/licenses/by-sa/4.0/\">Creative\n              Commons CC BY-SA 4.0</a> license<br>\n            Comments and public postings are copyrighted by their creators.<br>\n            Linux  is a registered trademark of Linus Torvalds<br>\n            </span>\n            </p></center>\n            \n            \n</body></html>",
		"metadata": {
			"ogLocaleAlternate": [],
			"sourceURL": "https://lwn.net/Articles/976822/",
			"pageStatusCode": 200
		}
	},
	"returnCode": 200
}