9 ms·

Blitz: A lightweight, modular, extensible web renderer

433 points by whatever3 2y ago

Fire-Dragon-DoL 2y ago
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.
- nicoburns 2y ago
  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.
  - RamblingCTO 2y ago
    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.
    - nicoburns 2y ago
      It's kinda early, but we're looking at collaborating with https://typst.app/ 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)
    - nine_k 2y ago
      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.
      - rescbr 2y ago
        I second this suggestion. For one use-case that it’s just a single page, I’m using SVG + rsvg-convert.
    - Semaphor 2y ago
      Weasyprint [0] works pretty well for us. Especially for basic things, it does everything. It’s only lacking some very advanced CSS Print features. [0]: https://doc.courtbouillon.org/weasyprint/stable/ https://doc.courtbouillon.org/weasyprint/stable/
  - Fire-Dragon-DoL 2y ago
    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
- OtomotO 2y ago
  Oh god, yes... Wkhtmltopdf is a resource hog. 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)
- cedws 2y ago
  Check out gotenberg[0], it might fulfil your needs. I use it in GitHub Actions to convert my CV to PDF. [0]: https://github.com/gotenberg/gotenberg https://github.com/gotenberg/gotenberg
  - Fire-Dragon-DoL 2y ago
    That looks amazing
- MrPowerGamerBR 2y ago
  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.
owenpalmer 2y ago
> It is effectively a lightweight webview except that the JavaScript engine is replaced with a native Rust API Woah, this looks promising. Basically Tauri without JS in the loop? Music to my ears.
- OtomotO 2y ago
  no, tauri uses the native web view, so different per platform. Blitz is an own renderer
- nicoburns 2y ago
  > Basically Tauri without JS in the loop? 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.
- afavour 2y ago
  I think Sciter is probably the better comparison: https://sciter.com/ https://sciter.com/ 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)
  - nicoburns 2y ago
    Yes, Sciter is definitely pretty close. 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 https://github.com/DioxusLabs/dioxus which is a react-like UI framework but in Rust.
atoav 2y ago
This is what we need. I hope somwone picks up working on a python implementation.
nicoburns 2y ago
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: https://github.com/DioxusLabs/blitz/issues/23 https://github.com/DioxusLabs/blitz/issues/23
- 9dev 2y ago
  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?
  - nicoburns 2y ago
    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.
Woshiwuja 2y ago
Could be cool using it with a backend + htmx. But i guess JS engine is not even in the mix, so i wonder how you could do that
- OtomotO 2y ago
  Simple, you replace htmx with Dioxus or later maybe leptos ;-)
  - Woshiwuja 2y ago
    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."
  - nicoburns 2y ago
    It would probably also be possible to port the HTMX client to Rust/Blitz if somebody was motivated to do so.
- eterps 2y ago
  That would be legendary. > But i guess JS engine is not even in the mix 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.
  - nicoburns 2y ago
    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.
webprofusion 2y ago
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?
- nicoburns 2y ago
  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.
darkteflon 2y ago
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.
- rapsey 2y ago
  For GUI apps which are as flexible as something built with Electron but do not run Javascript.
- nicoburns 2y ago
  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!
bigbones 2y ago
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
- nicoburns 2y ago
  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.
primering 2y ago
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.
- nicoburns 2y ago
  > How is the performance? 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).
dgb23 2y ago
This project looks very useful at a glance. 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“?
- philistine 2y ago
  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.
  - MrJohz 2y ago
    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).
    - 2y ago
ogogmad 2y ago
Any connection to Blitz Basic or Blitz 3D?
- nicoburns 2y ago
  Nope. I'd not heard of those until you mentioned them!
  - queuebert 2y ago
    What about Blitz++?
    - somastoma 2y ago
      [flagged]
indexerror 2y ago
This is what we need.
alberth 2y ago
TIL about Dioxus https://dioxuslabs.com/ https://dioxuslabs.com/
joshmarinacci 2y ago
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. https://en.wikipedia.org/wiki/Flying_Saucer_(library) https://en.wikipedia.org/wiki/Flying_Saucer_(library) PS: amazingly it is still being updated! https://github.com/flyingsaucerproject/flyingsaucer/releases/tag/v9.9.0 https://github.com/flyingsaucerproject/flyingsaucer/releases...
deleted 2y ago
[deleted]

433 points by whatever3 2y ago

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.

nicoburns 2y ago
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.
- RamblingCTO 2y ago
  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.
  - nicoburns 2y ago
    It's kinda early, but we're looking at collaborating with https://typst.app/ 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)
  - nine_k 2y ago
    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.
    - rescbr 2y ago
      I second this suggestion. For one use-case that it’s just a single page, I’m using SVG + rsvg-convert.
  - Semaphor 2y ago
    Weasyprint [0] works pretty well for us. Especially for basic things, it does everything. It’s only lacking some very advanced CSS Print features. [0]: https://doc.courtbouillon.org/weasyprint/stable/ https://doc.courtbouillon.org/weasyprint/stable/
- Fire-Dragon-DoL 2y ago
  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
OtomotO 2y ago
Oh god, yes... Wkhtmltopdf is a resource hog. 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)
cedws 2y ago
Check out gotenberg[0], it might fulfil your needs. I use it in GitHub Actions to convert my CV to PDF. [0]: https://github.com/gotenberg/gotenberg https://github.com/gotenberg/gotenberg
- Fire-Dragon-DoL 2y ago
  That looks amazing
MrPowerGamerBR 2y ago
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.

owenpalmer 2y ago

> It is effectively a lightweight webview except that the JavaScript engine is replaced with a native Rust API Woah, this looks promising. Basically Tauri without JS in the loop? Music to my ears.

OtomotO 2y ago
no, tauri uses the native web view, so different per platform. Blitz is an own renderer
nicoburns 2y ago
> Basically Tauri without JS in the loop? 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.
afavour 2y ago
I think Sciter is probably the better comparison: https://sciter.com/ https://sciter.com/ 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)
- nicoburns 2y ago
  Yes, Sciter is definitely pretty close. 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 https://github.com/DioxusLabs/dioxus which is a react-like UI framework but in Rust.

atoav 2y ago

This is what we need. I hope somwone picks up working on a python implementation.

nicoburns 2y ago

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: https://github.com/DioxusLabs/blitz/issues/23 https://github.com/DioxusLabs/blitz/issues/23

9dev 2y ago
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?
- nicoburns 2y ago
  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.

Woshiwuja 2y ago

Could be cool using it with a backend + htmx. But i guess JS engine is not even in the mix, so i wonder how you could do that

OtomotO 2y ago
Simple, you replace htmx with Dioxus or later maybe leptos ;-)
- Woshiwuja 2y ago
  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."
- nicoburns 2y ago
  It would probably also be possible to port the HTMX client to Rust/Blitz if somebody was motivated to do so.
eterps 2y ago
That would be legendary. > But i guess JS engine is not even in the mix 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.
- nicoburns 2y ago
  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.

webprofusion 2y ago

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?

nicoburns 2y ago
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.

darkteflon 2y ago

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.

rapsey 2y ago
For GUI apps which are as flexible as something built with Electron but do not run Javascript.
nicoburns 2y ago
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!

bigbones 2y ago

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

nicoburns 2y ago
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.

primering 2y ago

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.

nicoburns 2y ago
> How is the performance? 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).

dgb23 2y ago

This project looks very useful at a glance. 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“?

philistine 2y ago
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.
- MrJohz 2y ago
  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).
  - 2y ago

ogogmad 2y ago

Any connection to Blitz Basic or Blitz 3D?

nicoburns 2y ago
Nope. I'd not heard of those until you mentioned them!
- queuebert 2y ago
  What about Blitz++?
  - somastoma 2y ago
    [flagged]

indexerror 2y ago

This is what we need.

alberth 2y ago

TIL about Dioxus https://dioxuslabs.com/ https://dioxuslabs.com/

joshmarinacci 2y ago

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. https://en.wikipedia.org/wiki/Flying_Saucer_(library) https://en.wikipedia.org/wiki/Flying_Saucer_(library) PS: amazingly it is still being updated! https://github.com/flyingsaucerproject/flyingsaucer/releases/tag/v9.9.0 https://github.com/flyingsaucerproject/flyingsaucer/releases...

deleted 2y ago

[deleted]