Platform DX @Shopify. Created @preactjs. Do more with less. https://nitter.cf/t.co/z1d6J24DlE @developit@mastodon.social
Hamilton, Ontario, Canada
Joined September 2008
- Tweets43.7K
- Following2.3K
- Followers63.7K
- Likes64.3K
Introducing Preact Signals: a reactive state primitive that is fast by default.
β
feels like using plain values
π₯³ automatic updates when values change
β± updates DOM directly (fast!)
π₯Ή no dependencies arrays
preactjs.com/blog/introducinβ¦
Jason Miller π¦β retweeted
Git at Scale (by cursor) has been one of the most interesting blog posts i've read in a while. It came right when I was frustrated with Shopify's internal git system.
As an exercise, I've implemented it over the weekend as open source. It's a single rust binary that you can point at any S3 type object store. It uses WAL and CAS primitives and requires no other data store.
It also implements bundle-uri so large git repos (like our mono) are very fast to download as a chain of static bundles. Also comes with basic familiar UX.
github.com/tobi/walgit
Replying to @_developit @TheLarkInn
the "sideEffects" config means packages can have their exported interface be a barrel without no performance hit (Vite dissolves re-exports, TS types are generated+cached so no source fan-out). And the packages made it so file moves usually don't change importer specifiers.
Replying to @TheLarkInn
late reply but: no, not really. the DX win from the performance improvement massively outweighed any familiarity loss.
One thing we did to help was convert a bunch of "pseudo-package dirs" to real pnpm workspace packages with `"sideEffects"` configured.
Replying to @_developit @TheLarkInn
And then the bonus was that doing it as a bundler plugin meant it had to be fast, which forced decisions like doing it all via a Rust lexer (no ast), and those all got reused to build the codemod tool that we then used to stamp the barrels out of the source after.
Replying to @_developit @TheLarkInn
This got us to the end goal fast, but the main value was that it uncovered all of the incredibly nuanced bugs we had when barrel files were removed - module trees shifting between bundles, their exec timing changing, etc.
Replying to @TheLarkInn
Lol it'll be a riot. We did this for 5.5M loc. Tooling was the only solution.
Thing that worked best: I built a "debarrel plugin" for our vite setup that dissolved barrel files so that before any code changes were applied we were already running the "no barrels" output.
Soon you will be able to roll Preact in vite without Babel github.com/preactjs/prefreshβ¦
What if a signal on the server could just be a signal on the client?
Wrote about @_developit's mixed-signals - it reflects server-side Preact Signals to clients over any transport. Write your state once as a model, decide where it runs.
No fetch glue. No cache invalidation. Just signals.
jovidecroock.com/blog/mixed-β¦
Replying to @wesbos
lol yeah. though... I'd lay partial blame at the feet of CSS for that specific one haha
Replying to @jbscript
or the copyright that tells you what year the LLM training data was collected rather than the date the page was last updated
Replying to @cultheroro @wesbos
probably comes from the same vendor on the same boat anyway
Replying to @rossmorsali
lol maybe that's the shift - I'm using more frontends from the folks building LLM stuff, and that stuff is all rushed
Replying to @ryanflorence
its been going downhill for sure, but really feels like it's accelerated
Has anyone else noticed mobile frontends (native and web) are getting increasingly terrible (as we descend into UX vibe coding?)?
I keep noticing I've developed ridiculous coping strategies like constantly copying input to clipboard in case it gets lost when sending.
Replying to @fnthawar
If you haven't seen it, the Baroness Von Sketch Show is fucking hilarious (I assume this is a clip from it)
gem.cbc.ca/baroness-von-sketβ¦
Replying to @georgeranch
both. I routinely set up and steer serious/large PR work on my phone while I wander around the house trying to feel unchained from the desk