Tagged “javascript”
Adapting Stimulus usage for better Progressive Enhancement
A while back, Jake Archibald tweeted:
Don't render buttons on the server that require JS to work.
Astro
Astro looks very interesting. It’s in part a static site builder (a bit like Eleventy) but it also comes with a modern (revolutionary?) developer experience which lets you author components as web components or in a JS framework of your choice but then renders those to static HTML for optimal performance. Oh, and as far as I can tell theres no build pipeline!
Astro lets you use any framework you want (or none at all). And if most sites only have islands of interactivity, shouldn’t our tools optimize for that?
clipboard.js - Copy to clipboard without Flash
Here’s a handy JS package for “copy to clipboard” functionality that’s lightweight and installable from npm.
Inspire.js
Lean, hackable, extensible slide deck framework
I’ve been on the lookout for a lightweight, web standards based slide deck solution for a while and this one from Lea Verou could well be perfect.
Dragula - Browser drag-and-drop so simple it hurts
Here’s a nice, lightweight and framework-free drag and drop UI solution, that’s sure to come in handy.
Drag and drop so simple it hurts
Container Queries in Web Components | Max Böck
Max’s demo is really clever and features lots of interesting web component related techniques.
I came up with this demo of a book store. Each of the books is draggable and can be moved to one of three sections, with varying available space. Depending on where it is placed, different styles will be applied to the book.
Observer APIs in a nutshell
I’ve played with the various HTML5 Observer APIs (IntersectionObserver, ResizeObserver and MutationObserver) a little over the last few years—for example using ResizeObserver in a container query solution for responsive grids. But in all honesty their roles, abilities and differences haven’t yet fully stuck in my brain. So I’ve put together a brief explainer for future reference.
Encapsulated Eleventy/Nunjucks components with macros (by Trys Mudford)
Trys shows us how to use the Nunjucks macro to create encapsulated components. This works out less leaky and more predictable than an include preceded by variables assigned with set.
Front-of-the-front-end and back-of-the-front-end web development (by Brad Frost)
The Great Divide between so-called front-end developers is real! Here, Brad Frost proposes some modern role definitions.
A front-of-the-front-end developer is a web developer who specializes in writing HTML, CSS, and presentational JavaScript code.
A back-of-the-front-end developer is a web developer who specializes in writing JavaScript code necessary to make a web application function properly.
Vanilla JS List
Here’s Chris Ferdinandi’s curated list of organisations which use vanilla JS to build websites and web apps.
You don’t need a heavyweight JavaScript framework, and vanilla JS does scale.
Accessible interactions (on Adactio)
Jeremy Keith takes us through his thought process regarding the choice of link or button when planning accessible interactive disclosure elements.
Progressively enhanced JavaScript In Real Life
Over the last couple of days I’ve witnessed a good example of progressive enhancement “In Real Life”. And I think it’s good to log and share these validations of web development best practices when they happen so that their benefits can be seen as real rather than theoretical.
Newsletters, by Robin Rendle
A fantastic so-called “Scroll Story” from Robin Rendle. In his own words it’s “an elaborate blog post where I rant about a thing” however given the beautiful typography, layout and illustrations on show I think he’s selling it a little short!
Browser Support Heuristics
In web development it’s useful when we can say “if the browser supports X, then we know it also supports Y”.
Creating websites with prefers-reduced-data (on polypane.app)
Even though more and more people get access to the internet every day, not all of them have fast gigabit connections or unlimited data. Using the media query prefers-reduced-data we can keep our sites accessible to everyone.
Minimalist Container Queries
Scott Jehl’s experimental take on a container/element query aimed at letting us set responsive styles for our elements based on their immediate context rather than that of the viewport.
I made a quick and minimal take on approximating Container/Element Queries using a web component and basic CSS selectors.
Sets in JavaScript
I don’t often store things in a Set in JavaScript, but maybe I should. The fact it will only store unique values makes it pretty handy.
Cheating Entropy with Native Web Technologies (on Jim Nielsen’s Weblog)
This is why, over years of building for the web, I have learned that I can significantly cut down on the entropy my future self will have to face by authoring web projects in vanilla HTML, CSS, and JS. I like to ask myself questions like:
- Could this be done with native ES modules instead of using a bundler?
- Could I do this with DOM scripting instead of using a JS framework?
- Could I author this in CSS instead of choosing a preprocessor?
Introducing Rome
We’re excited to announce the first beta release and general availability of the Rome linter for JavaScript and TypeScript. This is the beginning of an entire suite of tools. Rome is not only a linter, but also a compiler, bundler, test runner, and more, for JavaScript, TypeScript, HTML, JSON, Markdown, and CSS. We aim to unify the entire frontend development toolchain.
Thoughts on inline JavaScript event handlers in the <head>
I’ve been thinking about Scott Jehl’s “simplest way to load external CSS asynchronously” technique. I’m interested in its use of an inline (onload) event handler for running JavaScript-based enhancements in the <head>, in the context of some broader ruminations on how best to progressively enhance UI elements with JavaScript (for example adding toggle show/hide) without causing layout jank.
Three CSS Alternatives to JavaScript Navigation (on CSS-Tricks)
In general this is a decent article on non-JavaScript-based mobile navigation options, but what I found most interesting is the idea of having a separate page for your navigation menu (at the URL /menu, for example).
Who said navigation has to be in the header of every page? If your front end is extremely lightweight or if you have a long list of menu items to display in your navigation, the most practical method might be to create a separate page to list them all.
The Simplest Way to Load CSS Asynchronously (Filament Group)
Scott Jehl of Filament Group demonstrates a one-liner technique for loading external CSS files without them delaying page rendering.
Color Theme Switcher (on mxb.dev)
Max shows us how to build a colour theme switcher to let users customise your website. He uses a combination of Eleventy, JSON, Nunjucks with macros, a data attribute on the html element, CSS custom properties and a JavaScript based switcher.
Debouncing vs. throttling with vanilla JS (on Go Make Things)
Chris explains how debouncing and throttling are two related but different techniques for improving performance and user experience when working with frequently invoked JavaScript event handlers.
With throttling, you run a function immediately, then wait a specified amount of time before running it again. Any additional attempts to run it before that time period is over are ignored.
With debouncing, after the relevant event fires a specified time period must pass uninterrupted in order for your function to run. When the time period has passed uninterrupted, that last attempt to run the function is the one that runs, with any previous attempts ignored.
Striking a Balance Between Native and Custom Select Elements (on CSS-Tricks)
We’re not going to try to replicate everything that the browser does by default with a native select element. We’re going to literally use a select element when any assistive tech is used. But when a mouse is being used, we’ll show the styled version and make it function as a select element.
JavaScript Arrow Functions
JavaScript arrow functions are one of those bits of syntax about which I occasionally have a brain freeze. Here’s a quick refresher for those moments.
We’ve ruined the Web. Here’s how we fix it. (This is HCD podcast)
During the COVID situation, people have an urgent need to access critical information online. But in 2020, the average webpage is rammed full of large JavaScript files, huge images etc, and as a result is slow to load. This problem is likely to be most keenly felt by those who don’t have the luxury of fast internet – potentially the same people who need access to that critical information the most.
Here’s a brilliant discussion between Gerry McGovern and Jeremy Keith on that problem, suggesting tactics to help fix things such as performance budgets, introducing tactics at the design stage to mimic slow connections and other access constraints, optimising for return visits, progressive enhancement and more.
I have to reluctanctly agree on this one. I’ve interviewed quite a few candidates for “front-end developer” (or similarly named) positions over recent years and the recurring pattern is that they are strong on JavaScript (though not necessarily the right time to use it) and weak on HTML, CSS and the “bigger picture”.
🧵 It's time for our industry to realize the title "frontend developer" is obsolete. The vast majority of these profiles are actually "JS engineers", and they're usually quite good at it, but they're not as good at all the other things contributing to great frontend experiences.
— Benjamin De Cock (@bdc) April 13, 2020
Multiplayer Crosswords (chriszetter.com)
I wanted there to be an easy way to complete crosswords together that didn’t need people to pass a phone back and forth or for a copy of the crossword to be made in a shared Google Spreadsheet.
How to get started with web development (Go Make Things)
Here’s Chris Ferdinandi with a list of resources to help those who are new to web development get started. I’m keeping this one handy so I can share it with any friends who’re thinking of getting into this game.
In the same vein as Jeremy Keith’s recent blog post, Hydration, which calls out some of the performance and user experience problems associated with current Server Side Rendering approaches, I think Jake Archibald is absolutely bang on the money here.
The server and client render should not be 1:1.
— Jake Archibald (@jaffathecake) February 20, 2020
Don't render buttons on the server that require JS to work.
Don't ship code to the client that simply repeats what the server has already done.
BBC GEL Inclusive Components Technical Guide
The BBC Global Experience Language (GEL) Technical Guides are a series of framework-agnostic, code-centric recommendations and examples for building GEL design patterns in websites. They illustrate how to create websites that comply with all BBC guidelines and industry best practice, giving special emphasis to accessibility.
You Don't Need
A nice list of tips and tools on how to use simpler browser standards and APIs to avoid the added weight of unnecessary JavaScript and libraries.
Hydration (Adactio: Journal)
The situation we have now is the worst of both worlds: server-side rendering followed by a tsunami of hydration. It has a whiff of progressive enhancement to it (because there’s a cosmetic separation of concerns) but it has none of the user benefits.
Testing Stimulus Controllers
Stimulus JS is great but doesn’t provide any documentation for testing controllers, so here’s some of my own that I’ve picked up.
Required 3rd-party libraries #
Basic Test #
// hello_controller.test.js
import { Application as StimulusApp } from "stimulus";
import HelloController from "path/to/js/hello_controller";
describe("HelloController", () => {
beforeEach(() => {
// Insert the HTML and register the controller
document.body.innerHTML = `
<div data-controller="hello">
<input data-target="hello.name" type="text">
<button data-action="click->hello#greet">
Greet
</button>
<span data-target="hello.output">
</span>
</div>
`;
StimulusApp.start().register('hello', HelloController);
})
it("inserts a greeting using the name given", () => {
const helloOutput = document.querySelector("[data-target='hello.output']");
const nameInput = document.querySelector("[data-target='hello.name']");
const greetButton = document.querySelector("button");
// Change the input value and click the greet button
nameInput.value = "Laurence";
greetButton.click();
// Check we have the correct greeting
expect(helloOutput).toHaveTextContent("Hello, Laurence!");
})
})A new technique for making responsive, JavaScript-free charts (DEV Community)
I wanted to see if it was possible to create SVG charts that would work without JS. Well, it is. I've also created an experimental Svelte component library called Pancake to make these techniques easier to use.
Let’s Learn Eleventy! (with Zach Leatherman) - Learn With Jason (YouTube)
When should you add the defer attribute to the script element? (on Go Make Things)
For many years I’ve placed script elements just before the closing body tag rather than in the <head>. Since a standard <script> element is render-blocking, the theory is that by putting it at the end of the document – after the main content of the page has loaded – it’s no longer blocking anything, and there’s no need to wrap it in a DOMContentLoaded event listener.
It turns out that my time-honoured default is OK, but there is a better approach.
Async and Await
My notes and reminders for handling promises with async and await In Real Life.
Modest JS Works
Pascal Laliberté has written a short, free, web-based book which advocates a modest and layered approach to using JavaScript.
I make the case for The JS Gradient, a principle whereby your app can have multiple coexisting modern JS approaches, starting from the global sprinkles to spot view-models to, yes, an SPA if that’s really necessary. At each point in the gradient, you’ll see when it’s a good idea to go a step further toward heavier JavaScript, or not.
Loading and Templating JSON Responses in Stimulus.js (by John Beatty)
Just because Stimulus.js is designed to work primarily with existing HTML doesn’t mean it can’t use JSON APIs when the need arises.
Building an accessible show/hide disclosure component with vanilla JS (Go Make Things)
A disclosure component is the formal name for the pattern where you click a button to reveal or hide content. This includes things like a “show more/show less” interaction for some descriptive text below a YouTube video, or a hamburger menu that reveals and hides when you click it.
Progressively Enhanced JavaScript with Stimulus
I’m dipping my toes into Stimulus, the JavaScript micro-framework from Basecamp. Here are my initial thoughts.
How to manage JavaScript dependencies
Managing JavaScript dependencies is about as much fun as a poke in the eye. However even if—like me—you prefer to keep things lean and dependency-free as far as possible, it’s something you’re going to need to do either in large work projects or as your personal side-project grows. In this post I tackle it head-on to reduce the problem to some simple concepts and practical techniques.
Webfont loading strategies
When it comes to webfonts, if you want to serve an accessible and high performance experience across device types it’s not as straightforward as just specifying your fonts in CSS then hoping for the best.
Promises in JavaScript
A brief explainer (for future-me and anyone else it helps) on what promises are and how to use them. Note: this is not an official definition, but rather one that works for me.
See all tags.