Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

71–80 of 146 posts

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

#71

Post by spankalee »

robbiejs wrote: post #53
rrgok wrote: post #47

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…

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.

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

#72

Post by vanderZwan »

bawolff wrote: post #49
vanderZwan wrote: post #43

Earlier quoted context omitted.

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.

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.

Ah of course, my apologies. I misread the original post.

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

#73

Post by rajh »

bawolff wrote: post #22
lewisjoe wrote: post #19

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

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

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.

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

#74

Post by Pelerin »

lewisjoe wrote: post #19

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)

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

#75

Post by thekingshorses »

lewisjoe wrote: post #19

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

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.

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

#76

Post by chearon »

menacingly wrote: post #66
vanderZwan wrote: post #43

Earlier quoted context omitted.

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.

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

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

#77

Post by moron4hire »

This sounds great.

In a past role, my job was to develop an immersive, online learning platform. We used Oculus Quest 2s to do foreign language training for DoD personnel. WebXR, Three.js, etc, because I had had enough Unity3D for one lifetime and we didn't want to submit to app store reviews. We had a fleet of our own devices, so it was fine.

One of the biggest challenges with the project was creating a workflow for didactic content. By myself. I had an employee who I supervised working for me, but most of the work was of such high technical level that it was way over their head and we couldn't afford to hire anyone else. I eventually landed on having our actual language instructors use PowerPoint to create PDFs, use a bespoke editor I created to upload the PDF into a content database and position them in the training environments, and then used PDFJS to render them to canvas elements to then texture on a 3D quad.

Something like this would have made it possible for me to avoid having people go out of band into PowerPoint to make those materials. The PowerPoint route did dramatically improve our workflow speed over a previous attempt to get people to author images in Photoshop. But if I could have built the "sign" editor into the app, it would have improved it even more by eliminating the "guess what will look good in the environment, export to PDF, upload to the database (oh, BTW, not a lot of people know how to keep files well organized), then find out how it really looks" cycle.

Oh well. We didn't have a business development team or market department that knew anything about selling products instead of services, so I guess the point is moot anyway.

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

#79

Post by wizzwizz4 »

littlestymaar wrote: post #29
guhcampos wrote: post #24

Earlier quoted context omitted.

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

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

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

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

#80

Post by tills13 »

vthommeret wrote: post #78

Does anyone have a similar solution for drawing graphs / charts in a Node environment without a browser dependency? Last time I explored this I couldn't find any good solutions.

You could use https://github.com/vercel/satori which supports Node 16+.
Post reply on HN