Reactive UI’s with VanillaJS – Part 2: Class Based Components

In Part 1, I went over various functional-style techniques for cleanly rendering HTML given some JavaScript data. We broke our UI up into component functions, each of which returned a chunk of markup as a function of some data. We then composed these into views that could be reconstructed from new data by making a single function call.

This is the bonus round. In this post, the aim will be to get as close as possible to full-blown, class-based React Component syntax, with VanillaJS (i.e. using native JavaScript with no libraries/frameworks). I want to make a disclaimer that some of the techniques here are not super practical, but I think they'll still make a fun and interesting exploration of how far JavaScript has come in recent years, and what exactly React does for us.


Managing State in CSS with Reusable JavaScript Functions – Part 2

In my previous article, which shall now retroactively be known as Managing State in CSS with Reusable JavaScript Functions - Part 1, we created a powerful reusable function which allows us to quickly add, remove and toggle stateful classes via click.

One of the reasons I wanted to share this approach was to see what kind of response it would generate. Since then I've received some interesting feedback from other developers, with some raising valid shortcomings about this approach that would have never otherwise occurred to me.

In this article, I'll be providing some solutions to these shortcomings, as well as baking in more features and general improvements to make our reusable function even more powerful.


Reactive UI’s with VanillaJS – Part 1: Pure Functional Style

Last month Chris Coyier wrote a post investigating the question, "When Does a Project Need React?" In other words, when do the benefits of using React (acting as a stand-in for data-driven web frameworks in general), rather than server-side templates and jQuery, outweigh the added complexity of setting up the requisite tooling, build process, dependencies, etc.? A week later, Sacha Greif wrote a counterpoint post arguing why you should always use such a framework for every type of web project. His points included future-proofing, simplified workflow from project to project (a single architecture; no need to keep up with multiple types of project structures), and improved user experience because of client-side re-rendering, even when the content doesn't change very often.

In this pair of posts, I delve into a middle ground: writing reactive-style UI's in plain old JavaScript - no frameworks, no preprocessors.


Simplifying CSS Cubes with Custom Properties

I know there are a ton of pure CSS cube tutorials out there. I've done a few myself. But for mid-2017, when CSS Custom Properties are supported in all major desktop browsers, they all feel... outdated and very WET. I thought I should do something to fix this problem, so this article was born. It's going to show you the most efficient path towards building a CSS cube that's possible today, while also explaining what common, but less than ideal cube coding patterns you should steer clear of. So let's get started!


When Does a Project Need React?

You know when a project needs HTML and CSS, because it's all of them. When you reach for JavaScript is fairly clear: when you need interactivity or some functionality that only JavaScript can provide. It used to be fairly clear when we reached for libraries. We reached for jQuery to help us simplify working with the DOM, Ajax, and handle cross-browser issues with JavaScript. We reached for underscore to give us helper functions that the JavaScript alone didn't have.

As the need for these libraries fades, and we see a massive rise in new frameworks, I'd argue it's not as clear when to reach for them. At what point do we need React?


ES6 modules support lands in browsers: is it time to rethink bundling?

Modules, as in, this kind of syntax right in JavaScript:

import { myCounter, someOtherThing } from 'utilities';

Which we'd normally use Webpack to bundle, but now is supported in Safari Technology Preview, Firefox Nightly (flag), and Edge.

It's designed to support progressive enhancement, as you can safely link to a bundled version and a non-bundled version without having browsers download both.

Stefan Judis shows:

<!-- in case ES6 modules are supported -->
<script src="app/index.js" type="module"></script>
<!-- in case ES6 modules aren't supported -->
<script src="dist/bundle.js" defer nomodule></script>

Not bundling means simpler build processes, which is great, but forgoing all the other cool stuff a tool like Webpack can do, like "tree shaking". Also, all those imports are individual HTTP requests, which may not be as big of a deal in HTTP/2, but still isn't great:

Khan Academy discovered the same thing a while ago when experimenting with HTTP/2. The idea of shipping smaller files is great to guarantee perfect cache hit ratios, but at the end, it's always a tradeoff and it's depending on several factors. For a large code base splitting the code into several chunks (a vendor and an app bundle) makes sense, but shipping thousands of tiny files that can't be compressed properly is not the right approach.

Preprocessing build steps are likely here to stay. Native tech can learn from them, but we might as well leverage what both are good at.

Debugging Tips and Tricks

Writing code is only one small piece of being a developer. In order to be efficient and capable at our jobs, we must also excel at debugging. When I dedicate some time to learning new debugging skills, I often find I can move much quicker, and add more value to the teams I work on. I have a few tips and tricks I rely on pretty heavily and found that I give the same advice again and again during workshops, so here's a compilation of some of them, as well as some from the community. We'll start with some core tenets and then drill down to more specific examples.


HTML APIs: What They Are And How To Design A Good One

Lea Verou writes about the design of HTML APIs and how we might write better documentation for web designers. An HTML API is term for a JavaScript library that is configured and controlled through HTML rather than through JavaScript. For example <div data-open-modal="#modal"></div> might tell a library that this element is in charge of opening a modal. There is no configuration or initting other than loading the library itself.

My favorite part of this piece is where Lea confronts what might generally be seen as a simple plug-n-play JavaScript library:

Even this tiny snippet of code requires people to understand object literals, arrays, variables, strings, how to get a reference to a DOM element, events, when the DOM is ready and much more. Things that seem trivial to programmers can be an uphill battle to HTML authors with no JavaScript knowledge

By giving folks an HTML API we can avoid potential headache.

...remember that many of these people do not speak any programming language, not just JavaScript. Do not talk about models, views, controllers or other software engineering concepts in text that you expect them to read and understand. All you will achieve is confusing them and turning them away.

Lea's made a collection of libraries that have HTML APIs.