はてなブックマーク

Many developers know that you can use service workers to cache web pages (and their sub-resources) in order to serve those pages to users when they’re offline. And while this is true, it’s far from the only thing that service workers can do to improve the performance and reliability of a website. A lesser known capability of service workers is that you can programmatically generate your responses—

Two years ago I wrote about a technique—now commonly referred to as the module/nomodule pattern—that allows you to write ES2015+ JavaScript and then use bundlers and transpilers to generate two versions of your codebase, one with modern syntax (loaded via <script type="module">) and one with ES5 syntax (loaded via <script nomodule>). The technique allows you to ship significantly less code to modu

A few weeks ago I was looking at some of the performance metrics for my site. Specifically, I wanted to see how I was doing on our newest metric, first input delay (FID). My site is just a blog (and doesn’t run much JavaScript), so I expected to see pretty good results. Input delay that’s less than 100 milliseconds is typically perceived as instant by users, so the performance goal we recommend (a

Now all we have to do is ensure our container elements always have the right breakpoint classes on them, so the correct component selectors will match. Observing container resizesFor most of web development history, it’s been possible to observe changes to the window, but it’s been hard or impossible (at least in a performant way) to observe size changes to individual DOM elements. This changed wh

Most web developers I talk to these days love writing JavaScript with all the newest language features—async/await, classes, arrow functions, etc. However, despite the fact that all modern browsers can run ES2015+ code and natively support the features I just mentioned, most developers still transpile their code to ES5 and bundle it with polyfills to accommodate the small percentage of users still

All analytics tools I know of track pageviews in a way that—to put it bluntly—simply doesn’t work for a growing number of websites today and is completely incompatible with the direction the web is heading. For the most part, these tools assume (by default) that each pageview corresponds to a full page load, and that each page load runs some analytics tracking code, and sends a pageview to a back-

Google Analytics is a powerful yet quite complicated tool. And unfortunately, the truth is most people who use it don’t reap its full benefits. There’s a lot of excellent and free content out there that explains how to use Google Analytics, but most of it is rather narrowly focused on use cases that primarily apply to marketers and advertisers; very little is geared toward web developers who simpl

Earlier this year I wrote an article for Smashing Magazine about Houdini, and I called it the “most exciting development in CSS you’ve never heard of”. In the article I argue that Houdini APIs will (among other things) make it possible to polyfill CSS features in a way that simply cannot be done today. While the article was generally quite well-received, I did notice the same question popping up o

New JavaScript and HTML features are being introduced all the time that make our lives as developers easier. In many cases, these new features are so helpful we choose to use them on production websites before they’re fully implemented in all browsers. To not break the experience for users on older browsers, we of course include polyfills for any not-fully-supported features. The problem with this

If you’ve been writing JavaScript for a while, you’ve probably heard terms like callback hell or the pyramid of doom. When promises were added to JavaScript a few years ago, I remember reading a lot of blog posts claiming that these problems would be solved; unfortunately, that was a little too optimistic. With more and more web APIs becoming promise-based, we’ve proven that even promises don’t pr

A few weeks ago CSS variables—more accurately known as CSS Custom Properties—shipped in Chrome Canary behind the Experimental Web Platform Features flag.[1] When Chrome engineer Addy Osmani first tweeted about the release, he was met with a surprising amount of negativity, hostility, and skepticism. At least, it was surprising to me, given how excited I am about this feature. After a quick scan of

Okay, before I start, I want to get one thing out of the way upfront. This article is not a rant about how much I hate specificity. If you want to read an article like that, I’m sure you can find dozens elsewhere online. What I want to do is pose an actual, honest question to the web development community and hopefully get people thinking. To restate the question in a way that gets more at the hea

I recently received an email from a reader of my blog that, for whatever reason, really got me thinking. Here’s what it said: Hi Philip, is it okay to ask how you become a great front-end engineer? Any advice? I have to admit, I was surprised to even be asked this question since I’ve never really thought of myself as a “great” front-end engineer. In fact, the first few years I worked in this indus

Update: as a follow-up to this article, I’ve created the Github repo Flexbugs: a community curated list of cross-browser flexbox issues and their known workarounds. The goal is if you’re building a website using flexbox, and something isn’t working as you’d expect, you can find the solution there. Way back in September of 2013, while testing my Solved by Flexbox project, I discovered a bug in Inte

Privacy has been a complicated issue throughout JavaScript’s history. While it’s always been possible to meet even the most stringent privacy needs (the myriad of compile-to-js languages proves this), the extraneous ceremony required to really do it right is often too much of a turn-off for most developers — especially to those coming from other languages where privacy is built in. In JavaScript w

HTML Inspector is a code quality tool to help you and your team write better markup. It’s written in JavaScript and runs in the browser, so testing your HTML has never been easier. Like JSHint and CSSLint, HTML Inspector is completely customizable, so you can use what you like and ignore what you don’t. It’s also extensible and pluggable, making it possible to write your own rules that enforce you

Any non-trivial site or application on the Web today will contain a large amount of HTML, CSS, and JavaScript. As the use of the Internet evolves and our dependence on it increases, having a plan for organizing and maintaining your front-end code is an absolute must. In today’s large Web companies, an increasing number of people are touching an increasingly large percentage of the front-end code.

Last week I published an article on this blog entitled How to Unit Test Private Functions in JavaScript. The article was well received and even mentioned in a few popular newsletters (most notably JavaScript Weekly). Still, a decent amount of the feedback I received in the comments and on Twitter strongly disagreed with my approach. The most common criticism was: unit testing private functions is

Update: A lot of readers have commented or tweeted that I shouldn’t be unit testing private functions in the first place. Admittedly, this article is a little light on the why and mainly focuses on the how. To explain some of my rationale, I wrote a follow-up article: Why I Test Private Functions In JavaScript JavaScript’s closures provide an excellent way to make variables and functions private,

To many Web developers, being good at CSS means you can take a visual mock-up and replicate it perfectly in code. You don’t use tables, and you pride yourself on using as few images as possible. If you’re really good, you use the latest and greatest techniques like media queries, transitions and transforms. While all this is certainly true of good CSS developers, there’s an entirely separate side

In CSS we often code the same visual components over and over again — even within the same project. It’s embarrassing how many separate times in my career I’ve coded a two-column layout, or tabbed navigation, or a dropdown menu, or a popup (and the list goes on). To deal with this problem Nicole Sullivan created the Object Oriented CSS (OOCSS) project. She suggests that instead of defining entire

The problem with z-index is that very few people understand how it really works. It’s not complicated, but it if you’ve never taken the time to read its specification, there are almost certainly crucial aspects that you’re completely unaware of. Don’t believe me? Well, see if you can solve this problem: The ProblemIn the following HTML you have three <div> elements, and each <div> contains a singl