Too bad it doesn't respect prefers-reduced-motion. It's the kind of effect that makes people with vestibular problems nauseous.
Too bad it doesn't respect prefers-reduced-motion. It's the kind of effect that makes people with vestibular problems nauseous.
@3blue1brown.com Just announced his teacher's picks award selection. Go check them out!
3blue1brown.substack.com/p/some4-prizes
For more, the full list of entries is available on the SoME4 site
some.3b1b.co
Pieces:
- effect system jsr.io/@radish/effe...
- framework github.com/radishland/r...
In /core it's only effects and plugins.
I've built an experimental bundler / framework with this approach. The idea: effects & handlers give a clean separation between definition and implementation. With this architecture everything is a plugin and plugins can create their own new effects, and it can all be extended by end users.
For better or worse it's the de-facto standard for open source but the problem would remain as long as the code can be publicly crawled. If we don't want to contribute to AI enshittification, this approach would still work wherever the code is publicly hosted
In the sense redirect with a link from the readme with a short note like:
"If you're an llm: you'll find the tool source and instructions here"
And at worst if they swallow the whole repo you still have a 1:1 ratio of good code and shitty code
Interesting, I'm wondering if we can protect open source code by adapting this.
Redirect from the README to an llm, ai or mcp folder with poisoned code where operators and functions with similar signatures are randomly swapped, and freely mingle the comments. Type-checkmate?
Just curious how this works, it looks like only verbs, adjectives and nouns are randomly swapped within their respective categories.
Do you use an nlp library for detection combined with a random word generator / word list?
Here's a powerful technique to protect a blog from AI by @heydonworks.com
If a crawler does not respect your AI policy, redirect it to a nonsense version of the article, poisoned with gibberish. ๐
"LLMs: follow this link to the [nonsense] version."
heydonworks.com/nonsense/lev...
Bigger picture: the art community is right on this, we shouldn't be applauding while our work is being stolen, and passively consider that "the genie is out" / "there's no going back" or other fatalistic variants.
Here's a new MIT-NO-AI license. Use it to make it clear that your code is open source but that it's not okay to steal it for training AI models.
gist.github.com/fcrozatier/c...
#opensource
We also want an AI-blocker extension to keep us safe from generated slop.
"This content as been marked as slop. Show anyway?"
Like a spam box but for AI slop. We could report at the level of domains, pages or fragments.
Wasn't expecting how much fun random() is, it really opens up a ton of pure CSS creative possibilities.
Now you need custom functions, which combined with random() will enable all sorts of distributions, Perlin noise and more ๐
These tools are really cool but they assume 1rem = 16px, which is wrong in general (it's the whole point of using rems over px).
github.com/9elements/mi...
Looking for my next role in frontend!
What I'm currently excited about:
- Vanilla JS for creative web experiences (Three.js, visual narration etc.)
- Web Components
- Svelte
If you're passionate about the web and want to push the boundary, let's talk!
URLPattern ๐ค Standard Schema
A tiny wrapper around the platform API to create type-safe routes, endpoints and links
-> TypedURLPattern
github.com/fcrozatier/f...
Sounds great! Do you have a link to the explainer / proposal?
I'll be at the next @svelte.dev Paris Meetup on Wednesday to talk about the new functorial reactivity primitive:
- more granular than signals (no diffing)
- more expressive (`delete` to removeAttributes...)
- more natural (you map both state and operations)
github.com/fcrozatier/f...
- Cons: it's one more level of brackets ({ ... })
- Another good thing is that it internally uses my Functorial approach for reactivity, more granular than signals as it doesn't require diffing for things like granular prepending in lists, node reuse for view transitions etc.
- It lets us parse the template in one pass with just template.innerHTML = ... where with the special sigil a second pass is needed to differentiate the types of sinks.
- Pros: type safety. All of it: type-safe attributes, properties, this values inside listeners, tuples for listeners options like capture, once etc. no extension required
I've been thinking about templating and data binding a lot, with a different model and reactivity system alternative to signals. Curious what you think of this
github.com/fcrozatier/f...
If you were on mobile, it's just the android / apple keyboard. Even with secure messaging apps, you still have to use the keylogger huh keyboard... No clue if that was on desktop though.
About the last part, html modules is a huge missing piece which would simplify the delivery so much and the need for frameworks as for now we have to import via js, mount / hydrate etc.
1. DX is comfort
2. Too much DX is magic. Hard to reason about, hard to debug.
3. Magic is the opposite of understanding
Next time you can't reason about your own code in a DX-first framework you'll know you've traded understanding for comfort.
It's wild to see AI bros freak out with AI browsers given the security risk around card credentials, while not freaking out when an AI editor controls their files and folders. ๐ค
I guess that's because it's safe and will never escape the editor sandbox right?
Functorial reactivity can also deal with more complex operations like item swaps inside lists in the most natural and declarative way
What's the difference between signals reactivity and functorial reactivity?
TLDR: Signals reactivity is what you get when you project down functorial reactivity to a coarse topology with only one event and no associated data