Despite perceived challenges like cost and time, modern tools such as Lookback and Maze offer affordable and efficient remote and unfacilitated testing options.
This post explores advanced TypeScript utilities for testing and verifying type correctness, akin to unit testing without extra setup.
To quote Chris Coyier from his recent post, Modern CSS Features You Need to Know: Given CSS’s ever-evolving capabilities, having a robust understanding allows you to build better-looking, higher-performing, and more accessible websites. And Jen Kramer’s new course Ultimate CSS Grid & Layout Techniques will level-up your layout skills and take you beyond the basics with Grid, Flexbox, […]
People from the official Discord weigh in.
Let’s look at using CSS as an efficient alternative to JavaScript for creating simple timers. We’ll use modern CSS properties like @property, @keyframes, and pseudo-elements with counter() values.
There were over 20,000 respondents in 2023. Key findings include the popularity of the datalist feature and discontent with form elements, especially styling issues. There’s mixed sentiment about web components, a desire for new HTML elements like datatables, and signs that the divide between HTML/CSS and JavaScript may be narrowing.
Server-side component rendering can improve data loading efficiency over client-rendered SPAs. Despite their benefits, such as out-of-order streaming, they have limitations, including slow server action updates and lack of support for client-side interactivity. React Query complements RSC by managing client-side data updates, addressing some of RSC’s drawbacks.
A Chrome extension that “steals” a button from every website you open. Button Stealer works automatically. Do your usual everyday online stuff and watch the collection of your stolen buttons grow. It’s fun, useless, and free!
Chrome is experimentally shipping with Gemini Nano, their smallest Large Language Model (LLM) baked right in, then offer APIs to use it.
In Chrome, these APIs are built to run inference against Gemini Nano with fine-tuning or an expert model. Designed to run locally on most modern devices, Gemini Nano is best for language-related use cases, such as summarization, rephrasing, or categorization.
It’s an API most, with methods you call and get responses. Raymond Camden had a look:
const model = await window.ai.createTextSession();
await model.prompt("Who are you?");
// I am a large language model, trained by Google.Code language: JavaScript (javascript)Using AI in this way means 1) it’s fast (no network trip) 2) it works offline 3) it’s private (maybe) 4) it’s free to use.
I admit that’s awfully compelling. I suspect this will happen and will be very highly used.
Don’t we need to think about standards here though? What if Apple ships window.ai.instantiateIntelligence() with an .ask() method? And Firefox ships navigator.llm('dolly').enqueueQuery()? I’d just like to remind everyone that when browser just ship whatever and compete on proprietary features, everybody loses.
Little boosts of front-end development news, information, and advice — right to your feed reader of choice.
RSS
I’m first hearing about the CloseWatcher API after running across Abdelrahman Awad’s blog post about it. The MDN docs are quite direct, making the purpose clear:
Some UI components have “close behavior”, meaning that the component appears, and the user can close it when they are finished with it. For example: sidebars, popups, dialogs, or notifications.
Users generally expect to be able to use a particular mechanism to close these elements, and the mechanism tends to be device-specific. For example, on a device with a keyboard it might be the Esc key, but Android might use the back button.
So rather than bind an closing action to the Esc key, use this API, which normalizes that user action across platforms.
I also like how it automatically creates a “stack” of things to close. So if there are multiple closeable things open, a close event only closes the most recently open one. I made a demo to play with this (note the Chrome-n-friends only support!).
Vercel published an article with research on how Google Bots deal with client-side JavaScript. People assume that sites that are JavaScript-rendered only are worse for SEO and worry about that. Which is entirely reasonable, as Google themselves warns you that there are limitations with client-side rendering and “some pages may encounter problems with content not showing up in the rendered HTML. Other search engines may choose to ignore JavaScript and won’t see JavaScript-generated content.”
Their testing idea makes sense. If the page is hit with a Google Bot, wait for the page to entirely finish loading (regardless of rendering method), and only then send tracking data back to store and analyze.
Their findings are mostly “this is fine” and literally every page was rendered in full, including pages with complex JS and dynamic content, although the comparisons of rendering strategies show that client-side rendering is still clearly the worst.
This was also testing directly on nextjs.org, which I imagine Google sees as a pretty highly trafficked and important site, and perhaps willing to send it’s most robust bots. Does your brand new site for Jimbob’s Bakery get the same treatment?
Here's our page on guest writing. It's a win-win-win!
Frontend Masters Donates to open source projects. $363,806 contributed to date.