Don't confuse Readability with Familiarity

A core tenant of writing maintainable code is to write "readable" code. But what does it mean for code to be readable? Can it be measured? Is it even objective? Why does more "readable" code always seem to mean more code? Longer names, more verbose patterns, less creative solutions, and so often "code a junior engineer can understand"? Let's explore this topic, challenge our assumptions, and get to the heart of what it really means to be "readable".

In Many Cases, Promises May Make For A Better Pattern Than async/await

Async/await may fit proceedural code patterns pretty well, but the Promise API enable functional patterns that are applicable far beyond promises. In fact, the Promise API offers a practical gateway to safer, cleaner, and more comprehensible code generally. Even when stuck in a procedural codebase, the Promise API can make for better patterns. Let's explore what this looks like in practice as we compare async/await patterns with the Promise API, and see what kind of other treasures it unlocks.

CSS actually IS AWESOME! And you can be too!

The memes are legion. What started as a humorous way of expressing frustration with the difficulty in doing seemingly simple layout things has turned into an axiom newer engineers unquestioningly accept, deterring them from going into depth on this beautiful, remarkable, resilient, exciting language. CSS is not what it was even 5 years ago. And it's about to get a whole lot better.

When Should the HTML table element be used for tabular data, and why is it never?

The HTML table element. In days past it was used as the primary means for controlling visual layout. Thankfully we put that to bed a long time ago*. Now we only use it when we want to display an actual table, like -Google Sheets-, -Number-, -Excel-, and -Notion- does. 😳

Well that's embarrassing, none of those use tables to display a table. In fact, perhaps HTML tables should be used at all. Perhaps HTML tables are actually deeply against the nature and grain of the web. If so, what do we do about it?

Understand More By Thinking Less

The key to creating applications and systems that can be fully understood and can scale over time and across engineers is to create applications and systems that engineers don't _need_ to be fully understood to be productive in.

Records & Tuples - How a slew of new JS features are going to radically change how we write our code

Records, Tuples, Change Array by Copy, Pipeline operator, Pattern Matching, Built In Modules, Temporal. Each of these proposals to the ECMAScript standard are super interesting on their own, but together, they represent a sea-change in how we can write JS to make things simpler, cleaner, safer, and more enjoyable. Come along on a journey of discovery through these features and more.

Monoidal Identity Elements, or, How to pick a default argument value

OMG, everyone! Destructuring and default values A.I.R.!!!

I love what has been happening to JavaScript over the last few years, and I imagine you do too. Two of the many wonderful additions to the language has been destructuring & default values. With those two things, we have been able to more clearly document function interfaces, aid linting and code completion tools and Leverage many of the features from tools like TypeScript, Flow, & Tern without necessarily buying into their entire ecosystem.

Perhaps it's not something that's been thought about too much, but what to choose for those default values? Would you believe that there's actually a strategy for choosing what value to use for a default value regardless of the particular use case?

Borrowing a wee bit from Category Theory, we can be confident in our default value choice and potentially eliminate a lot of guard clauses and existential checks.

Don't worry though, some of the words might be unfamiliar, but the concepts are actually pretty simple, and we will talk about them in plain language. You likely already understand most of these concepts intuitively but haven't had a name to give them, until now.

Data pipelines; A better way to write code.

Pipelines are a declarative pattern of programming where data is passed (or "piped") through a series of simple functions. There are numerous ways to go about it. Function composition, chaining, pipes, Promises, mapping, the pipe operator, and so many others. Pipelines allow us to define the complex in a simple way. We are going to explore what pipelines are, why they are useful, what are the mechanisms we can use in JavaScript to accomplish them and what to watch out for. We will be discussing this pattern in a way that is accessible to any level of programmer. It will be interactive and cover both practical application and theory.

You May Not Know It, But You Already Understand Monads.

Monads. That bit of cursed dark functional magic most developers don't understand, and the ones that do mysteriously lose the ability to explain it... Or so we've been told.

What if I told you, you already understand Monads? You've been using them for years. In fact, you very likely prefer them to other methods to accomplish the same kinds of things. Honestly, the worst part about Monads is the name -- let's be honest, it's a terrible name -- but apart from that, the concept is pretty cool!

Let's talk about Monads in JavaScript; what they are, what they're good for, how you're already using them, and how you can deliberately use them more often for profit AND fun. I PROMISE, you won't be scared of Monads after this.

The Miseducation of CSS

We use CSS to drive the presentation of our web experiences but all too often we hit a wall of complexity and maintainability much earlier than we had hoped. We use frameworks and opinions to try to mitigate and wrangle this complexity, but understanding why this happens can help prevent us from hitting that wall at all.

In reality, CSS addresses two very different concerns. One is decoration, the other is layout. Conflating these two concerns is the source of almost all our CSS woes. Understanding them is the path to transcendence.

JavaScript Classes are just Rube Goldberg Machines for Objects

The whole job of a class is to ultimately create an object. JavaScript has one of the simplest, most clear and succinct ways of creating an object literal. And a familiar, dead simple way to do it over and over again in a particular way. How does it stack up to what a class can do? Let's find out together.

This presentation is adapted from an article I wrote of the same name.

How To "Think in React" Today

It's 2023. When we first talked about how to "Think In React", class components with their lifecycle methods were the new hotness, and Redux was THE way to manage state. Lots have changed since then. Hooks are now old news. Sever components are the new hotness, and we _finally_ have "concurrent ~mode~ features". Whatever happened to uni-directional data flow and components as pure functions of props and state? Things sure seem to have gotten more complicated since those heady days. Surely it's time to update our mental model of React to reflect our current reality. Let's explore together what these new features mean for how we think about our React applications. What changes? What doesn't?

This presentation is loosely based on an article I wrote a few years ago called "Have we forgotten how to 'Think in React'? (https://365jsthings.tech/blog/have-we-forgotten-how-to-think-in-react). Although we harken back to some of the earlier days of React, this presentation is for all audiences and aims to distill React down to its vital essence. In doing so I hope to reinvigorate that sense many of us had when we first learned React as to the simplicity of the React model over so many others.