A deep dive into producing an interpolated “gradient” of colors from just two provided colors.
Zooming in browsers is an accessibility feature. I’d say that any attempt to fight against it is bad form. Don’t do it. Leave it be. I have seen compelling examples of ways to code that work with browser zoom that help make a site look nicer when high levels of zoom are applied. But they […]
CSS developers got the ultimate dream: container queries. But now that they are here, are we actually reaching for them as much as we thought we would?
Here is a list of popular courses on Frontend Masters for May 2024. Deep JavaScript fundamentals, React, and TypeScript continue to be incredibly popular. We’re proud that our community values learning the deep fundamentals—investing in core skills pays off for your entire career. As new tools and techniques evolve, it is much easier to stay […]
A very basic step-by-step guide of exactly how to do it for static files like .html, .css, and .js files.
Let’s get into the challenges and strategies of loading data in web applications, focusing on the comparison between client-rendered sites and server-rendered applications. There are some clear negative performance impacts of SPAs and server-rendered apps are *usually* better here, except when data is slow. Then what?
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.
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?
Little boosts of front-end development news, information, and advice — right to your feed reader of choice.
RSSHere's our page on guest writing. It's a win-win-win!
Frontend Masters Donates to open source projects. $363,806 contributed to date.