Lossy compression can be good. For something like a JPG, that naturally uses compression that can be adjusted, that compression leads to lost image data. In a good way. The image may end up being much smaller, which is good for performance. Sometimes the lost image data just isn’t a big deal, you barely notice it.
You don’t often think of lossy compression outside of media assets though. You can certainly compress a text asset like CSS, but you wouldn’t want to do that with a lossy compression. It would probably break syntax! The code wouldn’t work correctly! It’s total madness!
Unless you’re just having a bit of fun — like Daniel Janus was doing there.
When I think of JavaScript-based syntax highlighters, my go-to is Prism.js. I think it’s mostly used client-side but I don’t see why you couldn’t run it server-side (and in fact you probably should).
But I digress already, I’m trying to link to Shiki, a syntax highlighter tool I hadn’t seen before. The results look really nice to me:
It’s based on TextMate grammars, using the same exact system as VS Code. And it can be run in any JS runtime. Pretty compelling to me!
I was able to Hello, World! it on CodePen very easily.
“Pull to refresh” is a wonderfully satisfying UI/UX interaction famously first invented by Tweetie. It’s the kind of interaction where you might assume you need some deeper level of control over view primitives to pull off, and that we essentially lack this control on the web. You’d be wrong though, as Adam Argyle has a really interesting solution for it.
The trick Adam uses is that the page starts scrolled down a smidge by virtue of the <main>
region having a hard scroll snapping point. With that in place, you could scroll upwards to see another element (which says “Pull to refresh”), but the page would immediately scroll snap back down if you let go. Turns out this is pretty tricky, involving using a very deliberately sized snapping point and even an animation to delay the adding of the snap point. Then Scroll Driven Animations are used to animate things as you scroll into that area, and a smidge of JavaScript, which you’d use anyway to “refresh” things, is used to fake the refreshing and put the page back in the original position
See the demo, it’s very cool.
If you were going to pick some colors, you could do worse than just stealing them from Dieter Rams designs.
Speaking of ol’ Dieter this collection of Framer components (thus work on the web through just HTML/CSS and sometimes SVG) is very impressive. Just really elegant buttons and controls that have that “beg to be touched” look.
Have you heard people saying “LoFi” lately? Kinda sounds like a subgenre of electronic music. But no, it stands for “Local First Web Development”. And even that twists my brain a little bit, because I’m like “yes obviously we all work on local development environments now, the edit-on-the-server days are all but gone”. But they don’t mean local development, they mean that the apps architecture should support storing data, possibly to be synced later, locally. This has many advantages, as Nils Riedemann writes:
“local first” is an approach to developing web applications in such a way, that they could be used offline and the client retains a copy of their data. That also effectively eliminates many loading spinners and latency issues. Kind of like optimistic updates, but on steroids with PWA, Wasm and a bunch of other new abbreviations and acronyms.
The premise is that it’s much easier to consider this behavior as the default and then expand, rather than the other way around.
There are some major apps like Figma that do this, and it’s fairly easy to point to them as examples and be like “see, good.” I don’t disagree, really. Especially the fact that it can help support the PWA offline approach, that just feels right. They have a homepage for the movement. There are some technologies that help support it. For instance, the concept of CRDTs to help sync data in a way where you can merge data rather than have one side or the other “win” is pretty transformative.