DEV Community: Kevin Ball

The React.ReactNode type is a black hole

Kevin Ball — Wed, 16 Feb 2022 07:00:00 +0000

As developers, we use TypeScript for a few different reasons. The self-documentation aspects are huge – being able to step into an unfamiliar function and know the shape of the objects it's expecting is a massive boon when working on a large project. The added tooling features, with IntelliSense and its ilk, are also a big help for productivity. But to me, the most important reason to use a strongly typed system is to eliminate an entire class of runtime bugs, where a function gets passed an object it doesn't know how to handle and fails at runtime.

It's that last reason that leads to the purpose for this post. I recently handled a bug where a React component was throwing an exception at runtime. The source of the issue was a recent refactor done when internationalizing this area of our application, where a prop expecting a renderable React.ReactNode was accidentally getting passed an object of class TranslatedText which could not render.

This is exactly the sort of bug we would expect TypeScript to catch at compile time!

How did this happen? At a high level it is because the React.ReactNode type included in DefinitelyTyped, used in hundreds of thousands of codebases around the world, is so weakly defined as to be practically meaningless.

We discussed this at a high level during the TIL segment of JS Party #213, but I thought it deserved a more rigorous treatment.

Come along as I share the exploration, why this bug has lingered in the wild for more than 3 (!) years since it was originally reported, and how we worked around it in our codebase to get ourselves protected again.

The Situation

It started with a simple bug report:

When I click on "Boost nudges" and attempt to select a filter group, I get an error saying something went wrong. This feature is vital for a demo I have tomorrow.

My first check was to see if I could reproduce it in the production application. I could. Next was to fire up a developer environment so I could get a useful backtrace, and the error was extremely clear:

Interpretation: React was trying to render something that it could not render. Using the file and line numbers to track down more, I could see that the object in question was a prop called description with the following type definition:

description: string | React.ReactNode;

The caller was passing it instead a TranslatedText object, which is a class we use in our system to handle internationalization. The expected use is that this object is passed to a <T> component that knows how to use it and a library of strings to render text in the correct language for the current user.

Having seen this: The fix was super simple. Wrap the TranslatedText object in a <T> component before passing it in as a prop.

With this patch in place, the immediate bug was resolved, and the demo mentioned in the ticket unblocked.

Understanding how the bug came to be was super simple - this portion of the application had only recently been internationalized, and the bug was introduced in that work. But then the real puzzle started: Isn't this type of bug exactly what using TypeScript and types is supposed to prevent? How in the world had the type system allowed something that was not renderable by React to be passed into a prop with type string | React.ReactNode?

The trail

When I first saw that this problem wasn't being caught, my initial thought was maybe for some reason type checking wasn't getting run at all. Maybe we had a bug with cross-module calls, or there was a problem in our configuration. But I was quickly able to rule this out by but reducing the prop type to string and seeing that it triggered a type error.

The next thing I tried was testing to see if somehow TranslatedText was somehow implementing the React.ReactNode interface, but adding a quick implements annotation to TranslatedText (i.e. class TranslatedText implements React.ReactNode) resulted in the compiler throwing an error. That matched my expectations, because it DOESN’T implement the interface - if it did, we wouldn't have had this problem in the first place!

I then started diving down into the way that React.ReactNode was defined. These definitions are coming from DefinitelyTyped, the canonical open source repository of type definitions for npm packages that don't natively include types, and the key definitions look like this:

    type ReactText = string | number;
    type ReactChild = ReactElement | ReactText;

    interface ReactNodeArray extends Array<ReactNode> {}
    type ReactFragment = {} | ReactNodeArray;
    type ReactNode = ReactChild | ReactFragment | ReactPortal | boolean | null | undefined;

There it is, in the ReactFragment definition!

The ReactFragment, which is included in the ReactNode type, includes an empty interface. Due to the way that TypeScript handles excess property checks, this means that the ReactNode type will accept any object except an object literal. For almost all intents and purposes, it is functionally equivalent to an any type. Even though most functions using this type will expect it to mean "something renderable by React".

At this point I brought this back to our team at Humu:

As folks dug in one of our team members discovered that that this has been a known issue since 2018! There is a discussion that implies an intent to fix the issue, but concerns about the ripple effects of introducing a fix, and no progress for the better part of a year.

First attempts at a fix

As we started looking at ways to address this issue in our codebase, we considered two options:

Moving everything in our codebase to a custom type
Using patch-package to update the React.ReactNode definition

Assessing the pros and cons of these different approaches, we felt that the patch-package approach would require fewer code changes and less ongoing cognitive load, but would have the disadvantage of requiring an additional dependency (and associated transient dependencies) and make it perhaps less visible what's going on.

In the end, we decided to try patch-package first because it would be less work. The change was super simple; we attempted a patch to the ReactFragment type that looked very much like the one that was proposed in the DefinitelyTyped discussion thread:

type Fragment = {
  key?: string | number | null;
  ref?: null;
  props?: {
    children?: ReactNode;
  };
}

While this approach didn't trigger any internal typing issues within our codebase, and resulted in the type system being able to catch the class of error that had bitten us at the beginning, it resulted in cascading type errors in calls into several React ecosystem libraries. We ran into troubles at the interface of our code into react-beautiful-dnd:

After diving down the rabbit hole and trying to figure out those type issues for a little while, only to have every change result in more and more type challenges, I decided that this would require someone with more TypeScript chops than me to figure out.

The Second Approach

The second approach we tried was to create a stricter type in our codebase, find/replace to use it everywhere, and then add a linter to keep it from being used. The types file we ended up with was very similar to the one we'd tried in the patch approach:

import { ReactChild, ReactPortal, ReactNodeArray } from 'react';

export type StrictReactFragment =
  | {
      key?: string | number | null;
      ref?: null;
      props?: {
        children?: StrictReactNode;
      };
    }
  | ReactNodeArray;
export type StrictReactNode =
  | ReactChild
  | StrictReactFragment
  | ReactPortal
  | boolean
  | null
  | undefined;

After verifying that this type actually caught the types of type error that we were trying to prevent, it was time to make the replacement across our codebase.

I briefly explored using jscodeshift to automatically make the replacement. I started going down that road, but I have no prior experience using jscodeshift and it was proving tricky. As I had limited time, I decided that our codebase was small enough that running find/replace in VS Code plus manually adding the import would be tractable and much faster than continuing to try to figure out jscodeshift.

NOTE: If anyone wants to write this codemod and send it me, I'd be happy to include it as an addendum to this post with a shoutout to you!

One PR later, we had a much safer codebase using StrictReactNode everywhere, but there was one step left to make this sustainable.

Writing an ESLint plugin

The reason React.ReactNode had permeated our codebase is that it is such a logical type to use in many situations. Any time you want to assert a prop is renderable by React, it's natural to reach for React.ReactNode.

Now we need all of our developers to instead reach for StrictReactNode. Leaving this to developer discretion or requiring this to be a part of manual code review and/or education seemed untenable, especially in a rapidly growing company like Humu.

To enforce the new practice and make it seamless to keep our codebase up to date and safe, we decided to write a custom ESLint linter to check for React.ReactNode and throw an error with a pointer to our preferred type.

This post is not about how ESLint plugins work, but in case you want to use it here is the plugin we arrived at:

module.exports = {
    create(context) {
        return {
            TSTypeReference(node) {
                if (
                    node.typeName.type === 'TSQualifiedName' &&
                    node.typeName.left.name === 'React' &&
                    node.typeName.right.name === 'ReactNode'
                ) {
                    context.report(
                        node,
                        node.loc,
                        'React.ReactNode considered unsafe. Use StrictReactNode from humu-components/src/util/strictReactNode instead.',
                    );
                }
            },
        };
    },
};

Now if someone does by accident try to use React.ReactNode in a type declaration, they get an error that looks like this:

Linting is a part of our CI testing that occurs before any branch can be merged, so this prevents anyone from accidentally pulling in the unsafe React.ReactNode type and points them to the replacement type instead.

Update: Mathieu TUDISCO wrote a more generalized eslint plugin with a fixer!

Wrapping Up

From my perspective, the entire goal of using TypeScript and a type system is to be able to prevent an entire class of bugs and make refactors like the original one that sparked this safe to do.

Having a wide open type like this in a super commonly used library is super scary. Time permitting, I will continue to work on getting this patched in DefinitelyTyped, but the ecosystem problem is large enough that this is unlikely to happen in a timely manner. Changes of this magnitude create a massive wave of ripples and types that need to be updated.

In the meantime, I highly recommend using an approach like our StrictReactNode to protect your codebase.

Friday Frontend: End of 2019 Edition

Kevin Ball — Fri, 20 Dec 2019 08:00:00 +0000

This will be my last Friday Frontend of 2019; I’ll be off the next two weeks, and then the newsletter will pick up again on January 10th. I hope you have a holiday break in front of you, and are able to unplug and enjoy it!

In the meantime, this week we’ve got a set of great articles, many of them retrospectives looking back not just one year, but 10 or even 15. There’s also some fascinating info in the State of JS Survey results, and some solid tutorials.

Enjoy!

Best,

KBall from ZenDev

CSS & SCSS

The Origin Story of Container Queries

An interesting look back at the origins of one of the most-desired not-yet-implemented CSS features. There are some interesting backstory pieces about why element-level media queries are so hard, but it is kind of surprising that not even a deliberately limited version of this exists now almost 10 years after folk started talking about them.

A History of CSS Through Fifteen Years of 24 ways

Fascinating look back through not only how CSS has evolved, but how one of the thinking of an expert in the field has evolved with it. I love how it highlights the ways our solutions have evolved with the spec.

Why CSS HSL Colors are Better!

A dive into how by combining CSS variables with HSL formatted colors you can create incredibly concise, readable, and adaptive color schemes.

7 Uses for CSS Custom Properties

Great quick roundup of use cases for CSS Custom Properties. I particularly like the staggered animations example. I’d love to take that further - what other properties of animations could we vary based on custom properties?

JavaScript

State of JS 2019 Results

A very interesting look at the state of the JavaScript ecosystem today. CAVEAT: The respondents are almost certainly not representative of the entire ecosystem; it skews heavily male, heavily US, and based on prior years more heavily comes from the React community than any others. So don’t draw too deep of conclusions, but still fascinating to explore. My favorite stat - JSParty is on the list for most listened-to podcasts. Not as high as I’d like, but last year didn’t make a showing, so it’s moving up! :)

🚀⚙️ JavaScript Visualized: the JavaScript Engine

Short and sweet, with some wonderful animated visuals, this post gets into the basics of what’s going on behind the scenes to run the JavaScript code you write.

Thoughts On Svelte.

Given one of my predictions for 2020 is the continued rise of precompilation-based tooling and frameworks like Svelte, I’m on the lookout for interesting takes on it. I appreciate that the author highlights the way that competition is improving the entire frontend framework ecosystem, and whether or not Svelte wins increased precompilation is going to be spreading more and more.

Portal – a new feature in Vue 3

This is an innovation from the React world that I’m super excited to see come to Vue. While a purely-nested component tree is great for a very large percentage of the problems we solve on the front-end, there are times (the canonical example being modals) where the logical place and the right place in the DOM are different. Portals give us a way to handle that.

Other Awesomeness

"The Decade of Design”: How the last 10 years transformed design’s role in tech

This is fun - not just “end of year” look-backs, but also “end-of-decade”. This one in particular highlights a trend that I think has been huge - the rise of design as both a differentiator and a requirement in technology projects. The bars for both “minimum viable” and “well designed” have gone wayyyyy up, even as the complexity of different device types and formats has also exploded.

Design APIs: The Evolution of Design Systems

Hmm… I’m not sure I agree with the author about where this is going, but I do find this a fascinating look at one of the ways we could further standardize the ways in which design and design systems interact and are used within software.

CSS 3D transformations & SVG

Super exciting look at the future of SVG. I’ve long felt like SVG is underutilized, and one of the reasons is that while it looks an awful lot like HTML, and in many cases works like it, there are lots of subtle cases where it doesn’t. This article explores one of the underlying reasons, why there’s now a chance to eliminate those discrepancies, and some of the power unveiled when you do.

Average Page Load Times for 2020 – Are you faster?

Quick look at the state of the web when it comes to load-time - how fast are things, how heavy, and how many different resources are being loaded?

Happy Friday!

That's it for this week's Friday Frontend newsletter. If you enjoyed this, you should probably follow me on Twitter or join my mailing list. Sign up to get these newsletters straight to your inbox every Friday! Sign up here: https://zendev.com/friday-frontend.html

Friday Frontend: Color Palettes and JS Performance Edition

Kevin Ball — Fri, 13 Dec 2019 08:00:00 +0000

Happy Friday! Just two full weeks left in 2019, and we’re starting to see a number of end of year round up/looking forwards, plus some “advent calendar” pieces publishing something every day this month.

That said, what stood out to me this week was a set of pairs - first in the CSS section looking at tooling for color palettes, and second in the JavaScript section looking at performance. There’s also some great new tools around shadows and sharing React components, plus an *awesome* interview published on JSParty.

Enjoy!

Best,

KBall from ZenDev

CSS & SCSS

A Handy Sass-Powered Tool for Making Balanced Color Palettes

Fascinating exploration of color and a tool to look at and balance different attributes. Interesting both for the tool itself and the exploration into Sass functionality to understand how it was built.

Calculating Color: Dynamic Color Theming with Pure CSS ⬇

If this wasn’t dated beforehand, I’d swear it was a reaction to the article above. This one takes a set of base colors and explores how you can use vanilla CSS to build out a color palette, creating much of the same functionality exposed by Sass.

Make a smooth shadow, friend.

Super cool tool that lets you manipulate a variety of dimensions of box shadows using a GUI, see the output, and copy the CSS to reproduce the effect.

CSS: An Art, a Science, a Nightmare (Everything You Should Know)

Solid overview article. I also super appreciate that the author makes clear who the article is for - not experts, not novices, but “the middleground of people who have had to touch CSS a few times here and there but ultimately don't feel like they know what they're doing, or struggle with making basic layouts.”

5 CSS Predictions For 2020

We’re at that time of year, where it’s great to look back and look forward. I think this is generally a great list, and agree with almost all of them. I do think the “hail mary” prediction of a package manager for CSS is pretty unlikely, but I wouldn’t be at all be surprised to see more css-specific tooling spring up around JavaScript package managers like npm.

JavaScript

JavaScript component-level CPU costs

Woah, this is a fascinatingly deep and precise look at the CPU cost of various JavaScript components. Appears to only fully work on Linux, but lets you get literal number of CPU instruction counts on how expensive things are to render and run.

The unseen performance costs of modern CSS-in-JS libraries in React apps

Great dive beneath the hood of what’s going in on some popular CSS-in-JS libraries, and what the performance implications are.

JavaScript Christmas

An “advent calendar” highlighting a different JavaScript article every day for the first 25 days of December. Depending on your level and interests different articles may be of interest, but it’s definitely worth taking a look.

Introducing React View, an Interactive Playground for Your Components

Interesting looking alternative to Storybook for creating interactive documentation of React components, open sourced by Uber. They’ve made some different choices than storybook, for one they allow live code editing in the web page to see how things work. I’ll be interested to hear what people think.

What's the difference between encodeURI() and encodeURIComponent() in vanilla JS?

Super short article, but it clearly answers a question I’ve found myself googling many times over my career, so I thought it might be useful to you too. :)

Promoted Link

LAST DAY TODAY - Udemy Courses starting at $11.99

Ending today, Udemy is running a “Tis the season for learning” sale marking down all of their courses, with almost all of them between $11.99 and $14.99. If you have been meaning to get something, now is the time! And if you’re looking for recommendations, Courses I’ve been recommending recently include The Complete JavaScript Course 2019, Modern React with Redux (the course I learned React from, updated with all the latest features), and Vue JS 2 - The Complete Guide (by one of my favorite Udemy instructors, Maximilian Schwarzmüller.)

Other Awesomeness

Modernizing Etsy’s codebase with React (Audio with transcript)

(Bias alert: I recorded this interview) -- Super fun interview with Katie Sylor-Miller, front-end architect at Etsy. We talk about migrating OhShitGit to the JAMStack, migrating legacy codebases to modern front-end technologies, and design systems.

Making a Better Custom Select Element

Fascinating walkthrough of the process of making an accessible custom element. Explores a series of different type of use case - mouse, touch, sighted keyboard use, screen reader plus keyboard - and looks at what we need for each to make this new element both understandable and usable.

WebAssembly becomes a W3C Recommendation

From an exploratory working group to an official W3C recommendation and standard, WebAssembly has grown up and is now clearly a huge part of the future of the web.

Motion Paths – Past, Present and Future

Cool tutorial on animating SVGs along a motion path. Looks at both current solutions using GSAP and the upcoming CSS motion path module. SUPER excited to have this accessible in CSS!

Brand Illustration Systems: Drawing A Strong Visual Identity

A delightful look at the process of design when it comes to visual brand identity. This is an area of design that front-end developers often have less insight into, as it comes well before the actual design of pages and components, but it’s super key for creating a recognizable and relatable brand.

Happy Friday!

Friday Frontend: CSS Subgrids Are Here Edition

Kevin Ball — Fri, 06 Dec 2019 08:00:00 +0000

Happy Friday! Hope you had a great week, and are going to have a great weekend.

There are a lot of great articles in this week’s edition, but there are 2 in particular I want to draw your attention to. First, the Firefox announcement with the latest version of Firefox means that CSS Subgrid is now LIVE in a browser. This is another huge step forward for the CSS world. The second is the article about CSS Architecture in modern JavaScript Applications. It is a tremendously deep and thoughtful piece - if you’re using any form of CSS-in-JS solution, or even working in a component-based JS application and trying to figure out your CSS strategy, I highly recommend it.

Enjoy!

Best,

KBall from ZenDev

P.S. Special announcement, I’ve just joined the engineering team at a startup called Humu. Don’t worry, it won’t get in the way of this newsletter, but may mean I’m slightly less responsive to email inquiries during the week, and I’ll no longer be offering 1 on 1 coaching. Also, if you’re interested in joining a diverse team that is using science, machine learning, and a little bit of love to make work better for businesses everywhere, we are hiring. ;)

CSS & SCSS

Case Study: lynnandtonic.com 2019 refresh

This is simply delightful! A wonderfully whimsical take on a website landing page that animates and changes as you resize the page (Go play with it! Zoom in and out! It’s fun!), and a coherent and easy-to-follow explanation of the techniques used to achieve it.

Avoiding jagged edges on gradients.

Simple quick hit CSS tactic. Lets you create angled color transformations without jagged pixelization. Love it!

Simplified Fluid Typography

I love this concept of “clamped” fluid typography; to me it fits extremely well with the “fluid” approach to responsiveness that is encouraged by flexbox layouts. We should no longer be thinking of responsiveness as a set of rigid snapshots at different breakpoints, but continuous variation between certain “sanity” clamps.

How to Overlap Images in CSS

Great article on using CSS Grid to overlap images without taking them out of flow - complete with fallback CSS that works on the same markup for those who have to support IE. Bonus: This site has a wonderfully whimsical stylistic touch taking advantage of custom cursor images.

The Power (and Fun) of Scope with CSS Custom Properties

Super fun article exploring what you can do by taking advantage of scope with CSS custom properties. While I wouldn’t recommend getting rid of semantic classes with inline variable setting (as shown in one example), the ability to do programmatic variation of parameters is fascinating, and the improvements of readability & code length even within the semantic classes is phenomenal.

JavaScript

CSS Architecture for Modern JavaScript Applications

Putting this in the JavaScript section because it’s only really relevant for folks who are using CSS-in-JS and other modern JavaScript, but really I recommend it to everyone. A tour de force on how to think about UI components and UI states in modern component-oriented systems.

The 2019 State of JavaScript Survey

This link is for taking the survey - results will be out later. This survey has been getting better and better each year, but still has some representation problems due to the concentration of their audience within the React community. Particularly if you’re in another part of the JavaScript/frontend ecosystem, make sure you take time to make your voice heard! (Also, there’s a neat blog post about what’s new in the survey this year)

Top ways to learn Vue 3

Excellent roundup of materials to get ready for the Vue 3 release, which is currently scheduled to come out in Q1 of next year. I’m super excited for this! It’s going to be a huge step forward in the Vue ecosystem, and I can’t wait to see the patterns that emerge as folks start to use the new functionality.

The complete guide to building a smart data table in React

I’ve gotten asked about smart data tables pretty regularly. It’s a problem that just seems to arrive a lot, particularly in admin/business dashboards. This is a nice rundown of options available from libraries in React, what some of the tradeoffs are, and how to do an implementation. I’d love to see a similar article for Vue.

Other Awesomeness

Firefox 71: A year-end arrival

This is a HUGE release, with some amazing new stuff, but I’m going to focus on just one massively important feature. CSS Subgrid! Subgrid has been loooooong awaited and I’m super excited to see it finally hitting browsers; this enables some amazing new functionality in terms of nesting components within grid.

There is no “Myths of Color Contrast Accessibility”

This article is a followup/response to another interesting article published a month and a half ago. Neither is perfect - I have agreement and disagreement with both - and there is some rambling, but I found them both fascinating explorations of a very tricky topic: colors. And particularly how you deal with brand colors that don’t create great contrasts when used in buttons with “common sense” text colors.

WhoCanUse

While we’re talking about color and accessibility, this is a super neat new website that lets you put in color pairs and breaks down not only the contrast ratio, but what types of visual disabilities are going to have trouble seeing it. I also enjoyed the visual display of what a contrast might look like to those folks with particular challenges, e.g. red/green colorblind, etc. Very cool!

Semantic sidenotes for the web

Fascinating look through an effort to make truly semantic sidenotes with HTML, that behave properly across various devices including screen readers.

Checklist to avoid the most common accessibility errors

Super useful! A quick hits rundown of the most common accessibility errors, tools for diagnosing them, and recommendations for how to fix. Love it!

Happy Friday!

Friday Frontend: Thanksgiving 2019 Edition

Kevin Ball — Fri, 29 Nov 2019 08:00:00 +0000

(Editor note - sorry for the late republish on web, things were very busy the 2nd half of this month. To make sure you see get this on time, sign up for the email newsletter)

Happy Thanksgiving for those of you in the US. I have mixed feelings about this holiday, but won’t say no to excuses for time off and time with my family. Hope you had a good holiday without too much arguing with the family you try to stay away from!

We’re a little light on links this week because I’m rushing to put this together in between family obligations, but still some great stuff to check out. I particularly like the article on Orthogonal React components, and the one on Adaptive Loading.

Enjoy!

Best,

KBall from ZenDev

CSS & SCSS

Playing Sounds with CSS

In the “cool party trick” rather than “use this for production” category, but this is pretty cool! The demos seem pretty fragile though - They’re supposed to be chrome/chromium only, but for me only worked in Brave (not even in Chrome). Your mileage may vary.

Using CSS custom properties to reduce the size of your CSS

I like this because it highlights the way your thinking can change as you start to incorporate CSS custom properties, and how you can use that to clean up and shrink the size of an existing CSS codebase.

💪 Train your CSS skills with online games 👾

Nice collection of games you can use to level up on a range of different CSS skills. Varies between very specific (flexbox froggy!) and very generic (CSS Battle)

The Thought Process Behind a Flexbox Layout

Train-of-thought style post taking you through what you can do with Flexbox, exploring various behaviors both from their defaults and what you can do with them. Great if you don’t feel 100% comfortable with Flexbox and want to ride along as someone explores it.

JavaScript

15 JAMstack Resources You Need as a Web Developer

I’m pretty excited about the JAMStack as a way forward for fast, secure web applications that can be build largely by front-end developers. If you’re intrigued, but not sure where to start, this is a great set of resources to get you going.

The Benefits of Orthogonal React Components

This is a nice look at how you can apply separation of concerns within React components, separating across different dimensions than we might have traditionally thought of for the front end. I appreciate that the author also highlights not over-applying the principle. I think you can apply similar logic to knowing when to refactor code - if it’s not changing, or easy to understand, leave it alone, but if the code is both complex and changing frequently, it’s time to refactor (or in this case, orthogonalize).

Other Awesomeness

Smarter Design Systems Tools

A look through some of the ways we’re starting to do a better job as an industry in “closing the gap” between design and development.

Protecting and syncing secret keys

This isn’t really a front-end topic per se, but it’s a very key concept in building and deploying software that talks to other services (which is increasingly front-end folks are doing with stuff like JAMStack), and an area that I’ve seen new developers struggle. The details of approach vary slightly as you adopt different deployment platforms, but the core idea - keeping secrets in environment variables rather than code - stays consistent.

Adaptive Loading - Improving Web Performance on low-end devices

Super interesting look into a new concept/approach for progressive enhancement, in this case specifically choosing what JavaScript (and other assets) are served based on information about the device loading your website. Very cool!

Happy Friday!

Friday Frontend: Birthday Edition

Kevin Ball — Fri, 22 Nov 2019 08:00:00 +0000

(Editor note - sorry for the late republish on web, things were very busy the 2nd half of this month. To make sure you see get this on time, sign up for the email newsletter)

I’m another year older this weekend, and grateful for having you a part of my life this last year. Thanks for continuing to read, and I hope this newsletter continues to be valuable to you.

This week, my favorite articles are in the JavaScript section, particularly the ‘build your own React’ deep dive and the post looking forward to the pipeline operator.

Enjoy!

Best,

KBall from ZenDev

CSS & SCSS

Finally, it Will Be Easy to Change the Color of List Bullets

A look through the history of our options for controlling the style of list bullets. Starts with the oldest solution, looks at a better version that works right now, and then gives us a glimpse into the future.

CSS Grid: 3 practical examples

Nice learn by example approach to CSS Grid. Takes a set of realistic layout problems and walks through solving them using grid.

How Do You Remove Unused CSS From a Site?

A look through the state of the art of options for removing unused CSS. The key takeaway: There is no magic solution, they all have tradeoffs, and you need to understand what your tools are doing! I’ve seen a lot of folks try to just drop in uncss or purgecss and shoot themselves in the foot.

Understanding the Difference Between CSS Resolution and Device Resolution

Super helpful breakdown of the different things we mean when we say ‘pixel’ in different contexts. Explains the origins of the difference, and how to handle it.

JavaScript

Build your own React

Wow. This is a lot. But it’s super cool - starting from some simple React code, the author takes you through progressively implementing React to show how that code becomes DOM elements on your page. A great way to learn what’s happening under the hood of the most popular frontend framework.

Responsible JavaScript: Part III

Deep dive look at the challenges and problems of using 3rd-party scripts, and how you can mitigate some of them. It may not be possible to completely eliminate them (though I have so far kept them out of my newest site and am loving the speed of having zero third party scripts), but after reading this you’ll be eager to trim them down and have a plan for what to do when you can’t.

Breaking Chains with Pipelines in Modern JavaScript

I think the pipeline operator is the feature I’m most excited about in upcoming JavaScript, and this article does a good job of illustrating why. Combining it with generators and iterators allows an incredibly clean and still performant approach to functional programming in JavaScript. Yes!

Handling null and undefined in JavaScript

Null and undefined are edge cases that are extremely frequent sources of bugs in JavaScript. This article looks at a range of techniques for handling and preventing those issuess.

Versatile Ivy: Using Angular and React Together

Interesting look at embedding Angular within React or React within Angular. Sure, for most situations you aren’t going to want to load both of these in one page, but it can happen, especially when in transition. Good to see how it can work.

Other Awesomeness

Variations on Theme: Reinventing Type on the Web

Part of a great series of insights that CSS tricks put together from web developers and designers about what they’re excited about in the year 2020, this highlights why this year may truly be the year variable fonts take off.

Get More For Less With Variable Fonts

If the above article has you intrigued, this one will take you further, looking in more detail at what variable fonts enable and what exactly the axes of variation are.

Scaling GraphQL at PayPal

Excellent case study of implementing and scaling GraphQL at a large company across many services and handling very large amounts of traffic.

The Aesthetic-Accessibility Paradox

I think this author is wrong along a few dimensions, and pretty abrasive in their response to some comments. However, I also think that there is a dimension here worth discussing, which is how to think about accessibility (particularly in colors) when it conflicts with other design goals. Honestly with the prevalence of theming and the increasing existence of settings like prefers-reduced-motion I wonder if we could resolve this by creating high-contrast and low-contrast themes, perhaps even automatically switched between using a media query.

Happy Friday!

Friday Frontend: Very Cold Edition

Kevin Ball — Fri, 15 Nov 2019 08:00:00 +0000

Hope you’re staying warm during the record cold weather we’re having across most of the US. Even over here in California where the recent polar vortex hasn’t hit us as much, it’s been much chillier and definitely feeling like winter.

This week, my favorite articles are the early look at the Vue composition API and the dive into design patterns we can learn from newspapers.

Enjoy!

Best,

KBall from ZenDev

CSS & SCSS

CSS Logical Properties

Great overview of what CSS logical properties are, why you’d want to use them, and some examples in action. As we move to an ever-more global world, it’s great to see CSS catching up to the needs of languages that aren’t all left to right.

Two-Value Display Syntax (and Sometimes Three)

A much shorter read than the deep dive I sent out 2 weeks ago, this looks at how the upcoming multi-value version of the display property makes CSS more logical and easier to explain.

8 CSS image filters with code examples

A look through what is possible with some simple CSS filters on images. I think for visual impact my favorite is the inversion filter, though I suspect grayscale and sepia will have far more examples of real-world use.

Some Things You Oughta Know When Working with Viewport Units

A nice quick-hit followup to an article I sent out last month, looks at some of the drawbacks/gotchas to using viewport units, and does a little bit of exploration into how you can address them.

aria-label Does Not Translate

Interesting look at the intersection between accessibility and language translation. The title is a little incorrect - in fact, Chrome does appear to include aria-label in its auto-translation, and given the 57% market share of Chrome worldwide, that is not insignificant.

JavaScript

An Early Look at the Vue 3 Composition API in the Wild

There’s been a lot of back and forth about the Composition API that is upcoming in Vue 3, and through the magic of plugins you can try it out now in Vue 2. This article does a nice job of showing how moving from the existing Vue 2 options API to the composition API can improve your code legibility.

The Wise Guide to React useState() Hook

React Hooks are now the norm for handling state within React, yet they can be pretty confusing to folks still used to a component-based syntax. This is a well-done in depth guide to the most common hook, useState.

JavaScript's try-catch hid my bugs! 🐞

A dive into error handling gotchas and better patterns in JavaScript using try/catch. Does a nice job going through the thinking around where to put error handling.

Attributes of object properties in JavaScript

This one is a bit of work to wrap your head around, but it dives deep into how object properties work in JavaScript. We love to think of properties as just being values we write, but they are not - they can be wrapped by getters and setters, they can be made readonly, and more.

Other Awesomeness

Location, Privilege and Performant Websites

A look at real-life consequences of disregarding performance in websites. Also, the website referred to is a shocking example of how naively including libraries adds up. Doing some quick digging into what they’re loading, I see 2 independent versions of jQuery (one conveniently renamed ‘xaquery’ to not do a name conflict), moment.js, lodash, plus over a megabyte of JavaScript from a 3rd party vendor called Coveo. Wow.

How to Fully Optimize Webpack 4 Tree Shaking

It’s a little bit down in the weeds, but if you’re inspired by the previous article to do something to reduce the amount of JavaScript you’re shipping, you may well want to dig into tree shaking. And if you are using webpack, you’ll find that it isn’t quiiiiiiite plug and play. That’s where this article comes in.

What I’ve learned about accessibility in SPAs

Solid look at accessibility patterns, some of which are unique to SPAs but others which are global. That said, I think my favorite thing is this takeaway: “Working on accessibility has improved the overall usability of my app in a number of ways, leading to unforeseen benefits such as KaiOS arrow key navigation and better integration tests.”

The Front-End Tooling Survey 2019 - Results

This survey deserves some of the same caveats and skepticism that many surveys of dev tools do - they have not done anything to figure out how representative the answers are of the broader community, and not done much in terms of exposing demographic info about who answered it. That said, there’s some interesting stuff in here. Don’t take it as gospel, but rather uses it to shine light on tools that maybe you will want to look into.

What Newspapers Can Teach Us About Web Design

Creativity is often the act of taking concepts from one domain into another. While newspapers are certainly not the only good source of inspiration for web design, they have had to grapple with many of the same information architecture problems, and over the centuries (!) they have been around have developed some very strong patterns.

Happy Friday!

Friday Frontend: Expanding Your Sense of the Possible Edition

Kevin Ball — Fri, 08 Nov 2019 08:00:00 +0000

Hope your week was good! I’ve caught a bit of a cold but am generally excited to be into November and on to the holiday season.

This week, there’s a number of articles that will expand your sense of the possible. From a look at upcoming CSS specifications to crazy CSS artwork, new JavaScript language features to a deep dive on concurrency in React, there’s a ton of great resources.

Enjoy!

Best,

KBall from ZenDev

CSS & SCSS

Show Search Button when Search Field is Non-Empty

Interesting look at what you can do with the :placeholder-shown selector to make your website respond to user-entered state, without any JavaScript. Accessibility caveat: You should almost never use placeholders to completely replace labels, but if you uses them in a complementary manner this technique can be super slick.

Things We Can’t (Yet) Do In CSS

This is a fascinating look at some design possibilities that exist in the print world but don’t yet work in CSS. And since it is coming from someone who sits on the specification body, I would imagine that many of these may make their way into our possibilities in the next few years. In fact, she includes some references to specs under way. I’m excited!

CSS Variables With Inline Styles

Very different approach - I’m not sure if I like it or not, but it’s mind expanding. The author defines a set of CSS classes that depend on variables, and then inline in the HTML manipulates those variables with inline styles. This seems super cool for prototyping, though I’d personally lean towards extracting those inline styles back out into classes as I moved towards production.

Uncommon Use Cases For Pseudo Elements

I’m a huge fan of pseudo elements - they let you get so much more out of your CSS than if you’re stuck just styling one object per object. And while maybe not as out of this world crazy as the examples in a.singlediv.com this article shows some great examples of how you can use pseudo-elements for innovative experiences.

PureCSS Lace

In the inspiration bucket, this is a pure HTML+CSS art piece. Take a look in chrome, then open up your inspector and start digging. It’s mind blowing.

JavaScript

What is super() in JavaScript?

Great introduction to using super within JavaScript. If you’re using the modern JavaScript class syntax, this is something you should definitely understand, otherwise you’ll be shooting yourself in the foot and wondering why code doesn’t work as you expect.

Making a Chart? Try Using Mobx State Tree to Power the Data

Fascinating look through modern graphic development using React and Mobx (an alternative to Redux) to power SVG generation, up to and including user-interactions on hover. Very very cool!

5 interesting and not-necessarily-useful Javascript tricks

I think the title is pretty accurate - not sure how many of these will actually be useful, but they are interesting, and reading about them will expand your sense of the possible in JavaScript.

Modern JavaScript features you may have missed

Also in the ‘expand your sense of the possible’ category, this article looks at the features added to the JavaScript language that have not been getting much attention.

Building Great User Experiences with Concurrent Mode and Suspense

Super in depth and not intended so much for application developers as for framework/library authors, but this is a deep dive into how the React team is thinking about data fetching, and how they’re thinking about Concurrent Mode and Suspense changing the way we write in React.

Other Awesomeness

Navigating Software Engineering Career Paths

(Bias alert - I wrote this). How do you know if you’re ready for a senior engineering position? What should you even be working on learning? I hear these questions all the time, and this post is an effort to start addressing them. I aggregated results from a large number of published engineering career progressions and boiled them down to a single progression for your use.

Creating Online Environments That Work Well For Older Users

This rings super true - while our industry loves to stereotype older users as incompetent, there are huge numbers of design choices that simply fail to take into account different preferences and declining physical characteristics. As someone who’s eyes have gone prematurely bad, I beg designers to look and listen to the contrast and font size recommendations! There’s some other great context here for understanding this demographic.

PRELOADING FONTS: WHEN DOES IT MAKE SENSE?

Fonts are honestly one of the trickiest tradeoffs when it comes to performance and design. We all love our beautiful custom fonts, but they’re also slow to load and can result in awkward loading states. This article looks at one of the approaches available to us to mitigate the issue.

The Trick to Animating the Dot on the Letter “i”

Great effect! Separate out the dot from ‘i’ (or ‘j’ for that matter) by using other glyphs, allowing you to create some fascinating animations. That said, read the comments for better accessibility recommendations than those in the article.

Happy Friday!

Navigating Software Engineering Career Paths

Kevin Ball — Tue, 05 Nov 2019 08:00:00 +0000

Should you dive deep into one front-end framework or try to learn all of them?

How do you know if you’re ready for a senior engineering position?

What should you even be working on learning?

These questions are extremely common in a field as rapidly changing as software engineering, and particularly front-end development, and answers are hard to find.

Existing Resources on Engineer Careers

Luckily, there’s some great resources out there - a bunch of top companies have published their engineering career roadmaps that we can look to as guidelines for how careers progress.

And Jonny Burch, a designer from the UK, has done us the favor of gathering a list of all of these different roadmaps at progression.fyi.

But it’s still kind of overwhelming to dig through. There’s a TON of resources, and they’re all somewhat different. Someroadmaps have more levels than others, some use different names, some include management and some do not. Some focus on design, others on engineering.

But there’s enough commonalities that I think we can draw some big pictures together. This post is an attempt to dothis, to provide a roadmap for understanding how career advancement looks across the industry.

For each job title, I pull together a set of typical characteristics, a set of milestone-related questions to ask yourself to understand if you’re operating at that level, some items to focus on, and some recommended resources.

Note: This is slightly incomplete, but I found myself referencing it enough I want to make it public anyway. In particular, I do not currently include info on ‘what to focus on’ or recommended resources for the highest level of individual contributor, and drop both these and the ‘what to focus on’ or the upper levels of management. If you’re in one of those roles and would like to contribute guidance please leave a comment.

Key Premises

Some things to be aware of as you look through this article, and to understand how I’ve pulled these together from the underlying data

Many published engineering progressions separate out different categories of skills (technical skills, communication skills, leadership, making your team better…) and some map progressions in each. I have deliberately kept a single progression for simplicity, but you will see different types of skills, with the emphasis changing as you move through different positions.
Not every engineer is expected to go through all of these levels. Many will very happily get to senior engineer and not move up further levels. There is room for progression (both in skill and pay) within each level.
Smaller companies will tend to have fewer formal levels, sometimes with only one or two, while larger ones will have finer-grained progressions. Regardless of your current official title, you can use this progression as a way to identify where you’re at in your career and what would be helpful for you to focus on.
Management is a completely separate track from engineering (makers). It is emphatically not the “natural” step up, or even necessarily “above” higher levels of engineers. In most progressions, a low level manager is about equivalent to a “Lead” engineer or even “Senior” engineer in terms of pay grade.

Technical Track

Junior Engineer

The first step getting into the industry. Typically straight from university or a boot camp. Where we all started!

Characteristics:

Typically 0-2 years of experience.
Typically working on well-defined tasks
Often doing a lot of bugfixes
Learning skills & processes
Learning how to learn

Milestone questions to ask as you advance within this tier:

Are you able to apply most of the fundamentals of your area of focus? (backend dev => CS concepts, databases, servers, FE => HTML, CSS, accessibility, etc)
Are you able to prioritize and complete well-defined programming tasks?
Are you actively working to learn and improve your skills?

What to focus on

You should be working on getting deep understanding of 1 specialization. E.g. Focus on frontend or backend, pick a framework, and go deep.
You should be working on improving your habits. Get into habits of learning, being productive every day, and making lists of what you need to get done.

Resource Recommendations

Note: Depending on what domain of software development you work in, there are a ton of domain-specific resources out there. I’m not going to try to detail them all, rather pointing to more generalized resources.

Mid-Level Engineer

The “in-between” between a junior and senior. At many companies they may just call this position “engineer”, though at many startups that’s the only title they ever give so the name isn’t super helpful.

Characteristics:

Typical 2-5 years of experience
Able to design & architect implementation of features within area of expertise
Follows established patterns and conventions without need for guidance
Generally able to debug own code
Involved in team-level technical discussions

Milestone questions to ask as you advance within this tier:

Can you take a small to medium sized feature from start to finish with minimal guidance?
Are you able to unblock yourself when you run into problems?
Do you participate in team discussions about technology choices and decisions?

What to focus on

You should continue to specialize, and work on understanding how to build something front to back in your area of specialization.
Work on communicating about your area of specialization. Participate in discussion, debate, and figuring out the right approach. Perhaps start writing blog posts focused on this area, or participating in tech talks.
Start learning a bit about the systems your specialization interacts with. You probably don’t need to fully understand them yet, but you should be aware of what they are and how they interact with your domain.

Resource Recommendations

Senior Engineer

This is when you first really start having to branch out beyond your “bread and butter” areas. This includes getting comfortable in other parts of the tech stack and may start touching on things that are not purely technical.

Many engineers stay at essentially this level, and that’s okay. Going up beyond this involves more and more of your job being outside the code.

Characteristics:

Typically 5+ years of development experience
Starting to take on “tech lead” responsibilities of keeping things moving
Typically own entire services or large tech components.
Mentor junior engineers, give feedback in code reviews
Work to set & maintain standards and processes
Understand the relevance of their “owned” services/components to the business
Communicates effectively with designers, product managers, etc.
Communicates technical decisions & concepts internally and externally with documentation, blog posts, tech talks, etc.

Milestone questions to ask as you advance within this tier:

Do you own the development of an entire service or large component front to back?
Are you regularly giving feedback to junior engineers, both in code reviews and outside of them?
Are you involved in setting standards (e.g. code quality) and processes (e.g. scrum) for your team

What to focus on

Practice your verbal and written communication skills. You should be able to clearly present your points of view in either prepared or impromptu scenarios.
Learn about the way all of the different systems in your software work and interact. You should now not only be an expert in your specialty but have a solid understanding of how the entire system works.
Get comfortable having 1 on 1 conversations with other engineers, giving helpful feedback, and guidance.
Start understanding the business implications of technical decisions. How does your company actually benefit or make money from your software? What parts are important to the business and which parts don’t matter as much to them?

Resource Recommendations

Lead Engineer

Sometimes called “tech lead”, this one of the most challenging transition points in the industry because you’re still deeply involved in the tech stack, but your primary responsibilities and focus suddenly have to expand to include a ton of human questions.

Characteristics:

Typically 8+ years of development experience. Some orgs have this as “parallel” or “orthogonal” to pure dev track (e.g. https://docs.google.com/spreadsheets/d/1k4sO6pyCl\_YYnf0PAXSBcX776rNcTjSOqDxZ5SDty-4/edit#gid=0 from Rent the Runway) but even there expectation is to keep going on eng track you’ll work as lead sometimes.
Engage in technical project management
Delegates tasks and projects to others.
Understand motivations & career goals of their team
Give regular feedback to team members on growth, progression towards goals, areas for improvement, and praise
Leads via influence rather than having direct reports
Proactive in identifying and clearing roadblocks for the team.
Typically coding much less. Some organizations just enough to keep familiar with codebase/hand in. Others only when it’s super high leverage to set example/clear roadblock.
Anticipate technical issues, manage risk, and communicate with stakeholders about these.
Fully understand the business value from your software & impact on customer.

Milestone questions to ask as you advance within this tier:

Do you help translate business and product needs into technical architecture for your team?
Do you communicate updates and roadblocks to stakeholders outside of your team?
Do you lead discussions and make decisions on standards and processes for your team?
Do you give regular feedback and mentorship to your team members?
Do you understand what types of tasks and projects are exciting for each of your team members?
Do you help determine who on your team does what work, either by facilitating or directly delegating and assigning work?

What to focus on

Learn to lead/manage a meeting.
Learn how to work productively with stakeholders. Understand their goals and how to translate engineering concepts for them.
Learn how architectural decisions impact business outcomes. Work to understand when technical debt can be useful to incur, and when it starts to become a problem.
Learn how to lead others to learn, grow, and make good decisions by framing situations and asking questions.
Measure your impact by the influence of your actions rather than the code you write.
Learn to manage your own emotional state - when others look to you as a leader, your words & actions have an outsized impact.

Resources

Principle/Distinguished Engineer

These are industry leaders. Some companies create even more levels beyond this, “fellow”, etc, but however you break it down these are people who are movers and shakers in the industry as a whole. Many will never get here, and that’s okay!

Characteristics:

Typically 12-15+ years of experience
Setting technical direction for the entire organization
Identifying strategic technological growth opportunities
Develop & communicate multi-year technical strategy
Act as multiplier building systems, tools, and policies/patterns
Wide industry recognition, participation in industry conversations & moving forward state of the art
Has thorough understanding of the entire business and how different domains contribute to overall business strategy
Facilitates organization-wide discussions
Anticipates technical problems that will fall out of major projects, and designs solutions to overcome those problems

Milestone questions to ask as you advance within this tier:

Are you looking at technology trends and which are relevant and important to your business?
Are you setting technology direction for your company or organization?
Are you putting together multi-year technology roadmaps?
Are you involved with industry state-of-the-art conversations via groups like standards bodies?
Are you leading conversations about architectural and technology decision tradeoffs and their impact on business domains across the organization?
Do you anticipate likely technical problems from major projects while those projects are still in the planning phase?

Management Track

Engineering Manager

Okay, this is the lowest level on the management track, and often a point of bifurcation where you decide if you’re going to climb the management track or stay in the technical/individual contributor lane. For a thoughtful piece on thinking about / dealing with this “Multi-lane” approach check out Engineering Management: The Pendulum or the Ladder

Characteristics:

Typically 8+ years of experience
Typically responsible for a team of up to 15 or 20 engineers
Sets clear expectations for team members. Solicits, synthesizes, and delivers feedback.
Focused on building relationships, both within the team and across teams
Coaches their team members to help them continuously improve and do great work.
Works with team members to resolve in-team disputes.
Identify and work with team members to remedy problematic behavior
Communicates timeline, scope, and technical concerns to stakeholders
Often lead recruiting for their team, or work with HR & Staffing managers to handle recruiting
Represent their reports during performance & compensation reviews & negotiations
Works with product managers & their technical team to manage scope and deliverables
Typically not writing code, but may occasionally contribute bug fixes to “keep hand in”, but not in mission or time-critical areas.
Much of your schedule will be in “manager” mode - dominated by meetings, 1 on 1s, and planning sessions. You will have few large uninterrupted blocks of time.
“Engineering how people will engineer products”

Milestone questions to ask as you advance within this tier:

Are you setting clear priorities and expectations for your team members?
Do you have a clear idea of what each of your team members is trying to accomplish in their career?
Are you keeping close track of your team’s deliverables and scope, communicating up when there are changes?
Are you helping your team members achieve their learning, career, and salary goals?
Are you pro-actively identifying and remedying problems and disputes before they get out of hand?

What to focus on:

Master conflict management and resolution.
Work on your coaching skills. Learn to get comfortable asking questions instead of giving answers.
Practice identifying and addressing bottlenecks in your team and companies process
Continually improve your ability to set clear expectations and deliver actionable feedback.
Improve your ability to communicate timelines, scopes, and risks “up” to higher level managers and “laterally” to other teams and stakeholders

Resources

Director of Engineering

At this level you’re well and truly into management, where much of your time is spent managing managers & balancing/coordinating resources across teams.

Characteristics:

Typically 12+ years of experience, with 4+ in management
Typically responsible for multiple teams, or a team that is breaking new ground
Collaborating with engineering leads and managers to facilitate and drive technical roadmaps & vision
Responsible for identifying and cultivating leadership at all levels of their teams, particularly managers and senior engineers
Ensures their organization has appropriately high technical competence
Often driving staffing and budget planning for their area of ownership
Work on how to structure teams and inter-team relationships to maximise for business priorities
Owns priority setting and review process for teams under their oversight
As needed manages vendor and external relationships for their organization
Collaborates across teams and disciplines to solve problems and resolve technical debates
Typically not writing any code.
Essentially all of your schedule will be in “manager” mode - dominated by meetings, 1 on 1s, and planning sessions. You will rarely have any large uninterrupted blocks of time.
Typically contributing to technical architecture by serving as technically savvy voice asking business & product questions to engineers.

Milestone questions to ask as you advance within this tier:

Are you continually working to delegate more and more things to your team, and building their skills to handle that delegation?
Are your teams learning how to operate independently?
Are you capable of setting realistic expectations for your managers while still maintaining positivity about their requests?
Are you tracking ‘health signals’ appropriate to your team, such as frequency of releases, frequency of incidents, and related?

VP of Engineering

Often the top “People manager” in an engineering organization, collaborating with a CTO who is more technically focused

Characteristics:

Typically 15+ years of experience
Focused on debugging organizations and processes
Often responsible for determining technical priorities across the entire company
Works with CTO, product leads, and other stakeholders to translate strategic vision into technology roadmap
Coaches new directors and senior engineering managers
Plans headcount for the entire engineering organization and works with directors to allocate across teams

CTO

The very top technical person in the company. Handled very differently across different companies but often focused on the future technology of the organization, not the day-to-day operations of the tech team (which is more the VP of Engineering’s responsibility).

Characteristics:

Typically focused on the technical strategy for the entire company
Rarely has direct people-manager roles but often works with VP Eng and others to lead engineering organization
Responsible for setting & communicating vision for company with regards to technology
Identifies business growth opportunities enabled by technology and executes on those opportunities
Ensures the architecture being implemented can support a multitude of future business possibilities.

If frontend development is something you care about, you might also be interested in my weekly newsletter the Friday Frontend. Every Friday I send out 15 links to the best articles, tutorials, and announcements in CSS/SCSS, JavaScript, and assorted other awesome Front-end News. Sign up here: https://zendev.com/friday-frontend.html

If, on the other hand, you’re more interested in the leadership and communication skills that start to become relevant from Senior Engineer and up, you might like my latest project SpeakWriteListen.com where I help engineers become leaders by improving their communication skills. Check it out!

Friday Frontend: Handling Shared State Edition

Kevin Ball — Fri, 01 Nov 2019 07:00:00 +0000

Happy Halloween! Hope you’re enjoying the holiday and fall weather, and not too many of you are evacuated or breathing smoke from fires out here in California.

This week, what stood out to me was a couple of great in-depth articles on how to handle the challenges of shared state. Both of those are down in the JavaScript section. I also got a kick out of the ‘random numbers in CSS’ article, and loved the historical exploration of grids.

Have a great weekend! Enjoy!

Best,

KBall from ZenDev

CSS & SCSS

The two-value syntax of the CSS Display property

Super interesting look at new functionality in the CSS spec when it comes to the display property. Shows how specifications themselves can be refactored as we learn - in this case the flexbox and grid specs highlighted that the way we were thinking about display was incomplete, which was fudged around at the time but is now being taken fully into account in the new specification.

Are There Random Numbers in CSS?

While I’m not sure if there are any practical applications for it, this was a delightful exploration of how to create pseudo-random outcomes (e.g. simulate dice-rolling) purely with CSS, for things like pure HTML/CSS games.

Bidirectional horizontal rules in CSS

Creating layouts that work both in languages that are RTL and LTR is a hugely challenging proposition. Most of us are used to using tricks like putting margin on 1 side of an element using margin-left, which doesn’t translate at all! But luckily we now have logical properties like margin-inline-end to use instead, which similar to flexbox let us define things in terms of the current direction, rather than by absolute direction. Love it!

8 state-of-the-art CSS features (and how to use them)

While none of these are likely to be completely new to you if you’ve been reading this newsletter for a while, this is still a nice roundup of some of the best new features in CSS over the last couple years.

Null variables in Sass

This is a cool, super simple way to create configurability without code bloat in CSS. Probably most useful for folks creating reusable frameworks and toolsets, rather than application focused CSS, but who knows maybe you’ll find a use for it there as well.

JavaScript

A Simple Explanation of JavaScript Closures

I’ve harped on the importance of understanding closures a few times, and it’s something that continues to be key in understanding JavaScript, especially as we adopt more and more functional patterns. I agree with the author’s description of this post: “While being used everywhere, closures are difficult to grasp. Closures, like recursion, require an “Aha!” moment. If you haven’t had your “Aha!” moment, then this post is for you.”

The problems of shared mutable state and how to avoid them

This is a super in-depth piece diving into the problems of sharing data between different parts of a JavaScript application and how to work around them. Dealing with shared state is a challenge I’ve seen bite particularly junior developers over and over again, and is something that even today after working in JavaScript for over a decade I still occasionally make mistakes with.

Encapsulation in JavaScript

A look at a different way to handle the problems of shared state - using encapsulation. This post dives into both the concept of encapsulation, its origins in object oriented programming, and the techniques available for implementing it in JavaScript.

Thought on Vue 3 Composition API - `reactive()` considered harmful

Interesting exploration into the Vue 3 Composition API. I haven’t used it enough yet to know if I agree with his conclusions about the right way to use it, but it’s a great look at some of the tradeoffs between different approaches.

Angular Architecture - Unofficial Docs

If you’re not in the Angular ecosystem, it can feel super intimidating to look at from the outside. There’s so many things! And ideas we don’t encounter in other JavaScript frameworks! How does it all work? This is a very nice quick introduction to the architecture of an Angular application, helping you see what is required and how it fits together.

Other Awesomeness

Stop Animations During Window Resizing

Nice, simple, reusable snippet of JS + CSS to stop all CSS-based animations whenever the window is resizing. Definitely reduces jank on animation-heavy pages.

History of grids: from the printing press to modern web design

Fascinating look at how grids have played out through history, looking at print, art, architecture, and more. If you haven’t been thinking about things visually for a long time (I haven’t!) it is fascinating to see how these grids have been present throughout our history, just out of sight.

Using the Platform

A bit of a meandering dive into the way the web evolves and continues to evolve through the standards process. This quote seems to capture so much of why the web is a uniquely powerful and challenging platform: “The web thrives on a healthy tension between stability and the chaos of experimentation. ”

If the code works, don't fix it... Or maybe do? When to refactor your code and when to leave it alone.

The questions raised in this article are super important to think about, particularly for newer developers who haven’t encountered them before. Engineers almost all start with a super-strong urge to refactor everything, especially as you’re learning fast, but while it is sometimes important it is often a waste. Of course if something is buggy you will want to fix it, but what about “working” code? The article sort of touches on this, but I like the framework of looking at working code along 2 dimensions: Rate of change and level of complexity/ugliness. If code is not being touched often and isn’t broken, it doesn’t matter if it is ugly or beautiful. If it’s being touched a lot, complexity/ugliness is slowing you down and it is much more likely to be a good candidate for refactoring.

There’s no server more secure than one that doesn’t exist (audio with transcript)

(Bias alert - this is an interview I did). This is a super fun conversation on the JSParty podcast diving deep into the JAMStack with one of the experts in the space, Phil Hawksworth of Netlify. Phil literally wrote the book on JAMStack, and in this interview we cover a wide range of topics including what the stack does well, how to think about it, what it doesn’t do well yet, and some sneak peeks at where things are going.

Happy Friday!

8 Key Communication Skills for Coders

Kevin Ball — Tue, 29 Oct 2019 08:38:00 +0000

Jerod, Feross, Divya and I recently had a conversation about communication skills for software developers on JSParty #93.

This is a topic that has come up a lot on JSParty, so it was great to do a whole episode focused on tips and best practices, and the results were too good to leave buried in a show transcript so I thought I'd pull them out into an article.

1. Comments should provide context for code.

Feross did a great job explaining this one:

You don’t want the comments to be at the same level as the code itself. Repeating the code obviously is not useful to anybody. But I think comments that are higher-level than the code can make sense, as well as ones that are lower-level than the code. What I mean by that is – like, higher-level than the code would be like explaining the motivation for the code, like why are we doing it this way, maybe what other approaches were tried, or what are we trying to accomplish at a high level here; it’s giving people context.

And then lower-level than the code can also make sense. I’ve seen comments like – say that you have a variable name that is not specifying the units. Maybe you’re getting an argument into a function and you don’t really know what are the units of this, or what are valid values, like “Can it be null? Can it be undefined?”, stuff like that. I would call that a comment that’s lower-level than the code; it tells you details that are not actually in the code itself.

2. Use documentation to explain the bigger picture

So often documentation is used only to create a 'reference' guide for developers, but while references can be useful this leaves new developers at a loss for the 'why' and 'how' to use your library.

Divya explained how Vue.js takes a different approach to their documentation:

The Vue docs were written in a way that was easily – it was almost like an introduction to Vue… So you could read the docs, and actually as you got to the end of it, understand exactly how things worked.

It was not necessarily the case where you have to read from cover-to-cover, but it was easy to pick up and then understand the flow of how everything works… Because the way that the documentation was organized kind of built on previous documentation. So as you’re jumping through, and if weren’t using it as a reference, you could easily jump from one piece to another and understand how exactly a specific function or a specific component would be architected, or Vue patterns etc. Which I think is really interesting, because that’s a very novel way of thinking about it, rather than thinking of documentation as like “Oh, I want to help a developer who’s working on this thing use this framework”, rather than “I wanna help them understand why they’re using this particular pattern.”

3. Prioritize and give weight to your feedback

It's not always clear how much weight to give to particular pieces of feedback, especially when you're getting a lot of it! How do you differentiate between "this is super important and you must fix it" as compared to "this is a minor nitpick, take it or leave it?"

Divya shared a powerful technique called a 'feedback ladder' that she uses at Netlify:

For example, if something needs to be changed within a PR, you would prefix it with “boulder.” I think there’s also “mountain”, and it means this huge, huge change, that needs a conversation… And then “boulder” is like “This is a change that you need to make before this PR is merged.”

And then I think there’s “pebble”, which is a tiny change, maybe a stylistic tweak… And I think “sand” is the smallest, which is often to your own discretion, “Do whatever you want. Take it or leave it” type feedback

This allows the person receiving the feedback to instantly know which pieces are most important and must be addressed and resolved, and which are simply stylistic preferences.

4. Create fast feedback loops with stakeholders

Many of us have had the experience of having a conversation, working on something for a week or two, and then coming back and hearing that what we've done is not what the stakeholder expected as well.

To prevent this problem, Jerod had a simple solution:

Well, faster feedback loops, for one. So don’t go work two weeks under an assumption, if you can. Get that four-hour session in and return back and say “Is this down the right path?” For example, I think that’s something that we’ve established as good - the faster your feedback loop to yourself, and then also to others who are gonna be using it, the less time you will waste on the wrong path.

5. Replay and summarize your understanding

Another key aspect to making sure you're on the same page with a stakeholder is to replay back what you think you understood so they can confirm it.

As I described in the podcast:

One thing that is kind of in that “Get it in writing” thing, but is kind of a variant on active listening, that I’ve used anyway, is when somebody is describing to me what they want, I will try to say back to them what I heard. But I will deliberately not repeat exactly what they said, because that makes sense to them. I’ll try to rephrase it in the way that I would think about it or approach it, and if they hear that and say “Yes, that is correct”, we at least have a better chance of both having the same mind frame on it… Whereas if I repeat back the exact language they said - or this is the challenge with getting it in writing… If I get them to write down exactly what they said, that still means the same to them, even if I’m interpreting it somewhere else. So make sure that we try that translation back and forth from your language to my language, and are in agreement that both of those languages seem to be saying the same thing.

6. Figure out the goals of the people you're talking to

People understand the world from their own perspectives, which means that in order to get them to hear, you need to understand where they are coming from.

Jerod highlights the most important way to find out someone's goals:

The way you find out is by asking questions. One of the keys to being a great communicator - we think about the output side of communication so much. “How do I write this? How do I say this? What hand signals do I provide?” But a lot of great communication is actually listening. You have to listen, and sometimes that requires practice and patience, and effort to say “I’m not listening, I’m actually just waiting for my turn to talk”, and so I’m missing out on all sorts of context that this person is providing to me, which I can then ingest and use to be a better communicator.

So listening is hard to do, especially in long form, especially when you just can’t wait to say that thing that you’ve been thinking about for this whole time… But if you don’t have the context of the person and if you can’t gauge their technical level, you ask them.

7. Get stakeholders on board by highlighting their own points

One of the most challenging things communicating with stakeholders can be pushing back effectively. And a key technique for doing this is using the stakeholder's own points and language to make your points.

Divya explains:

The other thing I really like about when you communicate with stakeholders - this has to do with active listening - is this way of attributing specific questions of feedback to people. So it’s similar to this replaying back a question, but it’s more like “To your point about this thing, this is what I see.” So it makes people feel heard, rather than like “I’m gonna come in as obviously the expert who knows more than you do, and tell you what exactly you need to do.” It’s identifying “You’re obviously the stakeholder and I’m building this thing for your use case, which means you’re obviously the expert, and I’m the architect/engineer who’s building stuff. So let me identify your problem.”

Essentially, just say that “Your problem is important” and how exactly you’re gonna solve it, and identifying – whenever you have those conversations to specific people, it makes it for a more fruitful discussion. And I think also in general people think well of you when you do that. I never realized how much of an impact that makes. I often just do it out of habit, because I’m like “Oh, to the point that you’re making about this, blah-blah-blah”, and they’re like “Oh, you really listened to what I was saying. You actually truly understand what I’m saying, and broke down and explained the problem and the solution so well.” Which I think is great, and it’s a wonderful way of communicating and making sure that someone feels heard.

8. Uncover users problems, gently discard their solutions

A key insight for communicating with listeners is to use the half-baked solutions they bring you to uncover their problems.

Jerod goes into more detail:

Users will often bring you a solution, when what they actually have is a problem, and they will describe it to you as a thing that you should do. Like, “Here’s what you should do” and it’s like “Move a thing” or “Change this…” And that can be helpful, it can be not helpful…

A lot of times their solutions are not good, but their problems are real, and good. If it’s their problem for you, and you’re on the business side of the software, so to speak, that’s good for you to fix that problem, because they are your customer and they are your user. So a skill to have as a coder who’s talking to users is the ability to translate their solution and to drill down with them. You don’t have to do this immediately when you hear the first sentence, but to work with them to figure out what it is that they’re trying to solve, because it’s a very real need there… And gracefully - in the case that their solution is often bad - gracefully discard the solution, and offer perhaps a more obvious or better solution, or maybe say “I’ll get back to you with options on ways of solving this…” But to be able to tease apart and find out what is the actual problem here – because they’re not gonna say “Hey, I’ve got this problem”, they’re gonna say “Hey, here’s what you should do. You should change this”, or “I have an idea for the website”, or whatever. And I was gonna say developers don’t do that as much, because they know, but no - we do that all the time; we just give you advice.

OK, that's my wrap-up. If you're interested in the people behind the tips, or want to dig deeper into these communication skills, you can listen to the entire episode right here 👇

Remember, people are human

JS Party

Your browser does not support the audio element.

1x initializing... ×

Like what you read? You might be interested in my daily communication tips. I send out a short email each weekday with communication tips, tactic, mental models, and ideas for improvement. No fluff, all focused on helping you improve. Sign up here: https://www.speakwritelisten.com/newsletter

Friday Frontend: Svelte is Making Waves Edition

Kevin Ball — Fri, 25 Oct 2019 07:00:00 +0000

Hope your week was amazing! Maybe it’s just because I’ve started working more with Svelte myself, but it seems like now everywhere I turn I’m seeing it come up. This week there’s 3 articles about it I’ve included, 1 in CSS and 2 in JavaScript. Definitely check those out.

Some other super fun articles, I love the 25 days of CSS animations, and RxDB looks like a fascinating possibility. There’s also some great looks at accessibility, both calling out challenges in development and walking through how to make a good accessible color scheme.

Have a great weekend! Enjoy!

Best,

KBall from ZenDev

CSS & SCSS

The `hidden` Attribute is Visibly Weak

Semantic HTML is great! Embracing semantics is wonderful! And what could be more semantic than using a hidden attribute so you could do things like <div hidden>Some hidden stuff!</div>... and yet. It’s extremely fragile, as outlined by this article, along with some suggestions for how to work around that fragility.

25 Days of CSS Animations: Teaching Myself CSS through Motion Design.

This article has the whole package. Compelling story, useful tips, lots of examples you can learn from, and last but not least EYE CANDY. Some very very neat animations!

Accessible Drop Caps

Great, digestible article on how to create accessible drop caps. The solution they came to is similar to a longer-form article I linked to in June, so if you want to go deeper into the challenges of setting up drop caps check that one out, but if you want a simple good answer without much fluff, this one is great.

The wondrous world of CSS counters

This is a delightfully whimsical and meandering look at CSS counters. I had no idea you could use them to generate different forms of counter styles (though in retrospect I shouldn’t be surprised, how else would you internationalize this?), and I love the entertainment value of using CSS to implement FizzBuzz.

Making Tables Responsive With Minimal CSS

Tables are a super useful tooling for displaying data, but they can have challenges on mobile. Those challenges can be overcome though, with the clever use of CSS! :) Take a look in this article.

What I Like About Writing Styles with Svelte

A look at how Svelte approaches CSS, and how it provides a nice middle ground between CSS-in-JS and vanilla CSS. It reminds me a lot of how Vue handles styles, and I like it. :D

JavaScript

JAMstack Tools and The Spectrum of Classification

I’m minorly obsessed with JAMstack at the moment, so it’s useful to see articles like this one spelling out what a lot of the options are. Is it a complete survey of everything available? No, and it doesn’t set out to be. But is it a good starter? Absolutely.

Observing Visibility in React

Nice look at how to use the IntersectionObserver API within a React component to keep track of what is and is not visible.

The Svelte Handbook

I’ve been greatly enjoying using Svelte recently, and highly recommend it as a new framework to learn. Svelte is taking the trend towards pre-compilation and pre-rendering to the extreme, with a 0-runtime framework that lets you have the convenience of a Vue or React but without shipping a runtime, because it all compiles down to vanilla JS.

Svelte vs React: First impressions

A rundown looking at basic ‘todo’ applications side by side, built with Svelte and React. Does a solid job of showing the tradeoffs involved.

Other Awesomeness

Why Are Accessible Websites so Hard to Build?

I super appreciate the point raised by this article. Accessibility feels hard because accessibility errors are currently invisible to most developers. JavaScript and CSS are both also hard, but because errors in them are immediately and incontrovertibly visible, we work hard to fix them. If we can use tooling to make accessibility issues as in-your-face as JS or CSS issues, we’ll quickly start building more accessible websites.

Designing accessible color systems

Fascinating in-depth look at what it takes to design a color system that is accessible “by default” and still looks good. This is a HARD topic, and I love the way the authors go deep on multiple factors looking at visual weight and clear differentiation, and how those interact with accessibility.

Can we please style the control?!

A look behind the covers of what the Web Incubator Community Group is working on to improve the web. Super interesting to see the data of complaints for form controls… I think I’ve hit almost all of these issues over time. :P

RxDB

Super interesting new database designed to let you subscribe to changes. If you’re creating reactive applications using a framework like Vue, React, Angular, or Svelte, this has the potential to let you hook into your database in a similar way to how you’d subscribe to changes in an in-client store like Redux or Vuex.