Writing

Let’s say you’re testing a function that: Does not accept callbacks (so you can’t use done as described previously) Is not async and doesn’t return a Promise Does not fire events or otherwise notify the outside world that something happened Does behave asynchronously, by e.g. calling external APIs or waiting on internal events Further, let’s … Continued

I’m in the process of learning Jest and doing my first TDD in Javascript. It’s hard! Jest is tough, even though it’s supposed to make JS testing a bit easier. Testing async code (literally, code that uses the async keyword), in particular, is tricky, especially when you have non-obvious calls to async functions.

Skillshare approached me recently to create a new class, after having seen my work on Codepen. They’re expanding their tech catalog pretty rapidly, so I’m sure I’m not the only developer they’ve contacted — but I still took it as a huge compliment. When we brainstormed ideas, Jessica from Skillshare suggested that, since my background … Continued

Part one of this series discussed the why; part two introduced our “legacy” application and got its basic functionality hammered out with surprisingly little hoopla; now we can add a little somethin’ extra to make it magical. ✨

Our latest deploy is missing some key features that were part of the spec:

• The “Reset” button doesn’t work, and
• We’re not saving the state of the modal anywhere locally so that it persists across page reloads.

So in Part Two, I lied: we’re not turning this guy into a component just yet! Let’s knock out the rest of our basic functionality first.

This is the second part in a series on modernizing your JavaScript incrementally, using Vue.js. Part one discusses why we might need to do this.

Shall we review?

• Pretend you have an old project that’s built with jQuery
• Your client’s needs have changed, and now they need advanced functionality that would be difficult to build with vanilla JavaScript and jQuery
• You decide to build the new functionality with Vue.js, ’cause it seems good

Our project will end up with some fancy functionality for surprisingly little trouble. But we’re not there yet! Let’s write some code.

Here’s a question for ya:

Do you need to be working with a blank slate to adopt a new front-end framework like React or Vue?

Many of the resources you’ll find about these technologies are written with the assumption that you’re starting a brand new project. While that’s helpful when you have the opportunity to start a project from scratch, the reality for most teams is a bit more complicated.

Here’s the reality for most of us:

• We have lots of old projects sitting around with aging jQuery scripts that handle form submissions, sliders, YouTube videos, etc.
• We want to learn new technologies and best practices, but our existing projects still need maintenance and new features
• It’s not really practical to revamp our existing toolchains/build processes on these old projects for the sake of modern JS
• Our customers’ needs and priorities change as our projects age, which sometimes means developing new features and functionality quickly

In that context, does it make sense to add modern frameworks to old projects, or should we just pile a few more noodles onto that delicious, delicious jQuery spaghetti? (Everybody does it, DON’T YOU ACT LIKE YOU DON’T. 🍝)

This is a question that only you can answer, as your users’ and clients’ needs are totally unique. But I’d argue that in some circumstances, it makes perfect sense to introduce a new framework like React or Vue, or any of the other super hip frameworks du jour, to an old project.

In fact, once you learn some basics, frameworks can help you get more work done at higher level of quality than if you’d piled on yet another jQuery plugin. (Side note: If we write jQuery spaghetti, what does that make jQuery plug-ins? jQuery meatballs? ¯\_(ツ)_/¯)

It might make sense to add a new framework into the mix as soon as your client requests any functionality that involves lots of state.

So how can we add new functionality based on new frameworks without breaking existing code, or otherwise making a mess of things?

For almost two years, I worked with an in-house team of smart, talented designers and marketers.

The quality and quantity of work these folks put out is impressive. In a high-pressure, high-production environment, they managed to knock design assets and concepts out of the park consistently, quarter after quarter.

But the marketing campaigns and associated designs all had one thing in common: Print. Catalog, signage, packaging, etc. Capital-P Print. Assets transferred to dead trees and delivered by real, human people.
In my time there, no fewer than four different designers and marketers asked me the same question:

How do I get into web design?

Some time in the summer of 2014, my old site and most other sites under my hosting account were hacked.

I don’t know when exactly it happened. I didn’t know until a client called me saying their site had been hacked. They would have missed it, too, except that they’re a financial advisor, and their customers had called them, worried that their financial information was compromised.