HN Explorer

Show HN: Dropflow, a CSS layout engine for node or <canvas> (github.com)

404 points by chearon ↗ HN
For the last 5 years I've been working on a layout engine that targets CSS2 and some more modern properties.

Live demo: https://chearon.github.io/dropflow/

It matches browsers in all cases I can find where they agree, and it's fast. It supports `position`, `inline-block`, `z-index`, and complex properties like `float` and `vertical-align`. It doesn't support high-level layout like flexbox or grid yet, but you can get intrinsics to easily divide space yourself and paint multiple layout trees. It has a great text layout implementation, and supporting non-Latin scripts is a top priority.

I've wanted this to exist as far back as 2013, and the desire kept coming up: for a way to get detailed intrinsics, for high quality rich text layout to canvas and SVG, and for server-side rich text. We currently use it in CellEngine for our new canvas-based spreadsheet library to layout text in hundreds of thousands of cells, and will be using it soon to render PDFs with thousands of pages in a few seconds.

145 comments

[ 3.5 ms ] story [ 211 ms ] thread
big_paps
Well this looks like something useful. Can't imaging how much work is needed to first understand css and then to build a layout engine around it.
troupo
There's also Facebook's Yoga: https://github.com/facebook/yoga
Rohansi
Yoga is great but only really supports flexbox. For most cases that can be enough but inline content (as shown in the Dropflow demo) is difficult with only flexbox layouts available.
lovegrenoble
For anyone struggling with flexbox, you can use this tool to streamline the process of creating

responsive layouts, removing the need to focus on multiple properties: https://flexboxcss.com

bobajeff
This sounds close to what I've been wondering about lately. I was wondering if css and svg could be used as abstraction over graphics and UI libraries. This is my first time hearing of node-canvas looks like it fills the drawing part of the solution. While this may do the layout portion (which is all I need from a UI library).

I wonder how hard it was to implement css. I've heard it can be pretty complex.

chearon
> wondering if css and svg could be used as abstraction over graphics and UI libraries

There's another project called Sciter that uses CSS to target native graphics libraries: https://sciter.com

> I wonder how hard it was to implement css. I've heard it can be pretty complex.

It was hard, but the biggest barrier is the obscurity of the knowledge.

Text layout is the hardest, because working with glyphs and iterating them in reverse for RTL is brain-breaking. And line wrapping gets really complicated. It's also the most obscure because nobody has written down everything you need to know in one place. After I finished block layout early on, I had to stop for a couple of years (only working a few hours a week though) and learn all of the ins, outs, dos, and don'ts around shaping and itemizing text. A lot of that I learned by reading Pango's [1] source code, and a lot I pieced together from Google searches.

But other than that, the W3C specifications cover almost everything. The CSS2 standard [2] is one of the most beautiful things I've ever read. It's internally consistent, concise, and obviously the result of years of deliberation, trial and error. (CSS3 is great, but CSS2 is the bedrock for everything).

[1] https://gitlab.gnome.org/GNOME/pango/

[2] https://www.w3.org/TR/CSS22/

jsunderland323
I’m curious if you’ve implemented a rich text editor with this. I think Google Docs uses canvas. I hate the browser APIs for rich text and wonder if this could be more a viable candidate than using contenteditable for future projects
chearon
Google Docs uses canvas, yeah, and last I looked it used an empty contentEditable just to receive [rich text] input. I do think you could use this to write a document editor like Docs and side-step many of the problems with contentEditable, but I haven't tried to.

Every time someone releases a new rich text editor I'm disappointed to find that it uses contentEdtiable. Would be very interesting!

c-smile
> Every time someone releases a new rich text editor ... uses contentEdtiable

Sciter is using its own implementation (obviously).

contentEdtiable thing is indeed quite limited for general purpose WYSIWYG editor.

For example Web platform is missing transactional update [1] mechanism that allows to put custom DOM mutation groups into unified undo/redo stack.

Sciter's <htmlarea> element ( implement behavior:richtext - WYSIWYG ) allows to build specialized editors. For example it is used in Sciter.Notes [2].

[1] https://docs.sciter.com/docs/behaviors/behavior-richtext#ric... [2] https://notes.sciter.com/

Traubenfuchs
> It's also the most obscure because nobody has written down everything you need to know in one place

Your work might have been, or maybe still is, the worlds biggest chance for this to change!

c-smile
There was a whole team behind Microsoft Trident (IE engine) that was dissolved in favour of third-party (for them) Blink engine. That team was surely knowledgeable, but they had gone.

Blink source is de facto current spec. Each function, if not single line, there is a paragraph in spec.

I remember at WHATWG / HTML5 WG times when Ian Hickson (Google) was pushing whole SQLite (and its SQL flavour) to be included in HTML5 ...

The spec area is so huge and indeed obscure that even Microsoft could not handle it.

niutech
Blink source is not the spec, there are W3C specs implemented by Webkit/Blink/Gecko, see the Interop project.

It's not that MS couldn't handle its own engine, it was just not worth it for them in the long term.

Ladybird, NetSurf or Servo engines are prime examples that it is possible to create an independent web engine from scratch even not being a big corp. If they can do it, MS definitely could do it as well if they wanted.

rikroots
> working with glyphs and iterating them in reverse for RTL is brain-breaking. And line wrapping gets really complicated. It's also the most obscure because nobody has written down everything you need to know in one place

I can confirm this. I've been working on a (much simpler!) text layout engine for my canvas library over the past couple of months and the amount of complexity associated with just stamping some glyphs onto a canvas has left me screaming at my laptop on an almost daily basis. Getting a decent underline was a proud moment!

Question: did you ever find out what algorithm the various browsers are using to calculate how many words can fit on a given line? I'm almost there, except words will occasionally jump between lines when I scale the text. Really annoying!

The PR's still a work in progress, but I've got all the functionality I want in there (shaping lines to fit in non-rectangular containers, styling text, text along a non-straight line, dynamic updates, etc). Just need to test and document it all now ... https://github.com/KaliedaRik/Scrawl-canvas/pull/75

chearon
> the amount of complexity associated with just stamping some glyphs onto a canvas has left me screaming at my laptop on an almost daily basis

This made me laugh because I can relate so much. Inline backgrounds can start in LTR text and end in RTL text, and when I was implementing that I got so frustrated that I had to stop and seriously consider I might have an anger problem.

> Question: did you ever find out what algorithm the various browsers are using to calculate how many words can fit on a given line?

Not sure if I understood the question correctly, but they use a greedy algorithm where the break points in the string are the choices. If your glyphs are scaling and so is the available width, you might have a float precision problem? Browsers use integers for that reason. I'm still using floats.

Scrawl/that PR look extremely cool! I would love to some day support CSS `shape-outside`, which achieves a similar thing to what you have in your PR.

ape4
Its too bad browsers don't support this.

    // Do CSS layout in the regular document
    const doc = new CssLayout(document);
    doc.layout(...);

    // Do CSS layout on your own canvas
    const mycanvas = new CssLayout(document.getElementById('mycanvas'));
    mycanvas.layout(...);
[deleted]
(comment deleted)
Sesse__
The security implications would be interesting, unless you tainted the canvas (which makes it instantly less useful).
adtac
What security vulnerability becomes possible with native CSS-in-canvas support that's not already possible today? Or becomes easier?
Sesse__
As I understand the proposal, everything about visited link colors, for instance. Lots of cross-origin leaks. New forms of image leaks.
awesomekling
Super cool! Nice job, chearon :)
chearon
Wow thanks! Seeing Ladybird progress kept me motivated!
1oooqooq
why not ship a desktop application at this point with support for a special schema?

i can understand the abuse for server side rendering, but at this poit you pretty much have a bad browser engine. running inside a 2d hack in a browser engine. sigh.

Bjartr
Why re-invent the wheel with a special schema when CSS2 is a solid standard and widely understood? Is there no room in the world for rendering implementations between nothing at all and full-spec web browser with all the bells and whistles?
1oooqooq
I'm actually advocating against re-inventing the wheel (insider another wheel, no less)

you can still follow css spec if you want. just get a better environment than a canvas.

robbiejs
This is a big achievement, congrats! A lot of time must have been put into this I am sure. And you are also making a spreadsheet product AND a PDF (preview?) product? How do you combine it?
chearon
With this and node-canvas, you have everything you need to generate PDFs. I'll add an example to the examples/ directory for that. The spreadsheet library and PDFs I talked about in OP were examples of how we use this in our application, but are closed-source.
XCSme
Could I use this together with Pixi.JS ?
jasonjmcghee
Are you planning to add support for the missing standard tags like img and table (both very useful for pdf rendering)?
chearon
Yes, definitely. In the meantime, you can still use this to get the intrinsic sizes of cells to create rows and columns, and you can use an empty inline-block and paint the image where it's laid out. I'll put something in the examples/ directory soon.
AndriyKunitsyn
I wonder if there’s something opposite — an abstraction for the Web to provide some layout rules that are more sane than CSS.
usrusr
Feels a bit like history repeating (well, rhyming) with the time back when Java was "the language of web applets" and then Sun created the Hotjava browser and confusion reached the point where minds simply blank out. Few technological novelties have been forgotten more decidedly than Hotjava. Despite marking an intersection of two technological fields (browsers and the JVM) that have shown extreme staying power through the last quarter century.

But the idea of using html for text styling has stuck, Swing UI do text styling with html (and rudimentary css!) to this day. Html would not be a lingua franca if its use was limited to the equivalent of native speakers (browsers).

eigenvalue
I worry that this sort of technology is going to lead to webapps that aren't really what we've grown to think of as "the web" but which will instead be closer to a VNC window where you just see pixels and can't interact with anything or see how stuff works in devtools.
jdiff
Accessibility features would need to be added to canvases before that reality's possible, so we've got a ways to go yet before we need to worry too much about that.
joelanman
traditionally, lack of accessibility has unfortunately not held back people's use of tech, see Flash and most SPAs
jdiff
The people who would do this canvas trickery are the people that would be held back by the lack of accessibility.
guhcampos
Is it bad though? This is of course a rethoric question, I don't know myself if I think it's good or bad, yet.

What I'm thinking is: there's been soo much discussion around "we have corrupted the Web", "Web standards were never made to build apps on", etc. with sometimes good and sometimes really bad arguments.

If we can build viewports in canvas that behave more like just a desktop environment where apps can be built, maybe that could be good? It could mean a split between the informational web and the "apps on the browser" paradigm, and in a ideal scenario this could make things simpler and more organized for everyone? Or it could just mean more work, more standards, more rupture and more siloing. Honestly don't know.

littlestymaar
It wouldn't be bad if we were sure it wasn't going to be abused to make apps where ads cannot be blocked, consent extortion pop-up cannot be removed, content cannot be copy-pasted, etc. unfortunately, this is the way this industry is always going, so there's good reason to be scared.

(It's also terrible for accessibility, for both disabled people or just regular users who expect to be able to navigate with the keyboard for instance, unless the framework re-implement everything itself, which I doubt)

wizzwizz4
> unless the framework re-implement everything itself

In which case, we're able to make an "inspect element" tool, which we could use to copy text out, and at the very least draw black rectangles on top of adverts. https://xkcd.com/2677/

ttepasse
A major point of the web for me back in the 90s was that everything was text. You could inspect it, you could change it, you could curl it. That’s why Java and Flash and Silverlight were so annoying, they were blackboxes inside web pages. I can’t help but see this today like those yesterday.
danielvaughn
I don't see this, or any other equivalent effort, taking off. It's neat, but CSS layout is a small part of the overall problem. Even setting side accessibility, which is a massive undertaking in and of itself, you have text rendering.

To get an idea of what you'd have to emulate, here are some (not even all) issues related to rendering text: https://faultlore.com/blah/text-hates-you/

dspillett
Even without this that is happening in small ways. I've seen a few fairly visual pages (graphs & charts, etc.) where parts that could be done with plain HTML+CSS such as separate tables containing the data (or a subset thereof) displayed in the charts was also rendered on a canvas.
abofh
Every snake eats its own tail eventually - we went from bit blasting onto a frame buffer in 320x200 to bit blasting vector graphics onto a virtual frame buffer. (I leave out earlier steps and later steps, but every implementation eventually tries to implement its framework - it seems like the natural flow of things)
[deleted]
(comment deleted)
nickpsecurity
That’s what a GUI app is, though. You could say it’s the default way we interact with graphical apps. Web browsers, along with web-enabled platforms, add a bunch of extra stuff to that.

Many of us just want good, GUI apps for many things. They were often faster and lighter. VS Code is the exception to the rule which I use regularly.

zharknado
This discussion reminds me a bit of the description of Fujitsu trying to implement Habitat in Japan:

“…instead of sending a command message to the object on the server, the client would send the X-Y coordinates of your mouse click. The server would then render its own copy of the scene into an internal buffer to figure out what object you had clicked on. Not only was this extremely inefficient, but the race conditions inherent a multi-user environment meant that it also sometimes just got the wrong answer. It was amazing…”

http://habitatchronicles.com/2004/04/you-cant-tell-people-an...

NegativeLatency
Like flash?

Seems like less of a risk than the flash days because browsers are faster and more capable, and stuff like this is currently a subset of what the browser can do, instead of a superset like flash was (or the strong vendor push like microsoft silverlight).

Not old enough to have been a dev when flash was in it's prime though so might not have the most accurate view.

lewisjoe
This is an amazing piece of work. Thanks for making this open-source.

The default way of generating beautiful PDFs in the backend these days is, running a headless browser and using browser APIs to turn HTML/CSS into PDFs. And apparently, it's a bit costly running instances of browser in the server and scale it properly for huge workloads.

This is literally a game changer. Now it's possible to design PDFs using HTML/css and generate them without the browser overhead!

bawolff
As an aside its amazing how far the web has come, where the best way to make pretty pdf documents is to literally run a web browser on the server. This would have been so unthinkable back in the 90s & 2000s
vanderZwan
I'm fairly certain that using a headless browser on the server is mainly about sandboxing all the security concerns that PDFs have, not aesthetics, but yes.
bawolff
Security of the pdf format is not relavent here. The headless browser outputs a PDF. It is not taking a user controlled pdf as input.
vanderZwan
Ah of course, my apologies. I misread the original post.
menacingly
it's actually because layout-via-code for arbitrary documents is a humblingly complex problem, so leveraging existing layout engines is preferred.

This impressive effort looks far better than what I'd achieve, but when this approach has been tried before, it is eventually discovered that few organizations have the resources to maintain a rendering engine long-term.

chearon
I do think complexity could be part of why we don't have many options here, but I don't agree that a layout engine is too difficult to maintain. More of the issue is that CSS layout (and maybe layout in general) is not widely well-understood. I've almost _never_ come across people interested in layout because generally it's a few properties to get something working and then you move on.

> few organizations have the resources to maintain a rendering engine long-term

I'm curious are there other instances of this happening than Edge switching to Blink? That event was one of my main motivators; it felt like further consolidation of obscure knowledge.

Sesse__
Opera switched from Presto to Blink, too.

Very fun project! Did you ever consider integrating with web-platform-tests? It's shared between all the common browser vendors, and we're always interested in more contributors :-)

chearon
> Opera switched from Presto to Blink, too

True. But I wonder if there are more special-purpose engines similar to Prince that have been abandoned.

> Did you ever consider integrating with web-platform-tests?

I've run some of the WPT tests manually, but I don't yet have <style> support, and some of them use <script> I think? That's a path I'm wary of (eval()?) but I could have a special mode just for tests.

I did discover lots of weird corners that would be great to make some WPT tests for. Definitely something I want to do!

Sesse__
Yes, a _lot_ of WPT tests depend on <script>. But there's also a bunch of ref-tests, where you just check that A and B match pixel for pixel (where B is typically written in the most obvious, dumb way possible). It lets you test advanced features in terms of simple ones. But yes, you'd need selector support in particular.
nicoburns
I maintain a standalone web layout engine[0] (currently implementing Flexbox and CSS Grid) which has no scripting support. WPT layout tests using <script> is a major blocker to us running WPT tests against our library. Yoga (used by React Native) is in a similar position.

Do you think the WPT would accept pull requests replacing such tests with equivalent tests that don't use <script> (perhaps using a build script to generate multiple tests instead - or simply writing out the tests longhand)?

I could run against only the ref-tests, but if I can't get full coverage then the WPT seems to provide little value over our own test suite.

[0]: https://github.com/DioxusLabs/taffy

Sesse__
I don't decide WPT policies (and I honestly don't know who does), but I'm pretty sure using a build script would be right out, as WPT is deeply embedded in a lot of other projects. E.g., if you made a build script, you would need to add support for running that script in Blink and in Gecko and in WebKit, and their multiple different runners, and probably also various CI systems.

As for the second option, I don't actually know. If it becomes 10x as long, I would assume you get a no for maintainability and readability reasons. If it's 20% longer and becomes no less clear, I'd say give it a try with a couple tests first? It's possible that the WPT would be interested in expanding its scope to a wider web platform than just browsers. You would probably never get people to stop writing JS-dependent tests, though, so you would need to effectively maintain this yourself.

Of course, for a bunch of tests you really can't do without <script>, given that a lot of functionality is either _about_ scripting support (e.g. CSSOM), intimately tied to it (e.g. invalidation) or will be tested only rather indirectly by other forms of tests (e.g. computed values, as opposed to used values or specified values or actual values or …).

gsnedders
To reply mostly with my WPT Core Team hat off, mostly summarising the history of how we've ended up here:

A build script used by significant swaths of the test suite is almost certainly out; it turns out people like being able to edit the tests they're actually running. (We _do_ have some build scripts — but they're mostly just mechanically generating lots of similar tests.

A lot of the goal of WPT (and the HTML Test Suite, which it effectively grew out of) has been to have a test suite that browsers are actually running in CI: historically, most standards test suites haven't been particularly amenable to automation (often a lot of, or exclusively, manual tests, little concern for flakiness, etc.), and with a lot of policy choices that effectively made browser vendors choose to write tests for themselves and not add new tests to the shared test suite: if you make it notably harder to write tests for the shared test suite, most engineers at a given vendor are simply going to not bother.

As such, there's a lot of hesitancy towards anything that regresses the developer experience for browser engineers (and realistically, browser engineers, by virtue of sheer number, are the ones who are writing the most tests for web technologies).

That said, there are probably ways we could make things better: a decent number of tests for things like Grid use check-layout-th.js (e.g., https://github.com/web-platform-tests/wpt/blob/f763dd7d7b7ed...).

One could definitely imagine a world in which these are a test type of their own, and the test logic (in check-layout-th.js) can be rewritten in a custom test harness to do the same comparisons in an implementation without any JS support.

The other challenge for things like Taffy only targeting flexbox and grid is we're unlikely to add any easy way to distinguish tests which are testing interactions with other layout features (`position: absolute` comes to mind!).

My suggestion would probably be to start with an issue at https://github.com/web-platform-tests/rfcs/issues, describing the rough constraints, and potentially with one or two possible solutions.

rajh
I needed to transform a 12MB HTML file into a PDF document and headless Chrome quickly ran out of memory (4GB+).

We are now using a commercial alternative that seems be be using a custom engine that implements the HTML and CSS specs. The result is reduced memory usage (below 512MB during my tests) and the resulting PDF is much smaller, 3.3MB vs 42MB.

phonon
Did you try Weasyprint?
rajh
Yes, I’ve tried all the open source projects I could find. Including Weasyprint and wkhtmltopdf. Weasyprint was much slower than headless Chrome and also required a lot of memory to process the HTML. And wkhtmltopdf is no longer maintained and crashed while processing.
nojvek
We use docraptor based on princexml engine but haven’t tried a huge pdf. We generate 20-30 page pdfs sometime and it works great.
rajh
We are also using DocRaptor. It takes around 20 seconds to generate the PDF, and we only need to generate it every night. So the costs are also not an issue at the moment.
ManBeardPc
Have you tried Typst? It's like a modern version of LaTeX and allows to generate nice looking documents quickly. Can be called from the console and makes it easy to create templates and import resources like images, fonts and data (csv, json, toml, yaml, raw files, ...). Of course it is its own language instead of HTML/CSS but so far I found it quite pleasant to use.
sciolistse
Back around 2002 at least there were some products, ABCpdf is one I used a lot, which ran Internet Explorer on the server to generate PDFs from HTML. Worked pretty well from what I recall.
Pelerin
I'm a little confused by your comment. I've been using the Prawn library to generate PDFs on the backend for a side project I am working on for quite sometime https://github.com/prawnpdf/prawn

(Admittedly, the PDFs I generate are most certainly not beautiful, so maybe that's the difference)

Lukas_Skywalker
Prawn really is great. I use it to generate invoices and for exporting a billing overview in client projects. And it’s quite fast as well, since it generates the PDF directly without the need to spin up a browser.
lukew3
Lots of people are already really comfortable with html/css, so having the option to avoid learning an entirely new paradigm is helpful.
ricardobeat
> One thing Prawn is not, and will never be, is an HTML to PDF generator
thekingshorses
One of the benefits of using the browser is that the generated PDF will be using vectors/fonts etc whereas Canvas will be mostly an image in the PDF. Not a big deal for the most use cases.
aidos
I feel like it’s probably not a leap to go from this to having a PDF renderer as a backend. The trickiness is in the layout, which this is already doing. Looks to be a lower level api and a way to render to absolutely positioned html. That gets you most of the way there.
dusanh
We did use this approach years back when I worked for on a feature that generated PDF invoices.

But I wondered whether using instead something like LaTeX wouldn't be faster and easier to scale.

Sateeshm
I don't think rasterized output makes a good pdf.
xtrimsky1234
I've been building PDF renderers for a few clients. The biggest request in PDFs has been accessibility. Everyone needs to be ADA compliant. I sadly don't see myself switching to a canvas renderer because then there is no accessibility.
pietroppeter
I would be very much interested in articles on how to write a CSS layout engine from scratch
nicoburns
I've been considering writing such a thing. Although I've only implemented Flexbox and CSS Grid so far. The CSS specifications for those algorithms are worth reading if you're interested in this kind of thing. They're a challenging read, but not an impossible one.
joelanman
this wouldn't be accessible would it? For example to screen readers, so just wondering what the use case is over accessible tech
eob
This is incredible --- @chearon thank you for open sourcing this!

I think most folks probably don't realize how difficult it is to go from HTML -> PNG programmatically. You get hit with a thousand papercuts related to either Node<>Browser differences or HTML<>Canvas differences.

shepherdjerred
I've used satori [0] on the backend with TypeScript/Deno to render React JSX + tailwind CSS as an SVG (which is then rendered to a PNG). Of course you could use another flavor of JSX (or even plain HTML) or omit tailwind, but it's really cool that you can use the same stack as a typical frontend and render it as an image.

Satori is meant for rendering Open Graph images (e.g. the little images that come up when you post a link on Twitter/Slack/Facebook), but I found that it works well for rendering arbitrary images. Satori has no native dependencies, so it kinda "just works" on the backend. It supports a subset of modern CSS, including flexbox.

My use case is posting match reports for League of Legends into a Discord text channel, e.g. person X just played a match, here are their stats.

It's quite nice because there are almost zero server-side native dependencies (the one exception is the library to convert svg -> png requires some native libraries).

Here's what a match report looks like: [1]

Here's an example of what the JSX looks like: [2]

I also built a small project [3] that renders the JSX in a browser to make developing the images just as easy as developing a normal website.

If others are interested in this, I would by happy to write a blog post about the process.

[0]: https://github.com/vercel/satori

[1]: https://github.com/shepherdjerred/glitter/blob/main/assets/p...

[2]: https://github.com/shepherdjerred/glitter/blob/main/packages...

[3]: https://github.com/shepherdjerred/glitter/tree/main/packages...

[deleted]
(comment deleted)
LinguaBrowse
Thanks for sharing this. I’ll be checking its potential as a base element for something like NativeScript or Node.js.

Text is about the most complex UI element that a UI framework offers, and if you’ve got Flow Layout working, that’s very encouraging! Will be interested how far along things like gestures (particularly text highlighting) and IME integration are. In any case, kudos for opensourcing this!

mwit2023
will give it a try for opengraph images, thank you!
Vt71fcAqt7
This looks great. As you mention PDF, do you plan to support the various @page properties that add pagination? For example like pagedjs[0] but native? Major usecases are books and invoices

[0] https://pagedjs.org/about/

chearon
Yes, this is pretty high up on my list. I've already done a little bit of work on pagination/fragmentation, but it will take me some time.
wg0
This is pure craftsmanship. A heavy undertaking TBH, kind of reinventing browser flow on top of browser primitives.
rrgok
Perhaps I'm missing something, but why can't we render HTML directly onto the canvas in the browser? The parser is there, the layout engine is already implemented, and the calculation of box layout is already done. It should be doable without going in circles. If only the browser had a flag indicating which "surface" to render on.

I was looking at Glide Grid the other day, and it renders so fast, even with 1 million rows; it's somehow responsive. There should be an easier way to render HTML to canvas without resorting to low-level primitives. Why is canvas faster than the "regular" DOM renderer?

eeiaeaa
Glide grid renders to canvas also.
rrgok
Perhaps I worded it wrong: I meant to bring Glide Grid as an example how fast we can render millions of items to canvas.
spankalee
It doesn't actually render millions of items though. It renders the visible viewport, something you can also do with pretty standard DOM virtualization techniques.
duckfruit
But if all you want to do is render HTML then why use <canvas>?

I'm only speculating, but it doesn't seem surprising that regular DOM rendering logic - which has to handle approximately a bazillion different rules and special cases - is slower than a custom renderer written for a specific subset of HTML.

hwillis
If you want to do any kind of text or diegetic UI in webgl, you are begging for DOM rendering to canvas (which is then sent to a texture)
robbiejs
Glide Grid is an amazing achievement I have to say!

You can have a fast DOM without canvas, but it requires creative thinking. DataGridXL also renders millions of cells, but it does not use canvas as its main renderer (https://www.datagridxl.com/demos/one-million-cells).

The way it works: only columns are their own DOM nodes. For browsers it's just too much to ask to re-render let's say (20rows*10cols) 200 DOM nodes while keeping scrolling at 60fps.

spankalee
> it's just too much to ask to re-render let's say (20rows*10cols) 200 DOM

I don't think this is true with modern browsers and CSS. For a table, every cell and parents of the cells as much as possible, should be styled `contain: strict` and if possible, absolutely positioned.

robbiejs
It's still true. You might be able to get decent performance on a Macbook 3000 (doubtful even) but anything less than that, nope. That's why many grid components use canvas rendering. It would have been a lot easier for all these grid devs to work with DOM nodes if they could.
spankalee
> That's why many grid components use canvas rendering

Many grid components were developed many years before modern compositors and the `contain` property.

exceptione
Out of curiosity: What browsers did you test? Firefox performs magnitudes better in css benchmarks than Chrome, and I thought it is also better in handling large DOMs in general.
robbiejs
DataGridXL is used by 10 million end users. It's tested on all kinds of devices and browser combinations.

Browsers can handle AND update really large DOMs, but they still choke on doing all of these actions (repaint, reflow) WHILE SCROLLING, which is a different game.

[deleted]
(comment deleted)
dtf
As far as I remember, it's down to security concerns.

You can actually insert your HTML into a SVG foreignObject, and then drawImage() that onto your canvas. But your HTML-in-SVG document will need to load all its own resources, fonts, CSS etc.. which makes this process rather tedious.

lloydatkinson
It doesn’t support flex box? I really can’t tell what the purpose of this library is then.
recursive
The purpose is for documents that don't use flexbox.
lloydatkinson
Alright so that’s about as useful as saying “I built a word processor without left, right, middle align or tables”.
recursive
Maybe? I mean those exist. Not sure what you're getting at. If you don't like it don't use it.