It’s pretty straightforward to animate list items into new positions, but there is a few tricks when the specific one you’ve chosen to move needs a *different* transition.
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.
You can build your own TypeScript build process, and you might want to if you need true type checking and compatibility with a wider ecosystem of tools. But lots of tools, including now Node itself, just accept TypeScript as if it were JavaScript.
Why can’t we see if a feature is polyfillable or able to be progressively enhanced in the baseline data? There are reasons.
It’s quite fun to have an element react to another element scrolling in an unexpected way!
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/awaithave 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.
