I didn't submit this, but I'm the lead dev for Blitz. AMA.
One thing to note is it's not quite ready yet:
- The text input and focus system are pretty basic
- We don't support scrolling (other than the root viewport)
- Complex CSS selectors like nth-child and :has aren't working correctly yet.
- Event handling integration with Dioxus (the React-like framework that sits on top of Blitz) isn't robust or fleshed out yet (only clicks work, there is no preventDefault)
- The currently networking is super-dumb and does synchronous requests on the main thread. We need proper async and/or multithreaded networking.
- We have put very little work into performance - we're currently recomputing style/layout/paint every frame.
- Relatedly: We have few dumb memory leaks where nodes are not cleaned up. We know where these are, we just haven't fixed them yet.
- Less critical, but things like shadows, web fonts, calc, float layout, and form controls other than text input are missing (see README for more).
All of these are basically a case of "building a webview is a big task, and we haven't gotten around to that yet". We're hoping to have something a bit more complete in 2-3 months time.
There are some more screenshots here:
Personally, I would rather design a new document format, with simpler semantics, that is easier to render.
HTML feels quite complicated, and also it was not designed for dynamic rendering.
I like lean and kiss, and html doesn't feel like it's lean or simple enough for me.
You might like this article then, by the team lead of Flutter.
https://docs.google.com/document/d/1peUSMsvFGvqD5yKh3GprskLC...
https://news.ycombinator.com/item?id=34612696
By the prominent semantic markup advocate and Web standards developer Ian “Hixie” Hickson, who now works on Flutter and, it seems, gave up on the Web. The article proposes a modern riff on the Flash VM more or less.
The HN link goes into depth on why he gave up on the web, it's quite an interesting read.
It really is, it’s just that I don’t want to live in the world where his proposal is the main way to discover and deliver information. His solution to semantics going unused is motivated in the last paragraph, and I just can’t bring myself to feel any of the enthusiasm the writing attempts to convey:
I also have to admit I simply don’t—can’t—trust a proposal to make the (path of least resistance of the) Web less inspectable when it comes from the general direction of Google, even when it’s honest-to-goodness Hixie writing one upon evidently deep reflection; the same way I don’t trust a proposal to make a compiler toolchain collect user data by default when it comes from that direction, even when it’s honest-to-goodness Russ Cox writing one upon evidently deep reflection.
(In the case of Go telemetry, I still remember how Cox responded to a privacy-related question I raised on HN—but don’t even remember now—by proposing the organization maintain an anonymizing proxy for its many employees. Which was a fairly satisfactory solution, if you’re an organization and have many employees. And it seemed clear his mind had no other cases in its working set. Maybe it’s just something in the air there.)
I don’t mean to pass judgment here, to be clear. Hixie in particular has done more to improve the open Web than most people whose explicit job it was to improve the open Web, let alone web programmers, let alone programmers in general (the only cohort of those to which I can lay even a vague claim of membership). I don’t even mean that my upfront bias here is correct or should be emulated by anybody.
I only mean to warn you that I’m just unable to engage with the proposal without considering its source, most of all emotionally, so you should keep that in mind when I say it and its apparent excitement feel bleak, like a coat of bright paint on a rusty playground slide in the midst of a concrete Constructivist slum.
His proposal is more for web apps, not web sites that have information on them, so the way he talks about all of those topics, like "we will only gain as we unleash the kinds of amazing interfaces that developers can build when you give them the raw bedrock APIs that other platforms already give their developers" seems much more suited to, well, interface design, rather than informational conveyance in the form of a web page. On that aspect, I agree, it's not necessary to cram a document object model into an interface design model, which is where Flutter comes from, precisely understanding that fact, and where, it seems, all the new WASM and WebGPU etc renderers are coming from too.
He also left Google yet still maintains his stance in the article, to my knowledge, if that's any consolation to you that he's not necessarily thinking about the topic from a Google lens, at least, not anymore.
That sounds awful. Some of my favourite thing about the web are the semantics. This like links that have common shortcuts across all sites (like open in new tab) and a rich contect menu (send to another device, archive at archive.org). I have extensions to translate text to find URL anchors in documents.
If the web primatives where WebHID + WebGPU every site would lack any of these.
Of course this would come from the Flutter people who don't seem to care about this. Flutter on web is completely unusable and often Android and desktop versions are barely tolerable.
There's no reason extensions can't be made for it as well, HTML and CSS in the browser is just rendered via Skia anyway, so it's not much different to keep the renderer but change out the underlying languages. This is in fact exactly what Flutter does.
How do you solve the catch 22 of "no content means no users means no content"?
*gestures vaguely at Gemini*
(serious question, because I too want that simpler, lighter version of the web).
You could write a translation or compatibility layer for web content that reduces it to your minimal version.
But then no one bothers implementing your document format because their existing HTML already works and it's not worth investing more time into such a small userbase, and then you're maintaining even more code
That's not necessarily true. Markdown is a good example of compile-to-html format that has gained huge popularity.
As a transitive format. There are no places full of Markdown documents to read and share, where Markdown is the final display format. It's all translated to HTML.
If you did invent a "markdown over http" spec, it would be about 15 seconds before someone reimplemeted it as a JS library.
In fact, if I was trying to build "markdown over http" I'd start with the JS library. Skip the native browser application entirely.
da fuq
https://en.m.wikipedia.org/wiki/Lean_software_development
https://en.m.wikipedia.org/wiki/KISS_principle
Millions of developers know html/css
That's fair. One of the things that I hope Blitz's modular approach will enable is more experimentation around this kind of things. It should be quite easy to take the rendering support and add your own syntax or layout algorithms for example.
How feasible this is in practice remains to be. I'd be interested to see/hear what your vision would look like.
Why not just use a markup (markdown adoc djot) + CSS?
The documents are already out there
You can probably carve out a subset of CSS that's relevant - greatly simplifying your life
What the internet needs is another IPv6, sure.
Ohh, this is interesting. I'm just now looking for a solution to capture screenshots of websites, ideally from a previously crawled representation. From what I can gather, all existing offerings just run a Chromium instance and request a screenshot from that, which is pretty expensive (both in operating and as a SaaS product).
So, Blitz should be a pretty ideal fit for that, right? Can it run in headless mode and save a screenshot currently?
It can't, but it'd probably only be a few hours work to add. We'd just need to plug the rendering library we're using into an image encoder rather than a windowing library. There might also be some extra work required to do tiling if you wanted a screenshot that is the full height of the HTML page (bigger than will fit in a single GPU texture), but I can't imagine that would be too hard.
That’d be an amazing extension with lots of potential to mix up the existing Screenshot aaS business. I’m no Rust dev, so I can’t help here, but I’ll follow the project closely!
Given general css support is not complete, would you really want a screenshot of something that might look radically different on a commonly used browser?
I guess perhaps such functionality will be more useful when the CSS support is more complete?
Many websites don't render properly anymore without Javascript. A pure "html + css renderer" would probably be of limited utility for screenshotting.
You can use Playwright with Webkit, which is much lighter weight than Chrome.
You might also look into trying Prince XML.
Its happy path is typesetting via HTML/CSS, but it may fit your use case as well.
Out of cursiosity, what's the motivation of combining a bunch of different components yourself over building on something like Servo or webkit?
You can't remove the JavaScript engine from Servo.
Why would that be? It seems quite unlikely to me.
Because it is central. From what I understand the DOM is completely JS. Blitz is basically the project of removing JS from servo.
It uses the GC from the JS engine for it's entire DOM implementation which definitely makes it tricky. There are also some other bits you'd probably want to rip out like gstreamer for media support.
We looked at using Servo's layout support. But it isn't really designed to be used standalone (although it could be if that was prioritized!). And we'll probably add a Webrender rendering backend at some point (Blitz is designed to have pluggable renderers).
1. Projects like Webkit are intimidating from both a codebase size and a commit frequency POV. We don't have the expertise or the engineering bandwidth to maintain such a solution.
2. We hope that by building a modular solution we might be able to lower the barrier to entry for building browser-like software.
3. We're a lot smaller. Servo is 100mb+. Blitz is 20mb out of the box. Potentially as small as 3.5 mb with optimizations.
4. We want to be a lot more customizable. Want to add your own layout algorithms? Image formats? Build your own native widgets with custom painting and accessibility? Fit into your existing render backend? Then we want that to be possible. Don't want SVG support? or AVIF support? Or network support? Or Float support? Then you should be able to disable it and not pay the cost for it.
5. We want our components to be usable in other contexts. For example Taffy, our layout library is used in several GUI frameworks. Many of our other dependencies are also generally usable.
What's your story regarding accessibility? Done? Planned? "we pretend disabled people don't exist until the government tells us otherwise"?
We have the basics (exposing an accessibility tree that is visible to screen readers, a keyboard controllable focus system). There's a lot more work to do be done to make it work well (but that's also true of Blitz in general).
We're building upon https://github.com/AccessKit/accesskit which provides a cross-platform abstraction over the OS accessibility APIs.
Hi, lead AccessKit developer here. Thanks for prioritizing accessibility even at this fairly early stage of the project.
Why are you so hostile?
I think the hostility is understandable when you consider that blind and other disabled people, like myself (I'm partially blind) and the poster of that comment, live every day having to work around widespread indifference toward our needs. I'm not immune to it myself; see some of my older HN comments on GUI toolkit accessibility, before I started AccessKit.
From the readme: "Blitz builds upon: [...] AccessKit for accessibility"
Personally I wonder what the motivation behind choosing "Blitz" as the name was. Sure, it means "flash" or "lightning" in German, but it also has some pretty negative historical connotations. E.g. if you google "blitz wikipedia english", you get "The Blitz" as the first result, which refers to the bombing campaigns of the Nazis against Great Britain during WW2 (https://en.wikipedia.org/wiki/The_Blitz). Also, there is the term "Blitzkrieg" (https://en.wikipedia.org/wiki/Blitzkrieg), referring to the Nazi invasions of Poland and France.
It's supposed to have connotations of speed. I think it's pretty commonly used in this way in English.
That seems like kind of silly objection, why should a common German word be considered harmful because it was used for a bad thing one time?
The word is in common use, especially terms like "ad blitz", "press blitz", etc. One of the headlines in the New York Times yesterday was "Summer Blitz Exemplifies Status of Remade Contest". A search [1] reveals many uses.
[1] https://www.nytimes.com/search?query=blitz
have you built Blitz for others to build browsers on ?
I build Wootzapp (https://github.com/wootzapp/wootz-browser) - we are kind of like Robinhood for data labeling. people can spend time labeling web data/images, etc in the browser and earn. Right now we are based on Chromium. Wondering if Blitz is looking to be the pluggable renderer for other browsers.
P.S. we are on the mobile (android today and ios tomorrow).
We've definitely built Blitz for other to build on. Whether it's feasible to build an entire browser on top of it... maybe. But for the being we are focusing primarily on use cases that don't need everything a full browser engine provides and can restrict themselves to a subset:
- Application UIs
- High-fidelity markdown previewing
- Perhaps PDF rendering, etc.
- Embedding web content within a wider system in an integrated way.
Etc.
It would be very cool if someone wanted to add actual JS scripting and DOM APis on top though.
How about rendering with print specific CSS to images/pdf ?
Images is easy. Although we'd need to support the print-specific CSS in layout. PDF is more complex but definitely doable. It wasn't part of our initial plans but is rapidly making it's way up the priority list due to popular demand (and we are of course an open source project, so we'd be very open to people contributing PDF rendering support).
Could you share what are the most complex engineering parts that you should deal with? Could you share your engineering documents even if they are just WIP?
Personally I am interested in how engines like Blitz, Servo, et al could be built in the future using formal methods practices. For example, start with definitions and generate part of the system. Nowadays, this includes LLM but I see them more like great tools than AI systems. Also things like Z3 comes to my mind.
BTW, some of my companies has a research branch on things like this.
I get it. I did my last project with a Web UI because that's the only reasonable cross-platform UI rendering engine I could find. And on Linux, a far superior choice to GTK, which doesn't seems credible because it requires a complete reimplementation of your UI code on every major release, and QT which is held hostage by commercial interests, and licensing terms that are inscrutable.
For a UI engine for native applications, it seems like a sensible strategy: use a layout language that developers are likely to already be familiar with.
Hopefully, in the longer term, there will also be a Blitz-TML library with higher-level UI components as well.
Good luck with this. It looks interesting.