shaduocn sidebar: shaduocn.vercel.app

Optimized gpu-lexer.vercel.app to be 3.8x faster: 850ms → 221ms. It's still far behind @pierrecomputer's diffs.com/highlights (incredible work!)

Also wrote down some thoughts on shud.in/thoughts/ideas…

Cheng Lou has 1,000 ways to build fluid gallery layouts.

Next version of Satori:

grid/block/inline/inline-block, fixed/sticky, float/clear, list-style, counter, word-spacing, overflow, aspect-ratio, order, visibility, outline, mix-blend-mode, isolation, paint-order, z-index, 3D transform, conic gradient, calc(), min/max/clamp()

(every frame of this video is rendered with Satori too)

((and every frame is rendered as a SVG which means this is a vector video, remember SWF?))

We migrated mercedesamgf1.com with as little intervention as possible, setting out to prove just how much faster @vercel is. ~70% faster builds and ~75% faster paints.

We derived two AI skills from the migration that we'll be sharing back. It was a mature workload with a lot of "$formerProvider-isms", and yet the net of the work was done in under a week.

If it's [built / rendered / shipped] fast, it's on Vercel.

HTML/CSS is Turing complete, so why not compile programs to plain HTML/CSS and runs with zero bytes of JavaScript?

zero-js.vercel.app

(How to center a DIV without JS)

This continues my school project from 11 years ago, just for fun: github.com/shuding/css-co…. It's like shader code on an analog computer: no persistent state, just circuits of CSS math that react live to their inputs.

Scroll-position hacks can persist state, but it's still rough.

I put some of my random notes into a blog post:

shud.in/thoughts/metap…

After one week, there are 5 more small models for specific tasks on the web:

1. gpu-time: natural language to JS date and time by @imarikchakma
2. gpu-query: natural language to structured filters by @cheatyyyy
3. neural-flexbox: model to centre a div (!) by @aaronvanston
4. gpu-cron: natural language to cron expressions by @ManuSchiller
5. tinysarf: arabic morphological analyzers by @Ahmedabdou1996

Excellent use case, excited to see more gpu-* libs!

Got a lot of attention for this (thank you!), but also there're some criticisms and questions:

1) it's a stupid idea

Maybe. Again, this is experimental and not meant to be used in production or as a replacement for anything. It is to explore new possibilities.

2) it's es wrong

Existing solutions are not always more correct just because they're "algorithmic". For example pic 1 is Highlight.js and 2 is gpu-lexer, lang is JS not something rare. There are counterexamples too.

Furthermore, language-agnostic is the real reason for exploring this approach. During training, the neural network learned patterns like "[keyword] variable = value" that are not tied to any specific programming language such as:

var ... = ...
let ... = ...
const ... = ...
using ... = ...
val ... = ...
auto ... = ...
type ... = ...
def ... = ...

And that knowledge can be shared without re-implementing a grammar rule repeatedly.

Another advantage is that this approach can potentially generalize to new programming languages or dialects without requiring extensive manual rule creation. If you go to prismjs.com/test, you can't find popular Web framework languages like Vue, Svelte, Astro, and many others. Not to mention that new languages and dialects are constantly emerging, making it impractical to maintain comprehensive grammar rules for all of them.

When that's a concern, you either use more comprehensive solutions like Shiki with a cost (carefully bundle, detect and load language definitions on demand, larger size), or use an easier approach for all kinds of source code with another cost (less accurate).

That is definitely a good reason to explore this direction.

Another thought: if you see each part (a word, symbol, number, space) of the source code as a pixel, syntax highlighting is essentially image segmentation for a 1D image. And it's a well-solved problem by models.