Avoiding “Undefined is Not a Function” with Constants

How many times have you come across JavaScript’s “Undefined is not a function”? Too many. JavaScript is known for being so flexible that it’s easy to create unintentional bugs.

One way we can add structure to JavaScript code is to make a habit of using constants. Constants pair well in JavaScript with JS’s powerful object data structure, and they can prevent all kinds of problems, Read more on Avoiding “Undefined is Not a Function” with Constants…

Bye-Bye, Sinon – Hello, testdouble

UPDATE: Justin Searls, the author of testdouble.js sent me an email with some notes on this post.
I’ve added some his comments below to provide some additional context.

I’ve been working in JavaScript-land for the last little while, writing lots of Node.js code. Since I practice TDD, I’m always trying to keep my eye on the best new ways to test JavaScript code. Read more on Bye-Bye, Sinon – Hello, testdouble…

4 Types of APIs and When to Use Them

Most apps today draw a strong line between the server and the client. The client, maybe a single-page web application or a native mobile app, focuses on the user-facing features, while the server provides the data and a way to update it. Atomic has done a lot of projects this way, and we’ve found it’s a solid way to decouple the core business logic and database from different platforms.

Decoupling the client from the server means we can use an alternative back-end instead of the eventual production server. Several projects I’ve worked on have used this ability to keep development on the client moving forward, even though the actual production back-end wasn’t ready yet. Ryan wrote about the benefits of fake APIs like this a couple of years ago. But there’s more to swappable back-ends than fake APIs. Different situations call for different servers with different powers.
Read more on 4 Types of APIs and When to Use Them…

JavaScript Promises – How They’ll Work Someday

In my last two posts, I showed you how JavaScript Promises, an ES6 API that streamlines and simplifies asynchronous programming, work—and how they can break.

In this final post in the series, I will show you how you can reduce the pain of working with Promises using new JavaScript language features–if your target environment supports them. Read more on JavaScript Promises – How They’ll Work Someday…

JavaScript Promises – How They Break

In my previous post, I took you through an introduction and gave a peek under the hood for ES6 Promises, showing you how they work and how to use them. Today, I’m going to talk about how JavaScript Promises can break. Hopefully, this will equip you to track down Promise bugs in code that fails in mysterious ways. Read more on JavaScript Promises – How They Break…

JavaScript Promises – How They Work

JavaScript literally cannot do two things at once—it is single-threaded by design. To operate in the browser, where lots of tasks are going on concurrently at all times, it uses events. All you have to do is register an event handler that will execute when something interesting happens.

But the event model, while quick and easy for responding to things like user input, becomes unwieldy when chaining together sets of “do this, wait for that” tasks.

In ES6, we have a standard model for this: the Promise object. Read more on JavaScript Promises – How They Work…

How I Test CSS

At Atomic, we practice Test-Driven Development for all the code we can, from single functions to entire stacks. But there’s one kind of code we’ve long neglected testing: CSS. We rarely have coverage of it, and we often discover bugs and style regressions long after they were introduced. We’re not alone. Most software developers don’t do CSS testing. It’s tough to assert that a website looks the way you want.

I’ve wrestled with the problem of CSS testing for a long time, and I have two suggestions for catching style problems early. Read more on How I Test CSS…

Pitfalls to Avoid When Moving from Clojure to ClojureScript

I’ve been excited about ClojureScript, its community, and the new tools and libraries that have been appearing, but I’ve only recently started working with it. Using ClojureScript to power a web (or mobile) client to a Clojure backend service seems really compelling. It’d allow for easily sharing code or logic between the different components, as well as a well-designed implementation of modern UI development, via Om Next. It’s also a fun and enjoyable language.

However, while exploring ClojureScript, I’ve run into some areas that left me feeling frustrated. Read more on Pitfalls to Avoid When Moving from Clojure to ClojureScript…