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.
With any of this, isn’t it a, “build it and they will come,” situation?
Web Assembly, for example, is pretty pointless if browsers don’t support it. Browsers now support it, so it can be used, and that’s slowly happening.
It seems like the new document standard would need to be written, the benefits would need to be demonstrated, to the point support is integrated into the mainstream browsers, and then people who see benefit from the (I assume) easier/faster/better development, can start using it for new projects or integrating it into existing projects.
Trying to make an entirely new internet based on a new document standard would be rough. At this point, I don’t see that as a way forward, unless it brings something extremely compelling that users want and go crazy for, which can’t be duplicated with existing technology. I’m thinking Napster levels of hype and consumer desire.
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
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 write a "markdown over http" spec and implemented a browser for it, 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.
One problem with markdown is it's technically a superset not a subset of HTML. You can put a canvas and video that's in it. It's not a great standalone format
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 read text out of a bunch of pixels rendered on a canvas? Yes the dom is eventually rendered by Skia but still exposes an api for querying the underlying structure
Flutter also exposes the semantics tree via the DOM so you can actually still target elements, but yeah if you want to target the WebGPU elements, there needs to be a new API for that, which I believe there will be in the future because a lot of WebGPU renderer are coming out, in Dart, Rust, C#, etc.
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.
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:
> The parts of the web that have actually delivered are the ephemerality and the security model, the indexability (but only for content, not apps), deep linkability, and the platform-independence. We can keep all those, and throw out the decades of legacy that's holding us back, and we will lose nothing, 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.
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.
A lot of people don't really feel like Flutter & the towards a modern web stack ideology are "web" apps. None of our extensions will work, our accessibility tools will all be broken.
It's an entirely new stack for apps unlike what the web is. Maybe that can be good for developers, maybe, perhaps, but gee it sure seems like a really bad bargain for users, user agency, and the technical legibility of our online world.
Yes, it's an entirely new stack, that's what the higher level commenter was talking about. I realize we've discussed this same article before but I do believe it is the way forward, for web apps at least, because the current HTML and CSS stack is really not as good as it could be, and as well, we are seeing a lot of new renderers in various languages coming out, so they'd need a new unified API. There is no reason to think that extensions would break once that new API is finished, because at the end of the day, it's all just Skia rendering the content, whether it translates from HTML or WASM.
I spent over a decade being the center of the ecosystem for something akin to web extensions for native Objective-C++ apps on iOS/macOS. I maintained a similar solution for Android/Java, and was starting work on something similar for C#.
The HTML/CSS web isn't some panacea for extensions. The code is minimized to the point of being obfuscated, and JavaScript engines provide almost no introspection into frames or closures. After-the-fact extending these apps is hard.
I would very honestly rather be sitting around in someone else's Flutter app with the goal of making some extension modification to the behavior than in someone's crazy DOM-based app, as at least the rules are clearer.
As it stands, though, HTML/CSS are just too complex. I could--probably alone, but certainly with a small team--build a browser that worked fully if the spec were something like WebAssembly connected directly to something like WebGPU.
The idea of a monopoly on browsers at that point would be laughable: we'd have a hundred of them, made by every company of any decent size, embedded into everything, and that spec would be both stable and would matter.
As it stands, we have like 2.5 web browsers at best, and I'm betting we are going to be down to 1.75 or so in the not-so-distant future. And yet, we continue to make the web MORE complicated to implement, which is simply demoralizing.
We can't even build a partial / limited browser renderer anymore, as progressive enhancement is dead now: if you don't support the full set of features then you'll run into modern React sites just giving up and showing a blank screen: even a browser that was fully capable just a few years ago is now dead in the water as it won't have all the crazy new CSS and JavaScript features you need.
And, why are we making this so hard? Because we think that the web is somehow more transparent than even a native app? It really isn't. There is a reason why we had tons of really invasive app behavior extensions for iOS and you almost never see anything integrated when it comes to web extensions: it is because the web's programming model is actually much more difficult to introspect and modify for anything other than superficial styling or wedged-in buttons that add mostly tacked-on behaviors.
There was someone recently on HN who went and added some feature to Gmail as an extension, and they seriously just bring up their own pane and require the user to have Oauth tokens for Gmail from their app, and the reason was because it is just too difficult to reach into Gmail and massively modify its behavior... but we would do that sort of thing on iOS all the time and it was not just easy, it was fun! Maybe a browser could be built that would give users the same kind of extension ability for the web--by ripping through all of the layers of JavaScript scope optimizations--but no one is going to ever build that as building a browser at all is an impossible task :/.
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.
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?
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.
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).
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.
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.
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).
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.
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.
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.
“ Anecdotally, my psoriasis disappeared after I switched to a strict vegetarian diet. I can't prove it, though, so I don't go on Reddit making unscientific claims I can't back up with evidence.”
There will always be exceptions like your case. However it is clearly the case that there aren’t hundreds of different types of gut fungi which grow out of control over a dysbiosis occurs in the guts microbiome. There is generally one type and it is called Candida. The problem is called a Candida overgrowth. Candida generally eats carbohydrates and sugar. A carnivore diet will generally starve it and cause a die off. The Candida generally released toxins that cause auto immune disorders.
Now I’m speaking in the cases of most not all people who experience auto immune disorders and where those disorders are caused by the guts microbiome.
There are also the cases where the gut has been damaged by gluten and other plant materials and is leaking food into the blood.
As far as I’m aware no animal flesh of any type does such damage to the gut. No fungi eats animal flesh.
You seem to think gut dysbiosis is one bacteria dominating others. No. It is a fungus in most cases. A single called yeast that rapidly duplicates called Candida and eats plants.
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).
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.
Most newer GUI libraries entirely neglect accessibility and focus exclusively on rendering. Maybe accessibility is seen as too much effort for too little gain?
It's kind like most CLI programs nowadays don't come with a man page (nor an info page) and think that an autogenerated `--help` is enough. Except that nobody is excluded from using your application just because it doesn't come with proper documentation
Create native applications that use the widely popular HTML/CSS paradigm for layout, but leave out much of the heavyweight stuff that a full JS/DOM/browser API implies. This looks like it can enable very large improvements over packaging browser engines like electron etc. do.
Funnily enough, I just recently listened to Casey Muratori on Richard Feldman‘s podcast, where they where extremely critical of CSS.
Some of the stories they told, like having to prerender and dynamically measure web pages in order to achieve some very simple layout relationships hit right at home.
Writing CSS feels, as Muratori said, more like presenting a case in the court of law, instead of building upon simple primitives.
Now there’s of course a very widespread need or want that is met by this project. Not just in terms of familiarity but also compatibility and the fact that „happy path CSS“ is incredibly productive.
But maybe there’s an opportunity to provide a simpler, general layer that a user of this can drop down to.
Perhaps the authors can find inspiration by looking at CSS houdini, which tries to make CSS extensible via a JS API. Or maybe that’s what they mean by „Custom Widgets“?
> Create native applications that use the widely popular HTML/CSS paradigm for layout, but leave out much of the heavyweight stuff that a full JS/DOM/browser API implies. This looks like it can enable very large improvements over packaging browser engines like electron etc
That's pretty much the pitch!
> Some of the stories they told, like having to prerender and dynamically measure web pages in order to achieve some very simple layout relationships hit right at home.
> Writing CSS feels, as Muratori said, more like presenting a case in the court of law, instead of building upon simple primitives
> Perhaps the authors can find inspiration by looking at CSS houdini, which tries to make CSS extensible
Pluggable layout algorithms are definitely something I'd like to enable in Blitz. I suspect JS for layout will be too slow in most cases. But this is an area in which we have an advantage with our API being in Rust. And our layout engine Taffy (https://github.com/DioxusLabs/taffy) is already highly modular.
Custom widgets would go beyond just layout and allow for fully custom layout, paint, accessibility, event handling, etc similar to a widget in a traditional GUI toolkit like GTK or Cocoa.
I also have a proposal to add a new unit to CSS itself (inspired by how many non-web UI systems do layout), which has the potential to greatly simplify web layout in the common cases https://github.com/w3c/csswg-drafts/issues/8267. It's been on the back burner for a bit, but I should really get back to it at some point (I really want to actually implement the algorithms).
“ Create native applications that use the widely popular HTML/CSS paradigm for layout, but leave out much of the heavyweight stuff that a full JS/DOM/browser API implies. This looks like it can enable very large improvements over packaging browser engines like electron etc. do.”
I’d be interested in something like that for simple, web browsing or apps. Sciter was the only one I knew about. It was proprietary but had innovative licensing.
We need a strict CSS that removes the cruft and promises improvements in performance. I don't know why the browsers haven't offered it yet. Like just remove float.
Float is necessary for some layouts, particularly documents where you might have a lot of text that wraps around a handful of images. I don't believe it's possible to implement that without floats (at least not without some clever shenanigans).
I think most attempts to simplify CSS are going to fail in this way. Almost all of CSS right now is useful for something or other — there's actually not a huge amount of cruft in there (in comparison to, say, JS, where a lot of built-in APIs and functions should not be used, or need to be used in the right way). It's just that CSS gets used for everything from applications (where grid/flex are mostly enough) through to documents (where floats and tables become more important).
Yeah the problem with CSS comes from its weird design with many implicit rules (border collapse, block formatting context, and hundreds of other quirks), but not from the fact that it's “bloated”.
So if you want to address CSS's problem, they must:
- invent a more coherent and easy to use styling language
- implement a GPU-accelerated renderer
- write tons of documentation to make sure people will find how to use it
No wonder why people stick with CSS for everything nowadays even if the consensus is that it's a really annoying tool to work with.
My point is that this language could be built on a foundation of CSS. Like don't implement the flow model, just implement box. Change how all the border collapses and block formatting work, but keep CSS as the language.
I mean they should even change the order priority to make it fit with typical conventions.
I built an open source project like this some years ago (holy carp! 20 years ago) called Flying Saucer. It was a pure Java HTML + CSS2 renderer.
I imagined people would use it to render rich text UIs in games, but the killer use ended up being server side PDF generation. It was far easier to generate HTML and render to a PDF than to use the various PDF report generation APIs available at the time.
Blitz looks cool. I'm excited to see more GUI libs in Rust.
Kinda, although Tauri uses system webviews, whereas we're building our own (partly on top of Servo components and other general purpose libraries, partly custom). In some ways we're closer to Sciter but without JS.
It is a ground-up implementation of HTML and CSS rendering. IIRC it used to have its own programming language but now uses JS.
I’ve long been interested in this kind of thing but haven’t actually played with Sciter in depth. Used to be that the licensing was a concern but looking at the site now it seems the terms have changed to be much more flexible.
(also worth pointing out that if you want a system webview without JS… just disable JS on a system webview)
We think we can do better CSS support. Sciter has good CSS2 layout support, but only has it's own proprietary equivalent to Flexbox. Our CSS2 support is currently pretty patchy, but we have good Flexbox and CSS Grid support. We also have full support for things like media queries and css variables which I don't believe Sciter supports.
Regarding "just disable the JS":
You can, but then you won't have scripting support. Blitz still has scripting support without JS using https://github.com/DioxusLabs/dioxus which is a react-like UI framework but in Rust.
(and the links on sciter.com go to the old repo, abandoned for a long time.. I really don't understand why this is supposed to motivate anyone into using it)
Interesting. Just today I was looking for wkhtmltopdf replacement after a horrible experience with puppeteer and trying to run chromium headless (do NOT try to run it with jemalloc in LD_PRELOAD). I did solve the problem, but I preferred the simplicity of a renderer.
You're not the first person to show interest in the PDF rendering use case. I think we'd probably need better support for some of the print-orientated CSS properties and page-based layout (for splitting layout across multiple discrete pages and controlling where page breaks occur), but it's definitely something that we ought to be able to support at some point.
You'd be a hero to a lot of people for supporting that. Current options for basic PDF reports suck. You essentially have to run Chrome (at scale possibly) for such a basic use case.
It's kinda early, but we're looking at collaborating with https://typst.app/ (a modern LaTeX alternative) on this. They already have some of the low-level PDF writing infrastructure in place, and are working on something higher-level that we're hoping to use.
(you could also look at using Typst directly if you're not tied to HTML)
BTW why not render things in SVG and convert to.PDF then? It would certainly require you to compute your own layout, but you.normally want that in a tabular report anyway. The rendering would not involve invoking a web browser though.
Yeah I'm not in hurry, but having to write a layout with css 2 was very painful. I had to resort to floats, clearfix and similar things, so I'm looking forward this
My use case was a bit different: I was trying to use Chromium Headless in Playwright as a simple way to render a element on a page, I experienced tons of random "Page crashed" and "Timed out after 30s" from Playwright.
Switched to Firefox Headless and these issues stop happening, in fact, switching to Firefox made the renderer ~3x FASTER than Chromium Headless!
The Blitz project seems very interesting and is actually what I needed, because I'm using a headless browser as an alternative because rendering everything manually using Java Graphics2D would be a pain because the thing I'm rendering has a bit of a complex layout and I really didn't want to reinvent the wheel by creating my own layout engine.
Other solutions have incomplete support for the HTML spec, so we can't quite create the pdfs we want (unless someone set down and figured it out with less modern features)
Not a comment on Blitz itself, but had never heard of Dioxus before. Is there some unwritten rule about compiles-to-wasm type frameworks where they never actually show a demo or have their own site self-hosted in the framework? Seen this like 5 or 6 times now. I see some wasm file loaded on the Dioxus home page, but it's not clear where it's being used if at all
Dioxus's site is self-hosted, but it supports server-side rendering (with hydration), so the WASM bundle is only used for interactive functionality. There are plans for a video demo in the works. Is there anything particular that you'd like to see.
Ideally a web renderer would support HTMX natively.
The general idea is that HTMX supports features that make HTML more complete:
- Why should only <a> & <form> be able to make HTTP requests?
- Why should only click & submit events trigger them?
- Why should only GET & POST methods be available?
- Why should you only be able to replace the entire screen?
Another way of thinking about it is that HTMX makes HTML elements less restrictive and more generic. If a web renderer takes that into account in its design, it could end up simpler.
Natively supported HTMX would be cool. Blitz is modular enough that this could probably be implemented as it's own wrapper around some of the core crates. And it wouldn't necessarily need to be coupled to the general HTML renderer.
Doesnt that force Rust onto you? what i was talking about was more... Language agnostic? I think this line explains what i meant:
> "We don't yet have Blitz bindings for other languages (JavaScript, Python, etc) but would accept contributions along those lines."
That's really cool! Would love to use it in my c++ projects. One thought that came to my mind: How is the performance? Could you render a relatively complex page at high frames per seconds? I usually use ImGUI which is excellent to display real-time data without even thinking about performance issues. Compared to Chromium's web rendering which burns my CPU already at 10FPS simple DOM text updates, this could be a game changer.
Currently terrible. But we've put no effort into optimization, and build upon some pretty fast dependencies so there is potential for much better.
I suspect we'll never beat Chromium in a "fair fight", but there is potential to enable things that just aren't possible in Chrome (much more powerful canvas-like APIs for example).
Looks really interesting and lots of strongly favourable responses in this thread. For those in the know: what’s something like this used for? Where does it fit in to the landscape? Is it a case of filling a specific need in the Rust front-end ecosystem, or something more language and framework agnostic? I’ve very little front end experience - the repo readme went over my head.
It's basically taking the web-centric approach to building a Rust UI toolkit. Which we hope will appeal to people who might otherwise use something like electron but want something lighter weight.
We're also building it in a modular fashion, which we hope will enable the engineering work we're putting to be reused for many other use cases. Many people on this page have proposed rendering to PDF for example, but that's just one use case amongst many!
This is impressive work, I greatly appreciate the "lightweight" aim but would it not make sense to use Servo, perhaps with build feature flags to reduce size?
Unfortunately Servo is quite monolithic, which makes this difficult in practice. So the idea is to pull bits out of Servo properly abstracted instead, while also making use of other well-engineered libraries in the Rust ecosystem. And then build our own where that isn't possible. One of the main thing's we're building ourselves is layout, which is partly because when it comes to "modern" layout algorithms like Flexbox and CSS Grid (which are particularly important for application UI use cases) our support is already quite a bit better than Servo's.
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:
https://github.com/DioxusLabs/blitz/issues/23