I have a handful of good links to articles about performance that are burning a hole in my bookmarks folder, and wanna drop them here to share.
The new WebPageTest website design
From fonts to SVG: an icon migration strategy— Erwin Hofman notes that he was using icon fonts out of sheer convenience, but that there are loads of reasons not to use them. He provides details on his new strategy for using icons, which is based on the <use> technique. Five years later, I’m still a big fan of just dunking the <svg> in the HTML where you need them. It’s just an HTML partial like any other.
Next.js Performance: Making a Fast Framework Even Faster— Ben Schwarz says that Next.js is already a pretty fast framework in that it does smart things that keep even React powered pages snappy. But performance isn’t something that can be left entirely to a framework. You have to do work. Fortunately, Next.js has some pretty handy helpers for things like dynamically (lazily) loading components, deferring scripts, optimizing images, and more.
Redirect Liquidation— Tim Vereecke covers a fascinating technique where instead of redirecting an old URL to a new URL, you let the old URL load, dynamically load the new content, then history.replaceState the old URL with the new URL. It’s faster, but just don’t do it for bots.
Performant A/B Testing with Cloudflare Workers— Philip Walton covers how A/B testing is a little trickier on static sites than server-backed sites, but you can pull it off (performantly) thanks to Cloudflare Workers which can manipulate HTML before it hits the browser, much like a Service Worker except at the edge rather than at the client. Save a cookie and you can maintain users in their proper groups.
A Unified Theory of Web Performance— Alex Russell tries to answer Tanner Hodges’ call for actually defining web performance. It’s one of those things that seems obvious (like it’s clear when certain things help and hurt web performance) but actually defining it is tricky. And not just defining it in terms of specific metrics (even that is tricky), but answer questions like: What are this discipline’s guiding principles?What does it look like to practice web performance? How do we do it?
Unveiling the new WebPageTest UI— I absolutely love seeing WebPageTest’s design evolve and improve. It’s one of those products that’s clearly a best-in-class tool for performance practitioners, yet had a prettttty gnarly design for a lot of years. This is way better. It’s like when Google Fonts finally got a redesign and the broad community let out a collective exhale of appreciation.
Caching Header Best Practices— Simon Hearne’s dissertation on Cache headers. When I first started caring about web performance, this was, like, the main thing. If you incorrectly send Cache headers, users might be re-downloading a file over and over unnecessarily when they don’t need to, which is about the worst thing possible. I’m glad to see headers keep getting attention and re-imagined as the web evolves.
I linked to Jay’s front-end predictions last year and I think they panned out pretty well. I think he’s got a bit of a knack for that wide-scope look at front-end, including tooling and architecture, as well as browser tech. Let’s review.
Jay’s front-end predictions for 2021
👍 React framework maturity is here in the fact that big players like Next and Gatsby are stable and have found pretty big markets. New players like Remix are arriving to clear success. Frameworks like Astro support React because it means picking up users who have less to learn.
👍 Early container queries are here for sure. The syntax has nestled in a little bit, there are multiple browsers playing, and a polyfill is available. We’re even seeing early days of container units.
👍 WASM adoption is more iffy to me. I don’t run in the circles that would be early adopters of it, but anecdotally, I probably heard it talked about more this year than any year past. That tells me it’s still of high interest.
👍 Monoliths, if we’re just talking site building tools that “do it all” probably never stopped being popular, especially if you consider that’s what WordPress is and has only grown in popularity and usage. Perhaps Jamstack usage is growing, too, which decouples a lot of services. But the biggest players in helping you build Jamstack architectures also help you bring all those services under one roof. Services like Netlify and Vercel are Jamstack hosts, but will also run your serverless functions. Netlify Graph is a clear stab at helping you work with APIs in an in-house way, not to mention other features like form processing and auth that help make the approach feel more monolith-y. DigitalOcean’s App Platform is a Jamstack host, but designed such that any other additional services are right there. The same is true for AWS Amplify or Azure Static Web Apps.
I added to Jay’s list the inert attribute, which certainly didn’t get widely shipped, but we are seeing a smidge of progress on it, with Safari being the first-mover.
Micro-frontends. I’m on the fence here, as I literally don’t get it. I think I’ll need to read more about it and see clear examples before I can weigh in on the technical choice here. But from a people perspective, it seems like a questionable move right out of the gate. I get that it’s complicated to get teams to work together perfectly, but splitting up their responsibilities and depth of technical knowledge doesn’t seem like a healthy solution that builds great sites.
The death of Jamstack (but not really). It’s mostly about the term itself, which I agree has gotten far too loaded and, thus, is losing meaning. “I think in 2022 we’ll see the confusion and exhaustion culminate in a gradual retreat from the term.” I can see that. Even using it in this post doesn’t feel quite right anymore.
Progressive enhancement. Jay points to frameworks producing functional sites that don’t require client-side JavaScript, which I agree is a major trend that has all sorts of positive fall-out. And I love it. I generally think of progressive enhancement as developers building interactive components — components that require tech that not all browsers support — and making sure they have some baseline functionality, even if JavaScript, or whatever other tech, fails. I never see that grow in popularity. I think it’s related to the things Melanie talks about here.
Functional JavaScript. Wild card choice! I like it! I can’t opine, but this is the kind of thing Jay is good at when it comes to front-end predictions.
Every now and then, I find that I’ve accumulated a bunch of links about various things I find interesting. Like React and JavaScript! Here’s a list of nine links to other articles about them that I’ve been saving up and think are worth sharing.
Seed Funding for Remix Remix went open source after taking funding which seems like a solid move. It’s a for-now-React-only framework, so I think it’s fair that everyone asks how does it compare to Next.js. Which they answered. Probably worth noting again for us CSS folks, Kent mentioned: “Because Remix allows me to easily control which of my CSS files is on the page at any given time, I don’t have all the problems that triggered the JavaScript community to invent workarounds like CSS-in-JS.”
React Router v6 Speaking of that gang, they released React Router v6, which looks like a positive move — all hooks based, 50% smaller than v5 — but is yet another major version with API changes. React Router has a history of API changes like this and they trigger plenty of grumbling in the community. There is plenty of that again.
React Aria “A library of React Hooks that provides accessible UI primitives for your design system”from… Adobe. Interesting. Looks like some pretty hard problems being solved here, like FocusScope (“When the contain prop is set, focus is contained within the scope.”) and interesting color inputs, like useColorField, useColorSlider, and useColorWheel. There are 59 hooks in all, ranging from interactions and forms to overlays and internationalization, with plenty of others in between.
Front End Tables: Sorting, Filtering, and Pagination Tania Rascia: “One thing I’ve had to do at every job I’ve had is implement a table on the front end of an application that has sorting, filtering, and pagination.” No shame in reaching for a big library with all these features, but sometimes it’s best to DIY.
Good advice on JSX conditionals Vladimir Klepov covers the (weirdly) many ways fairly simple conditionals can go wrong, like the number 0 leaking into your markup, and how to manage update versus remount in conditionals.
useProseMirror I’ve found ProseMirror to be a pretty nice rich text editor in the past. The library itself isn’t actually in React, so I think it’s a smart call here to make a modern React wrapper for it.
Spead up sluggish inputs with useDeferredValue You can introduce gnarly input delay the more work that an onChange function has to do on a text input. “useDeferredValue gives us a way to separate high priority updates from low priority updates for cases like this.”
🎥 A Cartoon Intro to WebAssembly If you don’t have a good understanding of what WebAssembly is, then Lin Clark will get you there in this video from JSConf EU 2017. So, no, not a new link or anything, but it’s new to me!
🎥 Turborepo Demo and Walkthrough Vercel bought Turborepo. Turborepo is specifically focused on making monorepos better. As someone who’s main codebase is a monorepo with Lerna and Yarn Workspaces such that we can have multiple different sites all share things like a design system, this is right up our alley. This video is with the Turborepo creator Jared Palmer and Lee Robinson, head of developer relations at Vercel. In this video, you get to see it all work.
This is a wonderful roundup from Jeremy, who I picture circling January 1, 2022, in red marker on a giant paper calendar back in 2008 and patiently counting the days.
See, there was a little smattering of internet drama back in 2008 (weird, right?) where Hixie kind of “officially speculated” that HTML5 would take 19 years to make it to full “recommended” status (2003-2022). Seems like most web developers at the time were quite certain HTML, and perhaps the internet as we know it, would be essentially obsolete by 2022. They were not right.
It’s 2022. And the current relevance of TypeScript is undisputed. TypeScript has dominated the front-end developer experience by many, many accounts. By now you likely already know that TypeScript is a superset of JavaScript, building on JavaScript by adding syntax for type declarations, classes, and other object-oriented features with type-checking.
And when I say dominated, I mean TypeScript has literally exploded on the scene since it was introduced in 2012.
That sort of growth is incredible, especially considering it really started taking off in 2017. But as we get into 2022, just how relevant is TypeScript going to be moving forward? It’s not like TypeScript will continue to grow leaps and bounds this way forever… right?!
It’s interesting to poke at the idea a bit to see where TypeScript is today and how it will continue playing a role in front-end development into the future. Jake Albaugh has already poked at the relevance of TypeScript himself, but from the perspective of whether or not knowing JavaScript makes you relevant as a developer.
So, what’s the future relevance of TypeScript look like? Let’s see.
TypeScript’s roots
OK, so we know TypeScript adds syntax to JavaScript. This syntax is used by TypeScript’scompiler to sniff out code errors before they happen, then it spits out vanilla JavaScript that browsers can understand. It’s also worth mentioned that TypeScript is maintained by Microsoft, licensed under Apache 2 license.
And we can’t really talk about TypeScript without also calling out ECMAScript (ES), the JavaScript standard and scripting language specification standardized by ECMA International. The JavaScript naming convention started with ES1 and has evolved to ES6. The most recent version, the 12th edition — or ECMAScript 2021 — was published in June 2021.
TypeScript is a strict superset of ECMAScript 2015. That means a JavaScript program is also a valid TypeScript program. Conversely, a TypeScript program can effortlessly consume JavaScript.
It’s important to know all this because we need to know where TypeScript gets its roots in order to poke at its possible future.
TypeScript’s components
There are three fundamental components of TypeScript that make it as awesome as it is. Not only do we get the aforementioned type-checking that comes with the TypeScript language, but we get the TypeScript compiler and language service as well.
These are the pieces that keep TypeScript relevant, so to speak. The language is what developers love writing. The compiler is what interprets the language for browsers. The service processes the language on demand with blazing speed. Without these, TypeScript just ain’t what it is.
TypeScript support
There’s another key piece to TypeScript’s relevance that often goes overlooked: it’s super well-supported by text editors. TypeScript’s relevance is only as good as it is accessible and something that can be picked up by just about any front-ender.
TypeScript was initially supported only in Microsoft’s Visual Studio code editor. Makes sense, right? I mean, TypeScript is maintained by Microsoft and all. But as TypeScript grew legs, more code editors and IDEs began started supporting it either natively or with plugins.
Some of the most popular editors and IDEs, besides Visual Studio Code, include:
And with more support comes more TypeScript relevance. The fact that you can pick up nearly any code editor and start hammering out TypeScript code makes it more and more a go-to choice as it’s simply available where you want it.
TypeScript’s evolution
From its initial release in 2012 to the present day (early 2022), there have been many improvements released in each version of TypeScript, like:
TypeScript 1.6 introduced the .tsx file extension, which enabled JSX within TypeScript files and made the new as operator the default way to cast.
TypeScript 2 brought in a major improvement by allowing developers to optionally prevent variables from being assigned null values.
Version 2.3 of TypeScript introduced support for ES6 features, such as generators and iterators.
TypeScript 3 brought in language enhancements, such as tuples in REST parameters and spread expressions.
TypeScript 4 (we’re currently at 4.5.2 at the time of this writing) continues the evolution with refinements to tuples, template literal types, smarter type alias preservation, and improvements to Awaited and Promise.
This is exactly the sort of speed at which you might expect to see a blossoming programming language iterating and releasing new features. Again, good context when evaluating the relevance of TypeScript moving forward.
TypeScript’s popularity
We’ve already established that TypeScript is, like, super popular. The chart that kicked off this post showed TypeScript growing at breakneck speed in a matter of a few years to rank as the fourth most popular language. But don’t just take my word and GitHub’s word for it (it is owned by Microsoft after all). Here’s a bunch of published research from various places saying the same thing.
RedMonk
RedMonk, a development industry analysis firm has this to say about ranking TypeScript eighth in its 2021 list of most popular languages:
Does [TypeScript] have the capacity to move up and outperform long term incumbents such as C#, C++ or even PHP eventually, or is TypeScript essentially at or near the limits of its potential? It’s impossible to say with any reliability, but it is interesting to note that a year ago at this time TypeScript lagged the fifth place languages by six points in the combined score that the rankings are based on, but in this run the gap was only two points. Past performance doesn’t always predict future performance, of course, but it suggests at least that TypeScript might yet have some room in front of it.
PYPL Index
The PYPL Index is a measure of Google searches for programming language tutorials. It’s not exact science, but a good indicator of interest. And, over time, TypeScript appears to be trending in a flat direction. TypeScript currently ranks eighth and, compared to a year ago at this time, PYPL indicates that TyeScript is trending flat overall while other languages, like Python and C++ are trending up year-over-year.
Stack Overflow 2021 Developer Survey
According to Stack Overflow’s 2021 Developer Survey, TypeScript is about as popular as PYPL indicates it is, coming in as the seventh most popular language, as ranked by approximately 83,000 developers.
The Stack Overflow annual survey is one of the most credible and most-awaited developer surveys. It uses a humongous developer base from all over the world to arrive at its conclusions. And how relevant does this say TypeScript is in the front-end community? Well, it’s not only the seventh most popular language, but it the second technology that developers want to work with the most (followed by Python), and the third most loved language (behind Rust and Clojure).
This annual survey (the next one is open now!) shows that TypeScript boasts a sparkling 93% satisfaction rate (up from 89% in 2019) among developers which is tops in the rankings. It also took top prize in interest (70%, up from 66%), usage (78%, up from 66%), and awareness (100% which is shockingly flat from 2019).
GitHut 2.0 Language Rankings
This ranking is an analysis that interacts with GitHub to suss out the most used languages across GitHub. And it’s indicative of TypeScript’s relevance in that TypeScript ranked seventh in the first quarter of 2021 before leaping up to fourth in the fourth quarter, and with the highest year-over-year change.
OK, so it’s clear that TypeScript is a big deal. But again, how relevant will it be moving forward?
The relevance of TypeScript in 2022 and beyond
So far, I’ve tried to paint a picture that identifies where TypeScript fits into the front-end development landscape, showing how it’s quickly evolved into a mature and serious contender as a programming language, and is fast-becoming both the programming language of choice and the one people like most.
In other words: TypeScript is relevant today.
But if we want to take a guess at where TypeScript’s current success is taking it, then it’s worth taking a peek the official TypeScript roadmap over at GitHub.
Here’s what we have to look forward to:
typeof class changes
Allow more code before super calls in subclasses
Generalized index signatures
--noImplicitOverride and the override keyword
Static index signatures
Use unknown as the type for catch clause variables
Investigate nominal typing support
Flattening declarations
Implement the ES decorator proposal
Investigate ambient, deprecated, and conditional decorators
Investigate partial type argument inference
Implement a quick fix to scaffold local @types packages
Investigate error messages in haiku or iambic pentameter
Implement decorators for function expressions and arrow functions
I think all of these roadmapped features are both exciting and will play a big role in maintaining the relevance of TypeScript for the foreseeable future. And while I think all of them are worthy of deeper discussion, here are a few I believe are core for TypeScript in 2022 and beyond.
Flattening declarations
The flattening declarations proposal, for example, aims to enable bundling declarations for TypeScript projects so that a library can be consumed with a single TypeScript file, regardless of how many modules it may contain internally.
The idea with flattening declarations is that a single amalgamated and flattened .d.ts file, in addition to a single output .js file, should be emitted by the TypeScript compiler. Access modifiers should be taken into consideration and respected when generating the DTS. Having a single declaration file with flattened declarations will make things much easier for developers and improve maintainability in the long run.
Ambient, Deprecated, and Conditional decorators
Design time decorators— such as ambient and conditional decorators — are another feature to look forward to. Decorators enable developers to add both annotations and metadata to existing code in a declarative way. In TypeScript, each decorator has a special name starting with @ that will not be emitted in the converted JavaScript, but can be persisted in .d.ts outputs.
Consider, for example, if you could issue a warning whenever someone attempts to employ a deprecated method or property so that they could upgrade to a newer library version. By having ambient, deprecated, and conditional decorators as part of the TypeScript specification in the future, the language will provide more powerful ways for developers to annotate their code and include metadata in it.
Decorators for function expressions/arrow functions
Decorators for function and arrow expressions is another feature I think will build on TypeScript’s ongoing relevance. Adding annotations or metadata to those expressions will enable developers to determine at runtime information about which the decorator has been applied.
Investigate error messages in haiku or iambic pentameter
OK, so maybe this one isn’t so much about the relevance of TypeScript’s robust feature set, but I think the personality it adds to the language is part of the overall package that makes TypeScript a pleasure to use. How cool (and pleasant) would it be to get an error message like this:
My code is breaking Ignore this error message Everything is good #TSConf
Sure beats a programmatic message that can sometimes feel like a scolding! And while there has been no progress on this proposed feature in the last two years, it still exists on the official roadmap which means someone will eventually work on it.
Microsoft unveiled Visual Studio 2022 Preview 3 back in August 2021. There was a lot to get excited about with that release, like new JavaScript and TypeScript tools to enhance the experience for single-page applications and front-end development. Plus, it included a new JavaScript/TypeScript project type to facilitate developers building standalone Angular, React, and Vue projects. Then there’s the enhancement that Visual Studio will leverage the native CLIs of each JavaScript framework to build front-end project templates.
All of this to say that TypeScript is not just evolving; it is exploding and only gaining momentum as we settle in 2022. So, yes, TypeScript is relevant in 2022… and will continue to be for some time to come.
Every now and then, I find that I’ve accumulated a bunch of links about various things I find interesting. Accessibility is one of those things! Here’s a list of related links to other articles that I’ve been saving up and think are worth sharing.
Myths about Web Accessibility — Alvaro Montoro covers some classics. My favorite is “accessibility is for people with disabilities.” Accessibility is for people with disabilities, because they are people, and accessibility is for people.
Accessibility Myths — Speaking of myths, Sergei Kriger built this entire site for them. I’ll cherry pick “Accessibility can be achieved by only adding ARIA attributes”, which is famously wrong as the first rule of ARIA is not using it.
Form fields in depth — While perhaps not specifically about accessiblity, forms are among the most crucial things to get accessibility right on and go wrong far too often. This new guide from Google incorporates accessibility throughout and gets specifically into it as well.
Accessibility Maze — Build by the Digital Education Strategies team in The G. Raymond Chang School of Continuing Education at Ryerson University. So fun! You can (and largely have to) play the whole game on the keyboard.
HTML focusgroup attribute — You know how when you’ve focused on one of the radio buttons in a group of radio buttons, then you can use the arrow keys to move between them? Or how the up/down arrows work to navigate the items of a native select? You could call that “focus group navigation”, and unfortuantely we can’t tap into that behavior whenever we want to. But what if we could with something as simple as a focusgrup attribute in HTML? That’d be cool, someday.
Adding A Dyslexia-Friendly Mode To A Website — I always think of the Dyslexie font, but clearly there is a lot more to it than just using the right font. A lot more spacing, especially typographically, and less clutter is helpful. See the demo. A somewhat rare use-case of word-spacing in use there.
How many people with disabilities use our site? — Hidde de Vries says it’s probably not a big number, but that doesn’t matter (love the quote from Tim Cook). Still, if you need to find a business upside, Hidde points out a report that cites 15-20% of the world’s population has a disability.
🎥 Building The Most Inaccessible Site Possible — Manuel Matuzovic proves you can get 100’s across the board on a Lighthouse test and yet make an entirely unusable site. It’s like learning in reverse. If you know what causes problems, you know how not to do those things.
Every now and then, I find that I’ve accumulated a bunch of links about various things I find interesting. Typography is one of those things! Here’s a list of typography links to other articles that I’ve been saving up and think are worth sharing.
Output Sans goes variable — David Jonathan Ross’s Output is a real workhorse typeface. He’s been re-doing it as a variable as part of an effort to get variable fonts “over the hump” — that is, away from being thought of as experimental and thought of as practical for day-to-day usage.
Line Lengths — Shawn says, “it seems an obvious immediate win to apply max-width: 69ch to your blog content blocks.” Nice. Oliver Schöndorfer dug into line length recently too.
Smarter line-heights with “calc” — Check out this particular part of Josh’s custom CSS reset. A potentially cool way to handle line-height for both body copy and headers in one swoop.
Women in Type — Just an incredible website from the University of Reading team. “These women worked daily on developing and producing typefaces that were, eventually, almost always attributed to male designers. They merit attention as key contributors to the design process of many renowned typefaces that emerged throughout the twentieth century.”
Retail — “Retail is the result of focussing our energy on the not-too-trendy world of humanist sans.” Very nice work from OH no Type Company.
Designers’ Pick: Best Google Fonts for 2022 — The fact that you can go from zero to implemented custom fonts, for free, in like 30 seconds with Google Fonts is going to keep it the most-used custom font solution likely as long as it exists. Fortunately, the website for it has gotten a lot better, the performance of them has gotten good (and controllable), and as this post on Qode shows, there is a ton of really great new choices available. I like the look of Space Grotesk. The Typewolf newsletter is always covering new good ones. Lately: Readex Pro & Spline Sans.
This isn’t supposed to be any sort of decision-making based on browser User-Agent Strings. But, ya know, collectively, we do make those decisions.
Karl Dubost notes that there is a significant change coming to them, notably moving the version integer past two digits:
According to the Firefox release calendar, during the first quarter of 2022 (probably March), Firefox Nightly will reach version 100. It will set Firefox stable release version around May 2022 (if it doesn’t change until then).
