[HN Gopher] Blitz: A lightweight, modular, extensible web renderer
___________________________________________________________________
Blitz: A lightweight, modular, extensible web renderer
Author : whatever3
Score : 402 points
Date : 2024-08-12 04:52 UTC (18 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| Fire-Dragon-DoL wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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)
| nine_k wrote:
| 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 wrote:
| I second this suggestion. For one use-case that it's just
| a single page, I'm using SVG + rsvg-convert.
| Semaphor wrote:
| 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/
| Fire-Dragon-DoL wrote:
| 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 wrote:
| 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 wrote:
| 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
| Fire-Dragon-DoL wrote:
| That looks amazing
| MrPowerGamerBR wrote:
| 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 wrote:
| > 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 wrote:
| no, tauri uses the native web view, so different per platform.
|
| Blitz is an own renderer
| nicoburns wrote:
| > 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 wrote:
| I think Sciter is probably the better comparison:
|
| 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 wrote:
| 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 which is a react-like UI
| framework but in Rust.
| yencabulator wrote:
| Sciter is not open source, so it's in a whole different
| category, not applicable to many many things that interest
| people on HN.
| afavour wrote:
| It actually has a BSD license these days.
| yencabulator wrote:
| Ah, they abandoned the old code with the bad license:
| https://github.com/c-smile/sciter-sdk
|
| At least something is BSD licensed:
| https://gitlab.com/sciter-engine/sciter-js-sdk
|
| They sure hate admitting that: https://sciter.com/prices/
|
| (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)
| atoav wrote:
| This is what we need. I hope somwone picks up working on a python
| implementation.
| nicoburns wrote:
| 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
| 9dev wrote:
| 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 wrote:
| 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.
| 9dev wrote:
| 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!
| nkozyra wrote:
| 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?
| nicoburns wrote:
| I guess perhaps such functionality will be more useful
| when the CSS support is more complete?
| nwienert wrote:
| You can use Playwright with Webkit, which is much lighter
| weight than Chrome.
| the_duke wrote:
| Many websites don't render properly anymore without
| Javascript. A pure "html + css renderer" would probably be of
| limited utility for screenshotting.
| TimTheTinker wrote:
| 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.
| hougaard wrote:
| How about rendering with print specific CSS to images/pdf ?
| nicoburns wrote:
| 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).
| jokoon wrote:
| 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.
| rapsey wrote:
| Millions of developers know html/css
| satvikpendem wrote:
| 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
| kevincox wrote:
| 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.
| satvikpendem wrote:
| 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.
| mananaysiempre wrote:
| 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.
| satvikpendem wrote:
| The HN link goes into depth on why he gave up on the web,
| it's quite an interesting read.
| mananaysiempre wrote:
| 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.
| satvikpendem wrote:
| 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.
| jauntywundrkind wrote:
| 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.
| flir wrote:
| 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).
| idle_zealot wrote:
| You could write a translation or compatibility layer for
| web content that reduces it to your minimal version.
| notsylver wrote:
| 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
| nicoburns wrote:
| That's not necessarily true. Markdown is a good example
| of compile-to-html format that has gained huge
| popularity.
| philistine wrote:
| 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.
| flir wrote:
| 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.
| 01HNNWZ0MV43FF wrote:
| 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
| al_borland wrote:
| 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.
| nicoburns wrote:
| 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.
| ahoka wrote:
| What the internet needs is another IPv6, sure.
| contrarian1234 wrote:
| 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
| 38 wrote:
| > lean and kiss
|
| da fuq
| JasonSage wrote:
| https://en.m.wikipedia.org/wiki/Lean_software_development
|
| https://en.m.wikipedia.org/wiki/KISS_principle
| the_duke wrote:
| Out of cursiosity, what's the motivation of combining a bunch
| of different components yourself over building on something
| like Servo or webkit?
| rapsey wrote:
| You can't remove the JavaScript engine from Servo.
| mkl wrote:
| Why would that be? It seems quite unlikely to me.
| rapsey wrote:
| Because it is central. From what I understand the DOM is
| completely JS. Blitz is basically the project of removing
| JS from servo.
| nicoburns wrote:
| 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).
| nicoburns wrote:
| 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.
| rob74 wrote:
| 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.
| infotainment wrote:
| 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?
| atombender wrote:
| 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
| nicoburns wrote:
| It's supposed to have connotations of speed. I think it's
| pretty commonly used in this way in English.
| miki123211 wrote:
| What's your story regarding accessibility? Done? Planned? "we
| pretend disabled people don't exist until the government tells
| us otherwise"?
| haunter wrote:
| Why are you so hostile?
| mwcampbell wrote:
| 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.
| mkl wrote:
| From the readme: "Blitz builds upon: [...] AccessKit for
| accessibility"
| nicoburns wrote:
| 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.
| mwcampbell wrote:
| Hi, lead AccessKit developer here. Thanks for prioritizing
| accessibility even at this fairly early stage of the
| project.
| nicoburns wrote:
| Thanks for building AccessKit and making this so much
| easier for us!
| wslh wrote:
| 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.
| sandGorgon wrote:
| 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).
| nicoburns wrote:
| 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.
| rerdavies wrote:
| 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.
| Woshiwuja wrote:
| 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 wrote:
| Simple, you replace htmx with Dioxus or later maybe leptos ;-)
| Woshiwuja wrote:
| 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 wrote:
| It would probably also be possible to port the HTMX client to
| Rust/Blitz if somebody was motivated to do so.
| eterps wrote:
| 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 wrote:
| 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.
| 3523582908 wrote:
| I really appreciated this way of looking at HTMX! Thank you!
| imacrayon wrote:
| There's some momentum around getting core HTMX functionality
| into the HTML spec so JS might not be required:
|
| https://www.reddit.com/r/htmx/comments/1ehjw7v/comment/lg09w...
| webprofusion wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| For GUI apps which are as flexible as something built with
| Electron but do not run Javascript.
| nicoburns wrote:
| 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 wrote:
| 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 wrote:
| 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.
| marcjschmidt wrote:
| 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 wrote:
| > 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 wrote:
| 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"?
| nicoburns wrote:
| > 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).
| philistine wrote:
| 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 wrote:
| 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).
| littlestymaar wrote:
| 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.
| nickpsecurity wrote:
| " 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."
|
| Like an improved Dillo?
|
| https://en.m.wikipedia.org/wiki/Dillo
|
| 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.
| ogogmad wrote:
| Any connection to Blitz Basic or Blitz 3D?
| nicoburns wrote:
| Nope. I'd not heard of those until you mentioned them!
| queuebert wrote:
| What about Blitz++?
| indexerror wrote:
| This is what we need.
| alberth wrote:
| TIL about Dioxus
|
| https://dioxuslabs.com/
| joshmarinacci wrote:
| 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)
|
| PS: amazingly it is still being updated!
| https://github.com/flyingsaucerproject/flyingsaucer/releases...
___________________________________________________________________
(page generated 2024-08-12 23:01 UTC)