Amelia Wattenberger asks in a wonderful blog post wondering about more human interfaces:
Can we build something richer—something that moves with us, speaks our language, and molds to our bodies?
A deep dive into producing an interpolated “gradient” of colors from just two provided colors.
We’ll get into layered content, clip-path, and the :has() selector to build a responsive slider with live videos. We can do it by hand, but a few SCSS loops will help make it more manageable.
This helps load in data just *before* a user gets to it, and it works with non-root containers and horizontal scrolling.
Hey we might as well spill out all these wishes as the CSS feature train has been rolling and we oughta get while the getting is good.
Set a variable in Pug, then create an inline script which sets that variable for using in JavaScript and use setProperty to pass it to CSS.
Accordion details, toggle switches, styleable selects, responsive video, and more!
If you’ve applied `container` to an element, know that, for the next little while, that makes a new “formatting context” in Safari, and does not in Chrome or Firefox.
Amelia Wattenberger asks in a wonderful blog post wondering about more human interfaces:
Can we build something richer—something that moves with us, speaks our language, and molds to our bodies?
Allen Pike “after about a decade away from regularly writing JavaScript” comes back to take a look. I think these points are all correct:
- React has evolved from a little experiment thought to boost performance, into a sprawling ecosystem thought to hinder performance.
- Platform features like ES Modules,
fetch
, view transitions, andasync
/await
have made the web a nicer platform to build directly for- Serverless has gone from a wild new idea to well-understood
- Cursor is especially good at working in TypeScript, which mostly eliminates boilerplate tedium
- Modern build and packaging tools like vite, pnpm, and esbuild have made the tooling around JS nicer and much faster
- All of the above has taken universal JS – sharing code between the client and the server – from barely-possible to well-supported
The goal was to see if there was an obvious (boring, trodden) framework, and the answer is… kinda?
I can imagine being asked at an interview: What’s the difference between JavaScript engines and JavaScript runtimes? Nicholas C. Zakas says:
A JavaScript engine implements ECMAScript as defined by the ECMA-262 standard. ECMA-262 defines the core functionality of JavaScript without any affordances for input or output. A JavaScript runtime is an ECMAScript host that embeds a JavaScript engine and augments it with additional functionality for input and output, along with anything else the runtime needs. Additional functionality might include the DOM in web browsers or file system access in server-side runtimes.
So a feature like a switch
statement is a core part of the standard and implemented by a JavaScript engine. But an API like querySelectorAll
is a DOM-specific thing and added on by specific JavaScript runtimes.
I enjoyed this very straightforward, well-presented, useful article on how to create a keyboard shortcut hook in React from Tania Rascia. It’s part basic implementation, part designing an API pattern that feels right, part dealing with React hook eccentricities, and part dealing with edge cases. In the end, a pretty readable 86 lines of code.
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.