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

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

InfluxDB - Power Real-Time Data Analytics at Scale
Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
www.influxdata.com
featured
SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives
www.saashub.com
featured
  • yoga

    Yoga is an embeddable layout engine targeting web standards.

  • InfluxDB

    Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

    InfluxDB logo
  • taffy

    A high performance rust-powered UI layout library

    I maintain a standalone web layout engine[0] (currently implementing Flexbox and CSS Grid) which has no scripting support. WPT layout tests using is a major blocker to us running WPT tests against our library. Yoga (used by React Native) is in a similar position.<p>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)?<p>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.<p>[0]: <a href="https://github.com/DioxusLabs/taffy">https://github.com/DioxusLabs/taffy</a>

  • dropflow

    A CSS layout engine

  • sciter

    Sciter: the Embeddable HTML/CSS/JS engine for modern UI development

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

  • satori

    Enlightened library to convert HTML and CSS to SVG

    I've used satori [0] on the backend with TypeScript/Deno to render JSX as an SVG (which is then rendered to a PNG).

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

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

  • discord

    Miscellaneous apps for my friends (by shepherdjerred)

    I've used satori [0] on the backend with TypeScript/Deno to render JSX as an SVG (which is then rendered to a PNG).

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

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

  • Prawn

    Fast, Nimble PDF Writer for Ruby

    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)

  • SaaSHub

    SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives

    SaaSHub logo
  • html5spec

    The WHATWG HTML5 spec as machine-readable JSON

    Brilliant! It's super important that stuff like this exists, demystifying the magic boxes of browser rendering engines.

    It would be great if we could create a full machine readable spec for html and CSS rendering, so that renderers can be generated. Browser quirks could then be extensions to that. Like https://github.com/tawesoft/html5spec but used for real engines.

  • synth-android

    Synth is CRED's inbuilt library for using Neumorphic components in your app.

    CRED had it in their app for a while, their library is open source

    https://github.com/CRED-CLUB/synth-android

  • Scrawl-canvas

    Responsive, interactive and more accessible HTML5 canvas elements. Scrawl-canvas is a JavaScript library designed to make using the HTML5 canvas element easier, and more fun

    > 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

  • Apache FOP

    Apache XML Graphics FOP

    I've served dynamic content directly as PDF with https://xmlgraphics.apache.org/fop/

  • wpt

    Test suites for Web platform specs — including WHATWG, W3C, and others

    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.

  • rfcs

    web-platform-tests RFCs (by web-platform-tests)

    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.

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts

  • Would anyone be interested in having me create custom Tailwind CSS Components for them?

    1 project | /r/nextjs | 5 Dec 2023
  • Svelte 5 Runes vs Vue Composition API vs React

    1 project | /r/sveltejs | 5 Dec 2023
  • Add motion to your apps with a single line of code

    1 project | news.ycombinator.com | 3 Nov 2023
  • Add expand &amp; collapse transition

    1 project | /r/tailwindcss | 14 Jun 2023
  • Animating React App in Less than a Minute

    1 project | dev.to | 17 Sep 2022

Did you konow that TypeScript is
the 2nd most popular programming language
based on number of metions?