Well done, this is really cool. It is nice to see more modern C++ in use. The codebase is really easy to read and understand.
People here need to get over the fact that it's not Rust. I use C++ for my own projects because I enjoy writing in C++. I just wouldn't write them if I forced myself to use Rust or whatever else.
This C++ code is wildly modern. Very impressive. Using only the GitHub web interface, I could not find the definition for Gc::Ref. Where can I find it?
I had the same reading the source code - it's an interesting mix of traditional c++, while some of the projects use the latest c++20 features with modules. The GC::Ref seems to come form the karm-gc library. (according to copilot)
The main goal is great support for static documents rendering as it's being used at the core of the paper-muncher [1] PDF rendering engine, meant to replace wkhtmltopdf at odoo. But we don't exclude general web browsing and JavaScript support at some point.
At a previous company we moved off of wkhtmltopdf to a nodejs service which received static html and rendered it to pdf using phantomjs. These days you probably use puppeteer.
The trick was keeping the page context open to avoid chrome startup costs and recreating `page`. The node service would initialize a page object once with a script inside which would communicate with the server via a named Linux pipe. Then, for each request:
1. node service sends the static html to the page over the pipe
2. the page script receives the html from the pipe, inserts it into the DOM, and sends an “ack” back over the pipe
3. the node service receives the “ack” and calls the pdf rendering method on the page.
I don’t remember why we chose the pipe method: I’m sure there’s a better way to pass data to headless contexts these days.
The whole thing was super fast(~20ms) compared to WK, which took at least 30 seconds for us, and would more often than not just time out.
I remember the afternoon I had the idea: it was beer Friday -and it took a few hours to write up a basic prototype that rendered a PDF in a few hundred milliseconds. That was the first time I’d written a 100x speed improvement. Felt like a real rush.
Maybe? I'd say it depends on what you're rendering. We rendered HTML that we created ourselves, filled in with data that we parsed and validated. Styles across the documents generated were also largely the same.
If your job is to render arbitrary user HTML, this could get much more hairy. First of all, print rendering at the time(and probably now) was notoriously finicky. Things like adjusting colors, improper rendering of SVGs, pagination were difficult. It took a lot of effort to get right.
Furthermore, if you're sending arbitrary HTML, you now have a much larger security exploit surface. If someone figures out how to call `addEventListener` within the page context, they can snoop on every PDF generated by that page.
At work we recently switched from Wkhtmltopdf to Typst, which is a breath of fresh air. It is very fast and generates PDFs from scratch without needing to involve HTML or a browser engine. It is implemented in Rust and distributed as a self-contained binary.
Oh interesting. I use their "old stack" for a couple of much smaller projects and it works fine, but it does seem a bit ridiculous to be starting up a whole chrome instance just to convert one file format to another.
I intend to keep Skift and Vaev together for as long as possible since everything is meant to be cross-platform. I don’t see any architectural conflict that would motivate such a change.
This is really cool! Building a browser engine from scratch is no small feat, especially when handling complex CSS features like calc(), var(), and percentage units. It’s a great way to learn the inner workings of the web.
Curious about your approach to the networking stack. Are you planning to support more protocols like HTTPS or WebSockets in the future, or is the focus more on keeping this lightweight and minimal for now?
Ha! Only a few days ago, I was making the argument that the browser is the new mouse. As in no one person can build a computer mouse. You need experts in metal, plastic, transistors, lasers, etc. (Seth Godin?) The same way a web browser, which is the gateway to any connected device, requires experts in countless fields to build.
So kudos for building it this far. Now let me see if it runs webgl before I eat my hat.
i find myself requesting this whenever i see a new minimalist browser pop up:
it would be great to standardize alternative browsers on a consistent subset of web standards and document them so that "smolweb" enthusiasts can target that when building their websites and alternative browsers makers can target something useful without boiling the ocean
i personally prefer this approach to brand new protocols like Gemini, because it retains backward compatibility with popular browsers while offering an off ramp.
AFAIK, "email HTML" isn't standardized either; most organizations that make nice-looking HTML emails have to do a ton of testing across different clients and come up with workarounds to make everything look consistent.
It's fascinating how much "email HTML" is trapped in about HTML ~2.5, with limited CSS support and still a ton of FONT tags and TABLE layouts.
HTML 2 might be an interesting subset of HTML to "focus on" for smolweb, but it would be a big retro throwback, and not feel at all modern.
If you were starting today, might be more interesting to start with the most modern stuff and work backwards. HTML 2 TABLE could be implemented as a specialization of CSS Grid, for instance.
Google has recently been pivoting AMP which nearly broke the web towards email. It might actually be a better use of AMP than the web, but I'm still skeptical about some of its privacy stance and ad-injection focus: https://amp.dev/about/email
Does the email client on Windows still use IE11? (Some older versions might still have significant market share, but I’m not sure it would be for much longer?)
"Outlook (New)" (aka "One Outlook") is React Native with a full Chromium webview, and the transition from out-of-the-box Windows-provided "Outlook Mobile" (Windows 8-10) to "Outlook (New)" has mostly completed, but the transition from Outlook (Classic) (aka "Bloated Corporate Outlook") seems somewhat stalled because a few big corporations have extensive plugins and cranky IT admins. (Also Outlook Mobile had a better than IE11 support and also has been Chromium on most platforms, it is "Outlook (Classic)" that continues to haunt us all with its ancient Word-based micro-browser fork of IE.)
No interactivity! The email must be printable as-is. Not even CSS code to change styles when you hover over links. That's what I would for a minimum HTML for emails standard that's widely supported.
It’s actually a bummer: you can’t use a <style> tag because some email clients don’t like them. Instead, you have to inline your styles in every element. the lack of :hover is just a side effect of that I think (although it plays out nicely here).
(While on it, can we also ban loading images from third-party servers?)
Hmm, that might not be a bad idea! We could ban CSS altogether: just leave some markup tags, maybe whatever you can do in Markdown + tables. No colors, no small print, no images. (We could even use something like gemtext as the format instead of HTML, but that wouldn’t be backward compatible with clients.)
But I don’t see any email clients with somewhat significant market share going through with this :(
I'm confused, we're talking about browsers, and comment I replied to suggested 'email + interactivity' as a standard for minimal browsers. I wasn't suggesting adding JS execution to emails. (I don't even allow remote images personally.)
I think that would be really neat for small scale web publishing, but making it a subset of browser standards could be a really difficult sell to the people making browsers. While it's easier to build a browser to a subset of such a massive set of specs, the subset will drift towards a "similar but slightly incompatible standard" pretty soon after it's decided on. Following the development of Ladybird has given me an appreciation for just how often the "spec" for the web changes. (in small ways, daily.) That locks new browser implementations into a diverging standards track that would be very difficult to get off of.
I think something like a reference implementation (Ladybird, Servo or even Vaev maybe?) getting picked up as the small-web living standard feels like the best bet for me since that still lets browser projects get the big-time funding for making the big-web work in their browser too. "It's got to look good in Ladybird/Vaev/etc".
An idea: a web authoring tool built around libweb from Ladybird! (Or any other new web implementation that's easily embeddable) The implied standard-ness of whatever goes in that slot would just come for free. (Given enough people are using it!)
The phrase "living standard" is an oxymoron, invented by the incumbents who want to pretend they're supporting standards while weaponising constant change to keep themselves incumbent.
> I think something like a reference implementation (Ladybird, Servo or
even Vaev maybe?) getting picked up as the small-web living standard
feels like the best bet for me since that still lets browser projects
get the big-time funding for making the big-web work in their browser
too.
A "standard" should mean there is a clear goal to work towards to for
authors and browser vendors. For example, if a browser implements
CSS 2.1 (the last sanely defined CSS version), its vendor can say "we
support CSS 2.1", authors who care enough can check their CSS using a
validator, and users can report if a CSS 2.1 feature is implemented
incorrectly.
With a living standard (e.g. HTML5), all you get is a closed circle of
implementations which must add a feature before it is specified.
Restricting the number of implementations to one and omitting the
descriptive prose sounds even worse than the status quo.
I feel like some of the newer standards like CSS Grid instead of tables might be the best way to go. Many HTML/CSS improvements were not just bloat but actually better standards to build on.
Right! Crazy fonts or cursors, not on smolweb (as another use put it) but Flex and Grid are almost necessary. There are loads of things that could be dropped (it feels like).
I just want one of these browsers to give me a proper ComboBox (text, search and drop-down thing)
Yes, but grids are everywhere in the UIs, not just the tables. In 2000-s, the problem was the opposite of what we have now: every interface was a table full of tables, because there was no other way to position things reliably.
But now we have best of both worlds: use <table> for the actual tables, and CSS grid for UI layouts.
But the rendering engine might be easier to build with TABLE as a specialization of CSS Grid layout rendering rather than the slow real world work of CSS Grid being a generalization of TABLE rendering.
Everything flexbox can do, CSS Grid can do, with easier/better/cleaner support for the second axis. At this point, I'd be interested in dropping flexbox entirely for CSS Grid.
("I don't need to worry about the second axis" seems to be a "not thinking fourth dimensionally enough" excuse to me today. You haven't considered enough responsive breakpoints or you haven't considered future features or future expanded data or future localizations, yet.)
Sites often get that wrong. I'd say support motherfuckingwebsite.com subset: <p>, <a>, <h*>, <img>, <ruby> (i.e. markdown/gemini++) and do everything else with webcompat/fixbrowser way.
I wish for the same as well and have been asking for it for so long. Or a new Standard that could compile to a consistent subset of web standard with test spec available.
In this case it is better to make a new standard because HTML/CSS have so many legacy things and quirks that better be got rid of (like <hr> tag for example, table cell not inheriting font size etc).
I'm interested in why C++ was chosen for this? Browsers are notoriously hard to secure, they're effectively mean to be RCE vulnerabilities! Securing C++ binaries is hard and has in recent years been called out by numerous organisations and companies as being the root cause of many classes of security vulnerability. With languages like (but not limited to) Rust, we now have better options.
For the same reason C++ is chosen for a lot of projects. Probably the authors have a lot of experience in C++.
For an exceedingly complex and large project, you really want to choose a language you're very proficient in. Like, years and years of experience proficient in. If you don't have the experience in Rust then you don't have it. And, Rust is really the only other language that can be considered here. Swift, C#, whatever, are just a tad too high-level to write an engine in. At least, ergonomically.
I looked at the source code briefly and it's very high-quality code. Writing good C++ is hard, harder than pretty much any other language. It's modern, it's consistent, it's readable, and it's typed well.
There already is a Rust web engine, it's called Servo, and it's currently being overtaken by the C++ Ladybird project.
Rust is a bad language to write an open source browser in because the hardest problem of building a browser is not security but the number of people you can convince to work on it.
C++ programmers are a dime a dozen, there's a huge number of people who write C++ for 8 hours a day. The Rust community is mostly dabblers like myself.
AFAIU they are not ditching C++, they are exploring writing some parts of the engine in Swift using the new C++ interop features in Swift. But a wholesale switch to Swift doesn't seem realistic.
> it's currently being overtaken by the C++ Ladybird project.
Saying a mature engine that you can use today for ~all of the web is being "overtaken" by unreleased pre-alpha software is a strange definition of overtaking.
Ladybird overtook Servo in WPT a few months ago and the gap is only increasing. Servo cannot match the development pace of Ladybird and Ladybird's access to the huge pool of C++ devs is everything to do with that.
AFAIK Rust isn't a great language for writing browsers, because the pattern that HTML/DOM needs isn't something that Rust supports out of the box, you need a lot of pointers here and there, IIRC Andreas Kling (Ladybird dev) said something like that, where Swift was better suited than Rust for the job, or at least more pleasant to work with after the team evaluated a few languages, including Rust.
I had the same thought. The project's description:
>secure HTML/CSS engine
No offense to these folks, but I see no evidence of any fuzzing which makes it hard to believe there aren't some exploitable bugs in the codebase. Google has world-class browser devs and tooling, yet they still write exploitable bugs :p (and sorry Apple / Mozilla, you guys have world-class browser devs but I don't know enough about your tooling. Microsoft was purposefully omitted)
Yeah, very few of those bugs are in the renderer, but they still happen!
FWIW, I don't write Rust, and this is why I said "not limited to". Honestly, Swift might be an interesting one. I gather Zig can provide a more safety than C++. There are a bunch of other options too.
Performance is often a concern, but a slow secure browser is better than a fast insecure one. Perhaps I'm a security troll, but writing this stuff in C++ has been shown over the last 30+ years to be functionally impossible, and yet security is one of the most important things for a browser.
If the answer is that there are more possible contributors, or even that this is a hobby project and it's what the author knows, those are reasonable answers, but I'm interested anyway because perhaps the author has a different way of thinking about these tradeoffs to me, and maybe that's something I can learn from.
I'm convinced that the "security" paranoia is just concern-trolling at this point, trying to push people towards more authoritarian and corporate-controlled languages and environments.
Yeah, suddenly everyone seems to care about security they know nothing about. If they truly cared, they would have cared before Rust, you know, by writing Ada / SPARK.
The reason why we don't have many secure browsers, is because everybody is doing it in C++. I'm just looking for a little variety and approach to security.
Do you think it is attainable ?
Could someone like you break the task up into small enough pieces to let each piece be coded by a group of rust newbies ?
I know its a tangent, but the idea that maybe ripping out android webview into a standalone cross platform project in its own right pops into my head everytime this problem arises. Keep meaning to check if anyones actually done it already.
Google themselves actually have gone vaguely in the direction you're thinking, kind of, in the form of Cobalt: a stripped-down copy of Chromium that has specific, deliberate "quirks" that minimize memory allocation/ballooning in long-running applications.
Google uses it to power YouTube TV.
Unfortunately, while I'm sure I downloaded a Linux X11 binary a while back to play with, I can't find anything of the like available anymore. The release packages just contain a shared library, and the containers in the registry are just full of compiler toolchains (I installed ncdu in them and checked).
The whole system is mired/buried in layers of hardware integration fluff (because Cobalt is meant to be embedded in set-top boxes) and there is very little in the way of batteries-included demos, potentially to keep the product from gaining cottage-industry traction on older systems. Which does make sense, given that there are specific CSS rules that Cobalt doesn't follow the spec on, and I'm not sure where where its JS support is at.
What do you mean by that? WebView is just Chrome embedded inside of an Android app. Same thing already exists on Windows (Edge WebView2), macOS (WKWebView) and Linux (WebKitGTK). There's also a library that wraps all of them into a single interface:
The idea is it would be lightweight (so just a few megabytes of libraries) and give the same functionality you get with an android webview (so send it html to load and javascript to run and get json results back).
I know there are quite a few options that try and do something similar. But they are all so incredibly bloated when all you want to do is use html5 for a native application UI.
Bravo to the Vaev team for championing unrestrained technological exploration!
The choice of C++ is bold.
Despite the security concerns often highlighted, modern C++ with smart pointers, and RAII patterns can be just as safe as Rust when done right. Vaev’s security model should focus on process isolation, sandboxing techniques, and leveraging modern C++ features to minimize vulnerabilities.
Super excited to see such raw innovation and courage in tackling a colossal task often monopolized by juggernauts like Chromium.
Hoping you will expand the documentation. That tldraw file is almost unusable, no online service exists to view the file. Only thing I got was a vscode extension. Unless I have reason to ditch sublime, there is not much choices left to view your architecture documented in an obscure format.
You're right, I think merged a few things together when writing the comment. What I meant is that (if you ignore PrinceXML and focus on FOSS) you're down to 3 options:
- wkhtmltopdf
- weasyprint
- (headless) chromium with puppeteer et al.
The first one I found to be unreliable, the second one is super slow and the third can be annoying to work with.
I don't mean this as a slight against you but it's incredible how much code it takes to write a browser that barely works. I've always thought it would be fun to write a browser in erlang/elixir due to its fault tolerance (a memory from the early days when browsers would constantly crash), but browsers are so outrageously complex with such intense performance requirements the thought of even creating a repo sickens me. I mean it looks like you guys have 100+ files, with half of the files being ~500+ lines of code.
oh the irony. I remember decades ago when google.com was branded as example of minimal html design, to save bandwidth as much as possible, they don't even enclose html tags.
Now google.com is loads of js crap. The SERP refuse to render without full blown js, css and cookie.
I wish one of these projects would make a browser which only renders text (so texts and links) and no additional support for media (images, videos, audio etc).
I know there is Lynx but having a non-terminal based browser which could do it would be cool.
You might be interested in Richard Stallman's method of browsing the web:
> I generally do not connect to web sites from my own machine, aside from a few sites I have some special relationship with. I usually fetch web pages from other sites by sending mail to a program (see https://git.savannah.gnu.org/git/womb/hacks.git) that fetches them, much like wget, and then mails them back to me. Then I look at them using a web browser, unless it is easy to see the text in the HTML page directly. I usually try lynx first, then a graphical browser if the page needs it. [0]
I know you wanted something other than lynx, but you could do this with EWW (Emacs web browser or any graphical browser, provided that your proxy wget dropped the images.
The fact that other browsers are huge engineering efforts only makes it more interesting to many. It's arguably one of the hardest things a programmer could build, how could you not wanna build one!
It's still early days, but Clang can check some lifetimes, using the [[clang::lifetimebound]] attribute [1]. You can also restrict unsafe pointer usage [2] outside designated blocks of code—somewhat like Rust’s unsafe keyword.
Since 2012, all future browsers will be written in Rust and looks like it will always be that case. Perhaps, programming a browser in Rust is a painful activity that nobody seems to have managed to complete (writing parts of it since the Servo days). Talking about safety though, nonstop, yeah no shortage of that.
I personally have had enough of the "security" bullshit after seeing what it's done to "secure" control over the population and put that in the hands of the enemy.
I think if you're going to bring up how security has a political angle to it (repeatedly!) you should not be surprised if people remember the arguments you recycle for the topic
I know you intended to be helpful and didn't mean to be unkind.
But, this site is called Hacker News, and it's always been one of the site's most important roles, to feature and celebrate novel and interesting projects that people hack on, for whatever reason they choose.
There are all kinds of things that can be learned by starting with a blank slate and re-implementing something as ubiquitous and foundational as a web browser.
Over the years, many users have enjoyed undertaking a course called "Nand to Tetris" [1]. I hope to find time to do it one day. I don't expect it will make me substantially more employable, but I think I'll enjoy learning about the fundamentals, and I'm sure it will be beneficial in my work somehow.
Please let's remember that the playful exploration that happens through a project like this can lead to all kinds of benefits that might be non-obvious, and that it’s fine to appreciate the effort for its own sake.
Hm, I'm sorry you feel that way. It's not meant to be mean. On the contrary; Instead of encouraging someone who I feel is going down a wrong path, to me it's kinder to express my view that they aren't. I have personally wasted years of my life on technical projects, and would have been better off if someone had told me that it was a bad idea.
I'm of the opinion that these passion projects are incredibly important.
Your passions projects were problably also far more important to your growth than you give them credit for.
Scratching an itch is how we, as programmers/engineers/whatever, grow. It is also how we stumble into solving real problems and make our mark on the world.
Who knows, this could become the next big player in the browsersphere, or maybe it'll pivot into something else, or perhaps it will spark someones imagination. At the very least it has (probably) already been a source of creative bliss and pride for the ones involved, which in my opinion makes it worthwhile.
I understand what you are saying and don't fully disagree. You can allocate time & energy into immediate real world solutions while reaping the personal growth. There is certainly a balance.
The counter-point is that in the case of a web browser you are studying deeply one of the most impactful technologies to exist, and you will learn 80% of the most important lessons with a minimal working build, maybe 0.1% of the real thing. You may learn and execute much faster too because there is a clear blueprint, and you are likely riding a wave of passion that will carry your mind to places you won't have expected.
The perspective gained puts you in a much better place to identify & execute successfully more impactful work. The work may be the seed of something more important, but unseen or unknown yet.
Well done, this is really cool. It is nice to see more modern C++ in use. The codebase is really easy to read and understand.
People here need to get over the fact that it's not Rust. I use C++ for my own projects because I enjoy writing in C++. I just wouldn't write them if I forced myself to use Rust or whatever else.
This C++ code is wildly modern. Very impressive. Using only the GitHub web interface, I could not find the definition for Gc::Ref. Where can I find it?
Probably this - https://github.com/skift-org/karm/blob/main/src/libs/karm-gc...
And this is not a garbage collector in the traditional sense, more like arena with smart pointers.
It's just a placeholder implementation, we will have a proper GC when we get to it
I had the same reading the source code - it's an interesting mix of traditional c++, while some of the projects use the latest c++20 features with modules. The GC::Ref seems to come form the karm-gc library. (according to copilot)
What’s the long term goal of this project beyond learning? Building a browser to support the modern web is a humongous work IMHO.
The main goal is great support for static documents rendering as it's being used at the core of the paper-muncher [1] PDF rendering engine, meant to replace wkhtmltopdf at odoo. But we don't exclude general web browsing and JavaScript support at some point.
[1] https://github.com/odoo/paper-muncher
Ooh blast from the past!
At a previous company we moved off of wkhtmltopdf to a nodejs service which received static html and rendered it to pdf using phantomjs. These days you probably use puppeteer.
The trick was keeping the page context open to avoid chrome startup costs and recreating `page`. The node service would initialize a page object once with a script inside which would communicate with the server via a named Linux pipe. Then, for each request:
1. node service sends the static html to the page over the pipe
2. the page script receives the html from the pipe, inserts it into the DOM, and sends an “ack” back over the pipe
3. the node service receives the “ack” and calls the pdf rendering method on the page.
I don’t remember why we chose the pipe method: I’m sure there’s a better way to pass data to headless contexts these days.
The whole thing was super fast(~20ms) compared to WK, which took at least 30 seconds for us, and would more often than not just time out.
Sounds like fun considering how real the problem is.
It was!
I remember the afternoon I had the idea: it was beer Friday -and it took a few hours to write up a basic prototype that rendered a PDF in a few hundred milliseconds. That was the first time I’d written a 100x speed improvement. Felt like a real rush.
Congratulations. Doesn't make this approach make so much more sense than writing a browser engine from scratch?
Maybe? I'd say it depends on what you're rendering. We rendered HTML that we created ourselves, filled in with data that we parsed and validated. Styles across the documents generated were also largely the same.
If your job is to render arbitrary user HTML, this could get much more hairy. First of all, print rendering at the time(and probably now) was notoriously finicky. Things like adjusting colors, improper rendering of SVGs, pagination were difficult. It took a lot of effort to get right.
Furthermore, if you're sending arbitrary HTML, you now have a much larger security exploit surface. If someone figures out how to call `addEventListener` within the page context, they can snoop on every PDF generated by that page.
At work we recently switched from Wkhtmltopdf to Typst, which is a breath of fresh air. It is very fast and generates PDFs from scratch without needing to involve HTML or a browser engine. It is implemented in Rust and distributed as a self-contained binary.
This blog post convinced us that the switch was worth it: https://zerodha.tech/blog/1-5-million-pdfs-in-25-minutes/
Oh interesting. I use their "old stack" for a couple of much smaller projects and it works fine, but it does seem a bit ridiculous to be starting up a whole chrome instance just to convert one file format to another.
I also love Typst and use it regularly. But just to note it : there is also https://weasyprint.org that takes HTML as input
So cool to see Odoo mentioned on HN. I've worked with it before and like it a lot.
I've made posts about it on HN before but they've never gained traction. I hope that this takes off.
You guys make neat software.
Does it support page margin boxes?
Yes !
Looks like skift is a hobby os like Serenity OS which Ladybird is spun out from. Maybe they intend to follow the same path?
I intend to keep Skift and Vaev together for as long as possible since everything is meant to be cross-platform. I don’t see any architectural conflict that would motivate such a change.
This is really cool! Building a browser engine from scratch is no small feat, especially when handling complex CSS features like calc(), var(), and percentage units. It’s a great way to learn the inner workings of the web.
Curious about your approach to the networking stack. Are you planning to support more protocols like HTTPS or WebSockets in the future, or is the focus more on keeping this lightweight and minimal for now?
Ha! Only a few days ago, I was making the argument that the browser is the new mouse. As in no one person can build a computer mouse. You need experts in metal, plastic, transistors, lasers, etc. (Seth Godin?) The same way a web browser, which is the gateway to any connected device, requires experts in countless fields to build.
So kudos for building it this far. Now let me see if it runs webgl before I eat my hat.
There are four people working on this project, not one.
i find myself requesting this whenever i see a new minimalist browser pop up:
it would be great to standardize alternative browsers on a consistent subset of web standards and document them so that "smolweb" enthusiasts can target that when building their websites and alternative browsers makers can target something useful without boiling the ocean
i personally prefer this approach to brand new protocols like Gemini, because it retains backward compatibility with popular browsers while offering an off ramp.
> standardize alternative browsers on a consistent subset of web standards and document them so that "smolweb" enthusiasts can target that
Could such a standard be based on the subset of HTML/CSS acceptable in emails? Maybe with a few extra things for interactivity.
AFAIK, "email HTML" isn't standardized either; most organizations that make nice-looking HTML emails have to do a ton of testing across different clients and come up with workarounds to make everything look consistent.
It's fascinating how much "email HTML" is trapped in about HTML ~2.5, with limited CSS support and still a ton of FONT tags and TABLE layouts.
HTML 2 might be an interesting subset of HTML to "focus on" for smolweb, but it would be a big retro throwback, and not feel at all modern.
If you were starting today, might be more interesting to start with the most modern stuff and work backwards. HTML 2 TABLE could be implemented as a specialization of CSS Grid, for instance.
Could we standardize email HTML?
If you can convince Apple, Google, and Microsoft to implement your standard: sure. Attempts have been made with varying success.
Your standard still needs to render in Outlook on Windows, though, which means you need to support the weird Office version of IE11 as an upper limit.
Google has recently been pivoting AMP which nearly broke the web towards email. It might actually be a better use of AMP than the web, but I'm still skeptical about some of its privacy stance and ad-injection focus: https://amp.dev/about/email
Does the email client on Windows still use IE11? (Some older versions might still have significant market share, but I’m not sure it would be for much longer?)
"Outlook (New)" (aka "One Outlook") is React Native with a full Chromium webview, and the transition from out-of-the-box Windows-provided "Outlook Mobile" (Windows 8-10) to "Outlook (New)" has mostly completed, but the transition from Outlook (Classic) (aka "Bloated Corporate Outlook") seems somewhat stalled because a few big corporations have extensive plugins and cranky IT admins. (Also Outlook Mobile had a better than IE11 support and also has been Chromium on most platforms, it is "Outlook (Classic)" that continues to haunt us all with its ancient Word-based micro-browser fork of IE.)
Sometimes I really wish MSFT broke backwards compatibility in the places that matter, not places their corporate customers don’t care about.
You could write a standard.
If it actually gets mainstream adoption or goes into the standards pile it another question entirely.
A few extra things like.. JavaScript?
No interactivity! The email must be printable as-is. Not even CSS code to change styles when you hover over links. That's what I would for a minimum HTML for emails standard that's widely supported.
It’s actually a bummer: you can’t use a <style> tag because some email clients don’t like them. Instead, you have to inline your styles in every element. the lack of :hover is just a side effect of that I think (although it plays out nicely here).
(While on it, can we also ban loading images from third-party servers?)
you sure can if we resolve to make a text editor instead of a web browser!
Hmm, that might not be a bad idea! We could ban CSS altogether: just leave some markup tags, maybe whatever you can do in Markdown + tables. No colors, no small print, no images. (We could even use something like gemtext as the format instead of HTML, but that wouldn’t be backward compatible with clients.)
But I don’t see any email clients with somewhat significant market share going through with this :(
I'm confused, we're talking about browsers, and comment I replied to suggested 'email + interactivity' as a standard for minimal browsers. I wasn't suggesting adding JS execution to emails. (I don't even allow remote images personally.)
A total PL would be nice...
I think that would be really neat for small scale web publishing, but making it a subset of browser standards could be a really difficult sell to the people making browsers. While it's easier to build a browser to a subset of such a massive set of specs, the subset will drift towards a "similar but slightly incompatible standard" pretty soon after it's decided on. Following the development of Ladybird has given me an appreciation for just how often the "spec" for the web changes. (in small ways, daily.) That locks new browser implementations into a diverging standards track that would be very difficult to get off of.
I think something like a reference implementation (Ladybird, Servo or even Vaev maybe?) getting picked up as the small-web living standard feels like the best bet for me since that still lets browser projects get the big-time funding for making the big-web work in their browser too. "It's got to look good in Ladybird/Vaev/etc".
An idea: a web authoring tool built around libweb from Ladybird! (Or any other new web implementation that's easily embeddable) The implied standard-ness of whatever goes in that slot would just come for free. (Given enough people are using it!)
small-web living standard
The phrase "living standard" is an oxymoron, invented by the incumbents who want to pretend they're supporting standards while weaponising constant change to keep themselves incumbent.
> I think something like a reference implementation (Ladybird, Servo or even Vaev maybe?) getting picked up as the small-web living standard feels like the best bet for me since that still lets browser projects get the big-time funding for making the big-web work in their browser too.
A "standard" should mean there is a clear goal to work towards to for authors and browser vendors. For example, if a browser implements CSS 2.1 (the last sanely defined CSS version), its vendor can say "we support CSS 2.1", authors who care enough can check their CSS using a validator, and users can report if a CSS 2.1 feature is implemented incorrectly.
With a living standard (e.g. HTML5), all you get is a closed circle of implementations which must add a feature before it is specified. Restricting the number of implementations to one and omitting the descriptive prose sounds even worse than the status quo.
The subset could just be an older version of the spec, e.g. HTML 4.01 and CSS 2.1.
(My opinion as another one who has been slowly working on my own browser engine.)
Pick a subset aimed directly at accessibility.
The least-needed features are often accessibility nightmares (e.g. animation - although usually not semantic).
The accessible subset could then be government standardized and used as a legal hammer against over-complex HTML sites.
For a while search engines helped because they encouraged sites to focus on being more informative (html DOCUMENTS).
I think web applications are a huge improvement over Windows applications, however dynamic HTML is a nightmare. Old school forms were usable.
(edited to improve) Disclosure: wrote a js framework and SPA mid 00's (so I've been more on the problem side than the solution side).
Styles can be provided as client-side dependencies instead of free form CSS:
then browser decides how to resolve them.That's easy to specify but contains a lot of bloat and unused features. A slimmer but more modern set would be useful.
I feel like some of the newer standards like CSS Grid instead of tables might be the best way to go. Many HTML/CSS improvements were not just bloat but actually better standards to build on.
Right! Crazy fonts or cursors, not on smolweb (as another use put it) but Flex and Grid are almost necessary. There are loads of things that could be dropped (it feels like).
I just want one of these browsers to give me a proper ComboBox (text, search and drop-down thing)
From accessibility background: Please stop using CSS for table data. It does not translate to my screenreader.
Yes, but grids are everywhere in the UIs, not just the tables. In 2000-s, the problem was the opposite of what we have now: every interface was a table full of tables, because there was no other way to position things reliably.
But now we have best of both worlds: use <table> for the actual tables, and CSS grid for UI layouts.
You still need to have tables.
And <marquee>, of course.
But the rendering engine might be easier to build with TABLE as a specialization of CSS Grid layout rendering rather than the slow real world work of CSS Grid being a generalization of TABLE rendering.
Cat is out of the bag. nobody wants their CSS without flexbox anymore. It has to include that.
Everything flexbox can do, CSS Grid can do, with easier/better/cleaner support for the second axis. At this point, I'd be interested in dropping flexbox entirely for CSS Grid.
("I don't need to worry about the second axis" seems to be a "not thinking fourth dimensionally enough" excuse to me today. You haven't considered enough responsive breakpoints or you haven't considered future features or future expanded data or future localizations, yet.)
Sounds kinda like DOM levels: https://en.wikipedia.org/wiki/Document_Object_Model#Standard...
Well, until everybody just gave up and declared it a "Living Standard".
I think we do still need something like this, but I worry that basing it on versions of the spec is just repeating the same DOM levels mistake.
But older versions contain lots of crap we don't need (eg <blink> tags) and miss out on useful stuff (grid layout).
Why not start with what is required for markdown formatting? Then build out from there.
> slowly working on my own browser engine
care to tell us more?
Sites often get that wrong. I'd say support motherfuckingwebsite.com subset: <p>, <a>, <h*>, <img>, <ruby> (i.e. markdown/gemini++) and do everything else with webcompat/fixbrowser way.
I wish for the same as well and have been asking for it for so long. Or a new Standard that could compile to a consistent subset of web standard with test spec available.
I am all for this. A completely simplified version of HTML without all the quirks and edge cases which have been added in over years + Javascript.
In this case it is better to make a new standard because HTML/CSS have so many legacy things and quirks that better be got rid of (like <hr> tag for example, table cell not inheriting font size etc).
What you have against <hr>?
You mean AMP without the BS
I'm interested in why C++ was chosen for this? Browsers are notoriously hard to secure, they're effectively mean to be RCE vulnerabilities! Securing C++ binaries is hard and has in recent years been called out by numerous organisations and companies as being the root cause of many classes of security vulnerability. With languages like (but not limited to) Rust, we now have better options.
> I'm interested in why C++ was chosen for this?
For the same reason C++ is chosen for a lot of projects. Probably the authors have a lot of experience in C++.
For an exceedingly complex and large project, you really want to choose a language you're very proficient in. Like, years and years of experience proficient in. If you don't have the experience in Rust then you don't have it. And, Rust is really the only other language that can be considered here. Swift, C#, whatever, are just a tad too high-level to write an engine in. At least, ergonomically.
I looked at the source code briefly and it's very high-quality code. Writing good C++ is hard, harder than pretty much any other language. It's modern, it's consistent, it's readable, and it's typed well.
There already is a Rust web engine, it's called Servo, and it's currently being overtaken by the C++ Ladybird project.
Rust is a bad language to write an open source browser in because the hardest problem of building a browser is not security but the number of people you can convince to work on it.
C++ programmers are a dime a dozen, there's a huge number of people who write C++ for 8 hours a day. The Rust community is mostly dabblers like myself.
But ladybird is ditching c++ for swift?
AFAIU they are not ditching C++, they are exploring writing some parts of the engine in Swift using the new C++ interop features in Swift. But a wholesale switch to Swift doesn't seem realistic.
I remember Andreas saying something along those lines in some interview, but seeing their repo[0] doesn't looks like
C++ 64.6%
HTML 22.4%
JavaScript 11.0%
CMake 0.7%
Objective-C++ 0.5%
Swift 0.3%
Other 0.5%
[0] https://github.com/LadybirdBrowser/ladybird
It did seem like an odd decision maybe they thought better of it.
I guess it's just me but after more than 10 years of C++ 8 hours a day I'm happy to never touch it for free
> it's currently being overtaken by the C++ Ladybird project.
Saying a mature engine that you can use today for ~all of the web is being "overtaken" by unreleased pre-alpha software is a strange definition of overtaking.
Ladybird overtook Servo in WPT a few months ago and the gap is only increasing. Servo cannot match the development pace of Ladybird and Ladybird's access to the huge pool of C++ devs is everything to do with that.
AFAIK Rust isn't a great language for writing browsers, because the pattern that HTML/DOM needs isn't something that Rust supports out of the box, you need a lot of pointers here and there, IIRC Andreas Kling (Ladybird dev) said something like that, where Swift was better suited than Rust for the job, or at least more pleasant to work with after the team evaluated a few languages, including Rust.
I had the same thought. The project's description:
>secure HTML/CSS engine
No offense to these folks, but I see no evidence of any fuzzing which makes it hard to believe there aren't some exploitable bugs in the codebase. Google has world-class browser devs and tooling, yet they still write exploitable bugs :p (and sorry Apple / Mozilla, you guys have world-class browser devs but I don't know enough about your tooling. Microsoft was purposefully omitted)
Yeah, very few of those bugs are in the renderer, but they still happen!
[flagged]
FWIW, I don't write Rust, and this is why I said "not limited to". Honestly, Swift might be an interesting one. I gather Zig can provide a more safety than C++. There are a bunch of other options too.
Performance is often a concern, but a slow secure browser is better than a fast insecure one. Perhaps I'm a security troll, but writing this stuff in C++ has been shown over the last 30+ years to be functionally impossible, and yet security is one of the most important things for a browser.
If the answer is that there are more possible contributors, or even that this is a hobby project and it's what the author knows, those are reasonable answers, but I'm interested anyway because perhaps the author has a different way of thinking about these tradeoffs to me, and maybe that's something I can learn from.
I'm convinced that the "security" paranoia is just concern-trolling at this point, trying to push people towards more authoritarian and corporate-controlled languages and environments.
Yeah, suddenly everyone seems to care about security they know nothing about. If they truly cared, they would have cared before Rust, you know, by writing Ada / SPARK.
Rude
You're right. The reason why we don't have many browsers is because nobody is doing it in rust.
The reason why we don't have many secure browsers, is because everybody is doing it in C++. I'm just looking for a little variety and approach to security.
Do you think it is attainable ? Could someone like you break the task up into small enough pieces to let each piece be coded by a group of rust newbies ?
I know its a tangent, but the idea that maybe ripping out android webview into a standalone cross platform project in its own right pops into my head everytime this problem arises. Keep meaning to check if anyones actually done it already.
Google themselves actually have gone vaguely in the direction you're thinking, kind of, in the form of Cobalt: a stripped-down copy of Chromium that has specific, deliberate "quirks" that minimize memory allocation/ballooning in long-running applications.
Google uses it to power YouTube TV.
Unfortunately, while I'm sure I downloaded a Linux X11 binary a while back to play with, I can't find anything of the like available anymore. The release packages just contain a shared library, and the containers in the registry are just full of compiler toolchains (I installed ncdu in them and checked).
The whole system is mired/buried in layers of hardware integration fluff (because Cobalt is meant to be embedded in set-top boxes) and there is very little in the way of batteries-included demos, potentially to keep the product from gaining cottage-industry traction on older systems. Which does make sense, given that there are specific CSS rules that Cobalt doesn't follow the spec on, and I'm not sure where where its JS support is at.
https://developers.google.com/youtube/cobalt
The compilation docs are about as dense as Chromium's are -.-
https://developers.google.com/youtube/cobalt/docs/developmen...
What do you mean by that? WebView is just Chrome embedded inside of an Android app. Same thing already exists on Windows (Edge WebView2), macOS (WKWebView) and Linux (WebKitGTK). There's also a library that wraps all of them into a single interface:
https://github.com/webview/webview
The entire point of WebView is that it's a browser embedded inside of a different application, how do you expect it to be a "standalone project"?
Add one more: QtWebEngine -> https://wiki.qt.io/QtWebEngine
The idea is it would be lightweight (so just a few megabytes of libraries) and give the same functionality you get with an android webview (so send it html to load and javascript to run and get json results back).
I know there are quite a few options that try and do something similar. But they are all so incredibly bloated when all you want to do is use html5 for a native application UI.
All the options I mentioned are fully native and require no extra libraries.
Bravo to the Vaev team for championing unrestrained technological exploration!
The choice of C++ is bold.
Despite the security concerns often highlighted, modern C++ with smart pointers, and RAII patterns can be just as safe as Rust when done right. Vaev’s security model should focus on process isolation, sandboxing techniques, and leveraging modern C++ features to minimize vulnerabilities.
Super excited to see such raw innovation and courage in tackling a colossal task often monopolized by juggernauts like Chromium.
... Thanks, LLM, for your input!
There is also https://sciter.com/ that the author tried to find finance to make it opensource but couldn't find enough supporters.
It's not a browser.
Hoping you will expand the documentation. That tldraw file is almost unusable, no online service exists to view the file. Only thing I got was a vscode extension. Unless I have reason to ditch sublime, there is not much choices left to view your architecture documented in an obscure format.
Does anyone know what the japanese in the logo means? As I read it ジブト (jibuto) means nothing to me.
Are you open to contributions? I would love if there was a non-chromium alternative to wkhtmltopdf!
wkhtmltopdf is not chromium though? "Wk" literally stands for WebKit.
There's also https://weasyprint.org/ which doesn't use any browser engine, but rather a custom renderer.
And both of those (and Prince) can be used as a backend by Pandoc (https://pandoc.org/)
You're right, I think merged a few things together when writing the comment. What I meant is that (if you ignore PrinceXML and focus on FOSS) you're down to 3 options: - wkhtmltopdf - weasyprint - (headless) chromium with puppeteer et al.
The first one I found to be unreliable, the second one is super slow and the third can be annoying to work with.
like https://www.princexml.com/ ?
Yea, Prince is awesome. Not FOSS tho. I make some GPL or MIT licensed software and wish there was something as good a Prince with more open license.
I don't mean this as a slight against you but it's incredible how much code it takes to write a browser that barely works. I've always thought it would be fun to write a browser in erlang/elixir due to its fault tolerance (a memory from the early days when browsers would constantly crash), but browsers are so outrageously complex with such intense performance requirements the thought of even creating a repo sickens me. I mean it looks like you guys have 100+ files, with half of the files being ~500+ lines of code.
Incredible work and dedication
Browsers might be the second most complex project you could build, the first one is an OS, also browsers can be categorized as an OS actually.
oh the irony. I remember decades ago when google.com was branded as example of minimal html design, to save bandwidth as much as possible, they don't even enclose html tags.
Now google.com is loads of js crap. The SERP refuse to render without full blown js, css and cookie.
> A lightning-fast, lightweight, and secure
Let me guess, it's lightning-fast because it lacks many features and secure because it's a thousand times less code than the alternatives?
I don't want to discourage, but such description is misleading.
interesting, seeing such things be built from scratch
nice
I wish one of these projects would make a browser which only renders text (so texts and links) and no additional support for media (images, videos, audio etc).
I know there is Lynx but having a non-terminal based browser which could do it would be cool.
You might be interested in Richard Stallman's method of browsing the web:
> I generally do not connect to web sites from my own machine, aside from a few sites I have some special relationship with. I usually fetch web pages from other sites by sending mail to a program (see https://git.savannah.gnu.org/git/womb/hacks.git) that fetches them, much like wget, and then mails them back to me. Then I look at them using a web browser, unless it is easy to see the text in the HTML page directly. I usually try lynx first, then a graphical browser if the page needs it. [0]
I know you wanted something other than lynx, but you could do this with EWW (Emacs web browser or any graphical browser, provided that your proxy wget dropped the images.
[0] https://www.stallman.org/stallman-computing.html
Wow. At a certain level, I'm glad that people so peculiar exist.
Something like Dillo? (You can disable image rendering in Dillo).
For distraction-free reading?
Something like Reader View in safari / firefox?
Those show media.
Then google will use text to show ads.
Isn't Ubuntu doing that for at least 3 years or so in terminal during system update?
Text based ads would be less distracting.
Not if they're inline and you've read an ad before you realized it. Like a YouTube sponsor segment. lol
Fair. However, text based ads are also very easy to filter out using some sort of extension no?
Yeah, I actually use NordVPN (this comment’s sponsor) for this.
Remembering when Google only served text based ads.
Cool idea!
[flagged]
The fact that other browsers are huge engineering efforts only makes it more interesting to many. It's arguably one of the hardest things a programmer could build, how could you not wanna build one!
Yes but why do it in C++? There is no compiler enforced safe mode and you're by definition implementing an engine to run hostile code in it.
> There is no compiler enforced safe mode
It's still early days, but Clang can check some lifetimes, using the [[clang::lifetimebound]] attribute [1]. You can also restrict unsafe pointer usage [2] outside designated blocks of code—somewhat like Rust’s unsafe keyword.
[1] https://clang.llvm.org/docs/AttributeReference.html#id8 [2] https://clang.llvm.org/docs/SafeBuffers.html#buffer-operatio...
Since 2012, all future browsers will be written in Rust and looks like it will always be that case. Perhaps, programming a browser in Rust is a painful activity that nobody seems to have managed to complete (writing parts of it since the Servo days). Talking about safety though, nonstop, yeah no shortage of that.
FWIW nobody has written a new complete browser engine in any language since then, not just Rust.
I personally have had enough of the "security" bullshit after seeing what it's done to "secure" control over the population and put that in the hands of the enemy.
I thought you were happy that your man was finally fixing things this year.
You of all people should know better than to bring that crap here, but guess how the Rust crowd leans politically.
I think if you're going to bring up how security has a political angle to it (repeatedly!) you should not be surprised if people remember the arguments you recycle for the topic
dudes... c++... definitive nono. Please, move to plain and simple C99+.
[flagged]
I know you intended to be helpful and didn't mean to be unkind.
But, this site is called Hacker News, and it's always been one of the site's most important roles, to feature and celebrate novel and interesting projects that people hack on, for whatever reason they choose.
There are all kinds of things that can be learned by starting with a blank slate and re-implementing something as ubiquitous and foundational as a web browser.
Over the years, many users have enjoyed undertaking a course called "Nand to Tetris" [1]. I hope to find time to do it one day. I don't expect it will make me substantially more employable, but I think I'll enjoy learning about the fundamentals, and I'm sure it will be beneficial in my work somehow.
Please let's remember that the playful exploration that happens through a project like this can lead to all kinds of benefits that might be non-obvious, and that it’s fine to appreciate the effort for its own sake.
[1] https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
This comment might be one of the meanest comment I have ever seen.
Hm, I'm sorry you feel that way. It's not meant to be mean. On the contrary; Instead of encouraging someone who I feel is going down a wrong path, to me it's kinder to express my view that they aren't. I have personally wasted years of my life on technical projects, and would have been better off if someone had told me that it was a bad idea.
I'm of the opinion that these passion projects are incredibly important.
Your passions projects were problably also far more important to your growth than you give them credit for.
Scratching an itch is how we, as programmers/engineers/whatever, grow. It is also how we stumble into solving real problems and make our mark on the world.
Who knows, this could become the next big player in the browsersphere, or maybe it'll pivot into something else, or perhaps it will spark someones imagination. At the very least it has (probably) already been a source of creative bliss and pride for the ones involved, which in my opinion makes it worthwhile.
I agree
I understand what you are saying and don't fully disagree. You can allocate time & energy into immediate real world solutions while reaping the personal growth. There is certainly a balance.
The counter-point is that in the case of a web browser you are studying deeply one of the most impactful technologies to exist, and you will learn 80% of the most important lessons with a minimal working build, maybe 0.1% of the real thing. You may learn and execute much faster too because there is a clear blueprint, and you are likely riding a wave of passion that will carry your mind to places you won't have expected.
The perspective gained puts you in a much better place to identify & execute successfully more impactful work. The work may be the seed of something more important, but unseen or unknown yet.
Except that it’s going to be used as odoo’s pdf generator so it’ll actually get used by at least thousands of people