Live data from Hacker News

Show HN: Dropflow, a CSS layout engine for node or

github.com

91–100 of 146 posts

Re: Show HN: Dropflow, a CSS layout engine for node or <canvas>

#91
post #74

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/…

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)

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.

Re: Show HN: Dropflow, a CSS layout engine for node or <canvas>

#92
post #74

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/…

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)

Lots of people are already really comfortable with html/css, so having the option to avoid learning an entirely new paradigm is helpful.

Re: Show HN: Dropflow, a CSS layout engine for node or <canvas>

#93

Earlier quoted context omitted.

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 node…

> 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.

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.

Re: Show HN: Dropflow, a CSS layout engine for node or <canvas>

#94

I would be very much interested in articles on how to write a CSS layout engine from scratch

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.

Re: Show HN: Dropflow, a CSS layout engine for node or <canvas>

#95
post #6

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(...);

The security implications would be interesting, unless you tainted the canvas (which makes it instantly less useful).

Re: Show HN: Dropflow, a CSS layout engine for node or <canvas>

#96
post #76

Earlier quoted context omitted.

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.

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 r…

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 :-)

Re: Show HN: Dropflow, a CSS layout engine for node or <canvas>

#97
post #74

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/…

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)

> One thing Prawn is not, and will never be, is an HTML to PDF generator

Re: Show HN: Dropflow, a CSS layout engine for node or <canvas>

#98

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.

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.

Re: Show HN: Dropflow, a CSS layout engine for node or <canvas>

#99
post #96
post #76

Earlier quoted context omitted.

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 r…

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 :-)

> 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 support, and some of them use 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!

Re: Show HN: Dropflow, a CSS layout engine for node or <canvas>

#100
post #99
post #96

Earlier quoted context omitted.

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 :-)

> 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 support, and some of them use 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 wei…

Yes, a _lot_ of WPT tests depend on . 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.
Post reply on HN