pretext

Wanted to have a better reading experience. Curated feeds to avoid bumping into paywalls. Used: https://github.com/chenglou/pretext and: https://github.com/lyallcooper/justif for layout and justification with 2-column pages. Simplified navigation with shortcuts (in Settings) to move through things more quickly. Mainly focused on desktop experience.

Aggregated links to paywall-free news articles because reading news was getting frustrating. Uses filter list of known paywall sites. Checks page for isAccessibleForFree. Looks for paywall vendor script signatures Fetches hourly on my Macbook using RSS, HN Algolia API, Guardian API. Dedupes with nomic on Ollama. JSON edition is here: https://freepress.today/api/edition.json Astro front-end. Use justif and pretext for better typesetting and masonry columns https://github.com/lyallcooper/justif https://github.com/chenglou/pretext About 6 hours on Claude Code in two sessions.

Re the text rendering, isn't something like pretext supposed to handle this efficiently? https://pretextjs.dev/pretext-demo/showcase-mesmerizing-anim... https://github.com/chenglou/pretext

AI is assisting you. It'll write efficient code if you guide it to write efficient code. You're not a hapless victim of ai written code. To give you a concrete examples. Recently pretext library made waves. I looked at the code and noticed that isCJK could possibly faster. So I spent 30 minutes TELLING claude to write a benchmark and implement several different, hopefully faster, versions. Some claude came up with by itself and some were based on my guidance. You can see the result here: https://github.com/chenglou/pretext/issues/2 The original isCJK, also written by AI (I assume), was fast. It wasn't obviously slow like lots of human JavaScript code I see. Claude did implement a faster version. Could I do the same thing (write multiple implementations and benchmark them) without Claude? Yes. Would I do it? Probably not. It would take sig

I extracted the /buddy generator from the claude code source code leak. I will probably update some things once the official release is completed tomorrow. But until then, you can use the site to see all the potential buddies. Uses pretext (https://github.com/chenglou/pretext) for the text layout

i wrote something similar for this purpose, but much simpler and in 2kb, without AI, about a year ago. uWrap.js: https://news.ycombinator.com/item?id=43583478. it did not reach 11k stars overnight, tho :D for ASCII text, mine finishes in 80ms, while pretext takes 2200ms. i haven't yet checked pretext for accuracy (how closely it matches the browser), but will test tonight - i expect it will do well. let's see how close pretext can get to 80ms (or better) without adopting the same tricks. https://github.com/chenglou/pretext/issues/18 there are already significant perf improvement PRs open right now, including one done using autoresearch.

I said it elsewhere but will repeat it here: This is incredibly impressive, many of this things have been missing for forever! I remember the first time I couldn't figure out how do a proper responsive accordion, it was with bootstrap 1, released in 2011 !! Today it's still not properly solved (until now?). Many of thing things belong in css no in js, but this has been the pattern with so many things in the web 1) web needs evolve into more complex needs 2) hacky js/css implementation and workarounds 3) gets implemented as css standard This is a not so hacky step 2. Really impressive, I would have thunk that if this was actually possible someone would have done it already, apparently not, at some point I really want to understand what's the real insight in the library, their https://github.com/chenglou/pretext/blob/main/RESEARCH.md is int

This thing is very impressive. The problem it solves is efficiently calculating the height of some wrapped text on a web page, without actually rendering that text to the page first (very expensive). It does that by pre-calculating the width/height of individual segments - think words - and caching those. Then it implements the full algorithm for how browsers construct text strings by line-wrapping those segments using custom code. This is absurdly hard because of the many different types of wrapping and characters (hyphenation, emoji, Chinese, etc) that need to be taken into account - plus the fact that different browsers (in particular Safari) have slight differences in their rendering algorithms. It tests the resulting library against real browsers using a wide variety of long text documents, see https://github.com/chenglou/pretext/tre

That's in there too: https://github.com/chenglou/pretext/blob/53a065b8a345fc29831...

Some details on how it works from a code comment: Problem: DOM-based text measurement (getBoundingClientRect, offsetHeight) forces synchronous layout reflow. When components independently measure text, each measurement triggers a reflow of the entire document. This creates read/write interleaving that can cost 30ms+ per frame for 500 text blocks. Solution: two-phase measurement centered around canvas measureText. prepare(text, font) — segments text via Intl.Segmenter, measures each word via canvas, caches widths, and does one cached DOM calibration read per font when emoji correction is needed. Call once when text first appears. layout(prepared, maxWidth, lineHeight) — walks cached word widths with pure arithmetic to count lines and compute height. Call on every resize. ~0.0002ms per text. https://github.com/chenglou/pretext/blob/main/src

https://x.com/_chenglou/status/2037713766205608234, https://xcancel.com/_chenglou/status/2037713766205608234 Demos: https://chenglou.me/pretext/, https://somnai-dreams.github.io/pretext-demos/ https://kevinho.com/experiments/biomap/