Chris here, filling in for Robin, our usually weekly correspondent. And speaking of Robin, you should subscribe to his blog, as it’s a great personal blog, which he’s moving to Astro and writing about that as just one worthy reason for subscribing.
I’ve been bullish on Web Monetization since I’ve heard of it. Native browser APIs that let you point to an online wallet, and users can safely, securely, and anonymously opt-in. Coil is behind a lot of the effort. Today, if you sign up and get it going, you’ll probably make, like a dollar. That’s largely because it’s not a web standard yet, so the ecosystem that will likely grow around it isn’t in place yet. Here’s hoping.
It’s not all rosy though. PPK called the experience user-hostile. Daniel Aleksandersen doesn’t like that you get zero transparency on where the money goes. Jeremey says the whole thing reaks of crypto in an unflattering way. It’s true—the only way to get money out is one of these online wallet things where crypto is kind of the point. Not that I’m some big fan of giant corporate banks, but I sure wouldn’t mind if my Web Monetization bucks funneled into my Chase Bank account where I do my business banking anyway.
Conformance is a system that ensures that developers stay on the well-lit path; it builds confidence and ensures predictable outcomes. It makes teams productive, and becomes crucial for scale — as teams grow and more features are developed simultaneously. It empowers developers to focus on building product features, freeing them from minutiae and the changing landscape in various areas such as performance, accessibility, security, etc.
Part of my like cool, good idea! Part of me is like uh oh I hope the goal here isn’t to make Google-centric tooling teaching people that they don’t need to learn performance or accessibility because automation will tell them what to do.
Like most weeks, a lot of great stuff right on CSS-Tricks! Here’s a handful of them:
- Web Features That May Not Work As You’d Expect — Farai Gandiya shares a bunch of counter-intutive web platform stuff. I was very surprised to learn that
- A Step-By-Step Process for Turning Designs Into Code — Mark Noonan takes a stab at one of my favorite kinds of articles, in part because they are so hard to write: a look at what the job of being a front-end developer really is.
- How to Get a Pixel-Perfect, Linearly Scaled UI — Georgi Nikoloff shows off a way to linearly scale a UI. That is, scale like a JPG scales, ya know? Just… shrinks. Typically not how we think of designing for different screen sizes, but I think it is a neat technique and appropriate sometimes. I ran across another technique for this where units are just all converted to viewport units, which is a bit of a mind trip. And another technique I wrote up a while back that does the same with transforms.
- Practical Use Cases for Scroll-Linked Animations in CSS with Scroll Timelines — Bramus Van Damme covers this newfangled
Imagine how much more you could get done if your project management tool didn’t make you sigh. Clubhouse is the ideal solution for task management, bug tracking, iteration planning, and reporting. Delight the scrum gods and try us out for free.
CSS Anchored Positioning is a proposal from Microsoft. I’d say one of the
After evaluating multiple options, it came down to Cypress and Puppeteer. Cypress is an end-to-end testing framework and provides an extensive list of features, covering everything from build machines to run the tests in parallel to UI snapshots of test failures. Whereas Puppeteer is a lightweight node library that could just be installed as an npm package and get started with our existing infrastructure right away.
We eventually picked Puppeteer due to it being lightweight, extensible, and allowed us to write our own helper methods to mimic the API of Capybara to reduce the learning curve for our web engineers as they migrate end-to-end tests from Capybara to Puppeteer.
I’m fascinated reading people’s integration & end-to-end testing journeys, largely because after all these years we’ve still not landed on something perfect for us at CodePen. Our journey started with Cypress and went to Puppeteer (with Jest), but even that hasn’t really locked in and we’re considering an attempted move back to Cypress. The DX of Cypress is so good, it’s hard to stay away.
Frameworks and libraries have been created to ease the burden of writing complex UI code. Learn about the most popular frameworks to deliver applications faster, better, and on budget.
I had a reporter reach out to me a few months back about browser engines. We’ve lived through Edge throwing their own proprietary browser engines in the bin now, opting for Chromium. Perhaps a win for open source. Perhaps a loss for the positive aspects of browser engine diversity. I say perhaps because it’s hard to boil these massive changes down to single sentences. I’ve tried weighing in in the past. And because we don’t know what the world would be like if different decisions were made, we’ll never know if the web is better off for it.
Back to the reporter though, they wanted a take on browser engine diversity, not only on the heels of the Microsoft changes but because of a new browser engine: Flow Browser. This isn’t a browser built on the guts of Safari, Chrome, or Firefox, which are all open source and you can totally do that, but an entirely new browser engine. Why? It looks like, from the marketing, that the target is a wide array of devices from TV boxes to video game consoles to phones and tablets. Probably lower-specced stuff where a browser designed for those situations will shine. They say they’ve even got desktop builds to play with, but in poking around, I couldn’t find anything. They do have a Raspberry Pi build though, which matches the idea that this browser needs a GPU to work and Raspbetter Pi’s have them.
The point is… can they do it? Is this really truly a new browser that can compete with the massive ongoing efforts of Safari, Chrome, and Firefox? My brain scoffs at this. How could they? You’re going to need a lot of seriously high-end engineers many years to make this happen. Say you get 50 engineers at $200k/year and you spend five years digging into this, that’s a half-billion-dollar play without any other expenses. Are there enough companies out there begging to pay for this to make that work? My numbers are probably all wrong, but I’d love to see the real math here.
Then when you’re “done” (you’ll never be done, browsers evolve), is there any chance it’s literally better than what open source provides for free? To the point that the companies willing to pay you for it are OK with that expense. I can’t imagine you can make it open source (that’s not going to help the quality of it) otherwise you’re going to have a hard time getting the money you need back out of it.
This seems like a weird game to play. Why not play the game of taking the open-source browser engines we already have and making them better?