Live data from Hacker News

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

github.com

31–40 of 146 posts

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

#31
post #10
post #5

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.

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

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

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

#33

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.

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.

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

#34
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 NodeBrowser differences or HTMLCanvas differences.

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

#35

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?

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.

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

#36

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.

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)

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

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

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

#38

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.

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…

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.

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

#39
post #10

Earlier quoted context omitted.

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

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

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!

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

#40
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!

Post reply on HN