Episode Transcript

Ethan:

Hi, this is a Responsive Web Design Podcast, where we interview the people who make responsive designs happen. I’m your host, Ethan Marcotte, and today I, in fact, happen to be your only host. Karen McGrane is out there saving the world today, which means that it’s twice as much fun for me. Because today I am pleased to be speaking with Chris Ferdinandi, who is here to talk to us a little bit about JavaScript that works everywhere. Chris, thanks so much for joining us.

Chris:

Thanks for having me, Ethan. I’m really glad to be here.

Ethan:

It’s great to have you on the show. So before we dive in, just to really quickly set the stage, earlier this year we did a series of spotlight episodes, where we interviewed designers, developers, and other front-end folks who are doing interesting work around responsive design, even though that might not be their primary focus. We just kinda wanted to hear what they’re thinking about and what they’re excited about.

And so, Chris and I started talking about some of the design challenges that he’s working on, and how JavaScript has become much more of a focus. We thought that might be a good topic for the show. So Chris, welcome, seriously. Why don’t you introduce yourself, tell us a little bit about what you do, and just kind of what’s on your mind these days.

Chris:

Absolutely, yeah. So I’m, I guess, originally an HR guy, and then a designer turned web developer, and I spend most of my time these days working on JavaScript-related projects. I’m also spending more and more of my time helping people who are new to web development learn how to use JavaScript, and really kind of help them get over a lot of kind of that feeling of complete overwhelmingness that seems to have emerged out of the modern web development process.

Ethan:

“Complete overwhelmingness” is maybe one of the best ways to sum up web design in 2017. I can definitely relate to that feeling.

Chris:

[laughs] Yeah.

Ethan:

Well, before we dive into the weeds, I’d love to hear more about that transition from HR to heavy front-end development. What was that path like? How did you actually start getting interested in front-end development?

Chris:

So, I actually had a human resources blog because my friends were so sick of hearing me rant about a lot of the stodgy old HR stuff that I thought everybody was doing wrong. So, I started writing about it, and I eventually hit a point where I was tired of working with whatever free WordPress themes I could find and I was too cheap to buy a really nice premium one. So, I wanted to start customizing it myself. Through just kind of googling a whole bunch of stuff and digging into Chris Coyier’s—I think it was like “Getting Started with WordPress Theming,” or he had some kind of like three-part series on that, that was kind of my first foray into web development. It was one of those things where the more I did it, the more I found it more interesting than the HR work. At some point, about four years ago I decided I just didn’t want to do HR anymore, and kind of made the jump over, which was a weird and interesting process.

In human resources, my focus was on teaching engineers how to do career-related stuff. So, I kind of took some of the stuff I was used to teaching those folks and applied it to my own career hunt. But yeah, it was one of those things where it was just a lot of hours of writing really terrible code and then writing it over and over and over again until it worked.

Ethan:

That’s great. I’m still writing plenty of terrible code these days.

Chris:

Aren’t we all. [laughs]

Ethan:

I guess so. [laughs] I’d love to hear a little bit more of how that feeling of overwhelmingness crops up in your work. Was that something that you had to deal with when you started getting your hands on front-end development? What kind of strategies do you put in place to deal with that?

Chris:

It was actually easier when I learned, too, because you didn’t have these kind of ridiculous tool stacks that seem to be the norm now. Back then, the most complicated thing you were really doing was maybe adding jQuery to your site before you started writing. I think for me, one of the toughest things, I found, was going from the CSS/HTML world to JavaScript. Which is not to say that CSS is easier than JavaScript, because it’s not. I think if you look at some of the people who do really intense stuff with CSS, it’s amazing how much you need to know.

But I often liken it to like skiing vs. snowboarding, and I’ve learned how to do both. With skiing, the fundamentals are just a little bit easier to pick up because you’ve got two legs, they’re pointed forward, you’re facing a normal, natural position… But once you get past that kind of really initial stuff, like mastering skiing you can spend your whole lifetime doing. Whereas with snowboarding, you spend the first three days just falling and you come out black and blue, and then once you get past the basics, you can start to kind of master your skills a lot more quickly.

And that, to me, feels a lot like what JavaScript is like. A lot of the nomenclature and the way you kind of do things in JavaScript I think are not as “plain English” as things in CSS might be, where if you want to change the background color on an object, you use “background color” and then specify the color. Or if you want to adding some padding or margin, you just apply “padding” or “margin.” Whereas in JavaScript, you have all these things like trim and RegEx and query selector, and you kind of start scratching your head around what these terms mean. So, from a basic level, that piece is kind of overwhelming.

I also dealt a little bit with imposter syndrome. Or, not even really imposter syndrome, because at that point I didn’t feel like an imposter—I literally didn’t know anything and I was learning. But there was this belief that a lot of people who do web development have these computer science degrees, and I’m just this HR guy trying to break into a field that I don’t necessarily deserve to be in because I didn’t pay my dues and go to school. And then I eventually learned that most front-end developers that I look up to don’t have degrees in computer science or some related field either, and they all kind of taught themselves. Once I kind of wrapped my head around that, I started to feel a lot better about the whole thing.

Ethan:

That’s awesome. So you mentioned earlier that a large part of your practice is working with other people and teaching them some skills for getting into JavaScript. How do you work with them to kind of get past that “snowboarding hump,” where they’re not just throwing themselves at the wall but they actually feel like they’re making progress?

Chris:

Yeah, so I guess it’s two parts. So, the first is, hands down, the best way to get better at coding is to write code. But there’s kind of that weird thing that happens, where you want to do maybe project-based learning with someone, but if they know nothing, you can’t just throw them at a problem and be like, “Figure out how to solve this.” It just doesn’t work. So, for kind of an initial pass, I like to give people just enough background fundamentals where they know what they’re doing, and then guide them through a project. So, “Hey, let’s take these four things we learned and actually build something that works.” So, I like to say that within twenty or thirty minutes I can have you, from knowing absolutely nothing, to building your first working little micro plugin, and I usually start with something super simple, like an expand and collapse widget, where you click a link to show more and then you click it again to hide that text, or something like that. Just getting people writing something that actually works does wonders for making them realize, “Oh yeah, I can actually do this. This is not as difficult or as intimidating as I thought.” I’ve had pretty good luck with that and my students seem to enjoy it, as well.

Ethan:

That’s very cool. When you’re starting somebody off, are you usually working with vanilla JavaScript? Are you working with a framework? What kind of environment are you usually talking about?

Chris:

I personally am all in on just plain vanilla JavaScript. I personally learned how to code with jQuery first and then migrated over. One of the reasons I tend to avoid the frameworks—well, I guess there’s two reasons. For one, I feel like when you know kind of the root-level fundamental JavaScript stuff, you can go learn any framework you want a lot more easily than if you learn in one framework and then kind of have to mentally shift from the conventions of that framework into another. Knowing the conventions of different frameworks can be really useful, but without kind of that fundamental knowledge it becomes more difficult to pick up each one.

The second thing is a lot of today’s frameworks are just really overdone, overcomplicated; they’re really bloated, they require you to use all of these ancillary tools. So, React, for example, I think is awesome, but to really get the most out of it, you have to use pre-compilers and you often have to feed it through something like Babel. And then now you’re taking a beginner from, “Okay, open up a text editor and browser,” to, “Open up a text editor, a browser, a terminal window, which, by the way, you’ve probably never worked in before, run these commands in some weird language you’ve never worked with before…” It just becomes really, really overcomplicated, and it results in web pages that are more bloated, slower, that tend to be a lot more fragile and break more easily. So, for all those reasons and more, I tend to shy away from frameworks whenever possible.

Ethan:

That’s interesting. You mentioned fragility and I’d love to hear a little bit more about that, because that’s obviously a big concern for a lot of folks that I talk to and work with, because it’s one thing to build a beautiful, flexible, responsive website, but if it’s taking twenty-eight minutes for first render on a 3G connection and a four-year-old phone, maybe there’s something that needs to be reinvestigated there. So, talk to me a little bit more about fragility. How do you talk about that?

Chris:

Yeah, so it manifests in a few different ways. So, part of it is what you just referred to: it’s kind of that slowness, where the more code you load and the more kind of abstraction you’re running it through, the slower everything becomes.

But I think for me, the even more fundamental aspect here is that JavaScript does not fail gracefully the way HTML and CSS do. So in HTML, if the browser runs into a tag or an attribute that it doesn’t understand, it just skips it and keeps going. In CSS, if the browser runs across a property that it doesn’t understand, or a value for that property that doesn’t make sense, it just keeps it and keeps going. In JavaScript, if you run into an error, everything dies. Like, it just fails catastrophically, and then oftentimes any other code you have coming after that, or other files that have other code in them also won’t work, too. And if you have a website where you’re going to load an empty HTML file and then pull everything with JavaScript, you’re going to expose someone to, in a worst-case scenario, a loading icon that never stops or an empty white screen. Best-case scenario, you’re going to get half of your stuff rendered and then you’re going to have a whole bunch of broken stuff that doesn’t work.

Even with more basic kind of JavaScript-lite sites that are still serving up traditional HTML and they’re just sprinkling some JavaScript, a lot of the time you’ll see things like modal windows that don’t open. So, the link says, “Click here for more,” and you click it and nothing happens, or like a, “View details” link to expand out some additional text that does nothing. Or today where everybody, myself included, are using Stripe, which requires JavaScript, you go to a checkout page and you can’t actually give a company your money because a file didn’t load or somebody missed a semicolon somewhere and something broke. Those are problems that are easier to avoid than I think most people realize, and they’re just obnoxious problems. Like, someone’s here, they want to give you their money, they’re not working on a perfect connection or the most recent device, and they can’t because of how you chose to configure your site.

So, that’s kind of the thing is really like my mission to fight back against, is I love JavaScript, I work with it all the time, but we use it for tons of things that are better served by just traditional HTML, or CSS, or both. Even when JavaScript is appropriate, we use it in ways that make it way more fragile than it has to be.

Ethan:

So, tell me a little bit more about how you actually help people avoid some of these problems, because I think everything you’re saying is right on. You’re sort of hitting on this—I think our industry tends to be very optimistic about how and where our websites tend to be accessed. We sort of assume ideal network connections, recent hardware… But that obviously doesn’t always play out in the real world. What kind of strategies or practices do you help clients put in place to deal with that?

Chris:

The first part is, for me, I have this philosophy of using as little JavaScript as possible, which seems counterintuitive given that my whole profession is centered around JavaScript. For example, I was just working with someone who has a webpage that they’re loading a bunch of stuff further down the page with some AJAX calls, with JavaScript, because, as they put it, they wanted to just “get the content out in front of people as soon as possible and then progressively load the rest of the stuff in.” What ends up happening, though, is HTML is really cheap to load, and JavaScript and those async calls are not. So, their page actually feels slower than if they just loaded it the traditional way. It’s the kind of thing where, in their case, you could just do away with JavaScript all together. That’s a big one.

The other thing is not hiding content until the JavaScript loads. So, for example, you have one of those expand-and-collapse widgets. My kind of default tendency is to have all of that content that would normally be hidden behind “Click here to view more,” or, “Click here to show less,” just make that visible by default, and then once that JavaScript file loads and initializes and you know now that the person visiting your site has the JavaScript and it works, you can then hide your content and add in all your extra stuff. It’s progressive enhancement for JavaScript. Similarly, you also maybe want to make sure that the browser and device they’re using can handle the JavaScript that you’re using. I know everybody laughs, like, “Oh, who’s still using IE7 or IE8 these days? Upgrade. Browsers are free.” But I’ve worked in plenty of corporate environments where, for legacy reasons, that is the browser that people are allowed to use and they don’t allow you to install your own stuff on your computer, and they maybe have some ancient corporate software that only runs on this really old version of IE. So, making sure that not just the file has loaded but that the stuff that you’re going to be doing in that file is going to work in their browser before you kind of hide content or obfuscate anything…

And then nowadays there’s all these really weird considerations around things like touch and tap vs. click. So, you take a drop-down menu, for example, and how you want to expose the content behind that. Traditionally, you might show content on hover. But if I’m someone who’s navigating with a keyboard, there’s really no good way to detect hover with a keyboard, so you have to do kind of some additional things there, and sometimes that’s an experience that’s better enhanced, for accessibility reasons, with JavaScript. That’s all great, but then when someone’s on a touchscreen device, hovering isn’t always a thing you can do. Sometimes it is; you have these really weird kind of hybrid devices now where you can touch and use a mouse and a keyboard and things like that. So, maybe you also want to detect click events or tap events. And then you get into some weird other behaviors, where if someone clicks on something or taps on something, a lot of browsers will fire a click event and a tap event. So, if you’re detecting taps and clicks, you’re going to end up having two different events that fire twice and behave redundantly. So, there’s a whole bunch of these kind of weird, kind of both edge cases and then a lot of really easy big things.

Those are, for me, those big things. So, it’s using as little JavaScript as possible, making sure that you only hide content once you know that once the JavaScript that will allow someone to view it again has both loaded and is going to run successfully in their browser. And then there’s kind of these additional things you need to think through around how someone’s going to interact with it. Are they going to tap it? Are they going to click it? Are they going to hover over it? On which devices can they actually do those things? Are there certain devices where they can’t hover, or they can’t tap, or where they can actually do both, which was an edge case you never had to consider until like a year or three ago, where Microsoft is introducing all of these beautiful touch tablets and touch laptops and things now. Suddenly you need to consider all these weird input methods that you didn’t have to think about before.

Ethan:

Well-said. I mean, listening to you talk, I was reminded I’ve dealt with more than my fair share of touchscreens that only send mouse events, which is fun. I think there’s plenty of challenges out there. But hearing you talk about devices, I’d be curious, do you ever have to talk with clients about implementing device-testing strategies or helping them figure out how to navigate some of these challenges? Because I think that’s, at least for me, a big challenge for a lot of these organizations, where a lot of folks I work with, they’ve got their hardware, they’ve got their own phone in their pocket, and that’s sort of like their default testing device. How do you get them to look beyond that device and actually put in some strategies that actually match up with their audience?

Chris:

Yeah, it’s a challenge, for sure. When you say testing, do you mean within the code, or do you mean, for example, actually, “Let’s pull this site up on a device and see how it works”?

Ethan:

Well, I was thinking the latter, but dealer’s choice. I think either one is fine. Whatever you have more experience with.

Chris:

With that in mind, the one I have the most experience with is just kind of—and I’ve got to be honest, I actually don’t get a lot of resistance around wanting things to work more backwards compatibly. So, I don’t often have to have the argument of, “Let’s pull out a device that this is going to break in and see how it works.” Which is awesome for me—I know that not everybody has such a wonderful experience, so I’ve just been really lucky with some amazing clients. But one of the things that is often a concern for the people I work with, because in particular I work with a lot of freelancers who then go to work with clients, and so they need to have a lot of these conversations. So, it’s often things like, “I need this code to work back to IE9.” They have clients who want deep backwards compatibility, either just because they’ve been asking for that for five years and their audience may have moved on but they haven’t, or they’re dealing with corporate clients who, for legacy needs, have it. And so, folks want to get in on a lot of the newer JavaScript methods and browser APIs and things like that, but they’re not really sure how to make that work across a lot of older browsers.

So, that’s where a lot of the conversations that I have usually sit, and so that involves a couple of things. The first is before you run any piece of code, you should feature test it to make sure that the browser supports the things you’re trying to do, or the device. And this is a technique that I shamelessly stole from the BBC, they call it “Cutting the Mustard,” and then Brad Frost talked about it a whole bunch and it just really kind of super-resonated with me. Where you pick a handful of the most advanced features that you’re working with that serve as kind of a blanket test for all of the other stuff in your code. So, a couple of years ago this would have been things like EventListeners and querySelector, which allows you to find elements on a page based on any valid CSS selector. And depending on what you’re trying to do, you might also look for things like browser storage. And so you check that the browser supports those things, and if it does you can safely assume it also works with all of the older kind of methods and approaches you’re using as well. So if it passes that test, you load your code and run it, and if it doesn’t, you don’t.

So, that’s one aspect, and I actually take that a step further. So, for a long time I would use a test like that to say, “Okay, the browser failed. Don’t run this code.” But The Filament Group, right up here in Massachusetts, where Ethan, you and I are, they—for me, anyways—popularized a technique where I actually now check that a browser supports that stuff before I even load the JavaScript file at all. So, I’m using one of Filament Group’s great open source projects, LoadJS, and I will check that the device supports the things I’m going to do, and if it does I’ll use LoadJS to actually load my JavaScript file, and if not, I don’t even bother loading it. So if you’re on an older device, you’re saving yourself some kilobytes of code that you don’t need or aren’t going to use.

The second part, for me, is I use terminal and I run some kind of prebuild processes with my code, but I absolutely hate how many articles and tutorials and best practices seem to center around these complicated tool chains, where you need to install Node Package Manager, or NPM, and then install a whole bunch of dependencies, and you end up with like a hundred megabytes of dependencies on your computer so that you can build a ten to twenty-kilobyte JavaScript file of stuff. It feels absurd and it adds a lot of complexity to the process. And so for that reason, I tend not to use tools that convert some of these more cutting edge JavaScript methods into stuff that older browsers can run—and Babel is the one that most notably jumps to mind. Babel is kind of the tool that most people use if they want to convert the new modern stuff into backwards compatible stuff.

But I also don’t want to give up on older browsers. So, one of the things I’ve been using with a great deal of success for the last year or two is polyfills. Polyfill is a term that was coined by Remy Sharp to describe a snippet of code that bolts modern JavaScript functionality, or support for a modern JavaScript method or browser API, into an older browser that wouldn’t support it natively. For example, there’s some modern JavaScript methods that allow you to loop over an array of stuff the same way you might with jQuery’s foreach method, and they only work in newer browsers. But I like to provide support at least back to IE9, ideally even further back. With a polyfill, you can actually add support to some of those older browsers to do the same thing. So instead of having to use a traditional “for variable I=0…” just this really kind of verbose looping thing, you can use some of this newer stuff without having to bolt in a framework or run any kind of pre-compiling tools. It just makes the thing work in older browsers, which is great.

Actually, just in the last couple of months, I switched from manually including my own to this absolutely amazing tool, called Polyfill.io, that is a polyfill service. It was built by Jonathan Neal for Financial Times, and they open-sourced the project and made it available to anybody. It does this really cool thing where it will detect the browser you’re using and then send you a collection of polyfills tailored to your browser that include just what you need and nothing else. So if I’m on the latest version of Chrome, I get nothing. If I’m on Firefox or Safari, I may get a couple of things; there’s usually like about a half a kilobyte of stuff in there. And then if I’m on, for example IE7, I’m going to get about fifteen kilobytes worth of stuff after minifying it and Gzipping it. Which, compared to name your favorite framework, even the latest version of jQuery, which is a lot smaller than the older ones, that is substantially smaller and allows you to just kind of write all the native stuff and work in older browsers, all the way back to IE7, which is really, really amazing.

Ethan:

That’s awesome. You mentioned file size and transfer size a couple of times. I’d be curious to know how do you talk to clients about performance, and how does JavaScript factor into that?

Chris:

The easiest way to talk about performance is to show them how terrible their site’s performance is today. And for me, the tool of choice for that is WebPageTest, available for free at WebPageTest.org. So, you just pop in a URL, hit “run”—there’s a couple of settings you can configure if you want, but the out-of-the-box stuff works great; it just tests the cable connection. It spits out some interesting numbers, like time-to-first-byte, so how quickly you’re getting data back initially from the server, as well as how quickly the browser starts rendering content and when it’s done loading everything.

But the thing that I find most compelling about the whole thing is they have this really awesome screenshot view, where you can actually see, they take screenshots every one-hundred milliseconds, or a tenth of a second, where you can actually see how your page loaded in real time. It’s really enlightening, because most clients will visit their own site from like a T5 connection, or a really high-speed cable connection at work, with their browser having already cached all the files that load on the page. So, they just don’t notice how slow their site is, especially for a first-time visitor. Or the page is loading fonts that already exist on their computer, so they don’t notice that weird kind of waiting thing that happens when you’re waiting for the font files to load, and just all the weird performance stuff that happens.

So, when you show them in real time like, “Here we are at the four-second mark, and yeah, all the background colors and images are there but none of your text is visible, and all this content you’re loading it with JavaScript is just not there,” all of a sudden they realize, “Oh yeah, this is not ideal,” and it becomes much easier to have conversations around how you fix that. And then when I can actually show them before and after examples, often which can be done by just re-ordering the way stuff loads or kind of changing a few things, suddenly they become really receptive to anything else you want to suggest around performance after that.

Ethan:

That’s awesome. Well Chris, this has been a fantastic chat, but before I let you go, I would love to know if you happen to have any advice you’d like to share with our listeners. If somebody’s about to take on their first JavaScript-heavy responsive experience, what’s one or two things you’d like to share with them?

Chris:

My biggest advice for anybody who’s going to be embarking on their first JavaScript-heavy project for the first time is to remember that support is not the same as optimization. And because of that, first of all, you don’t have to make the site look the same or work the same in all browsers. I think the most important thing is that the content and the key activities that your users want to complete can be done in any browser or device, regardless of their capabilities. Because of that, I think it’s really important to make sure that even if JavaScript doesn’t load, the site should work, all of the content should still be available. If someone wants to complete a purchase, they should be able to do that without JavaScript. If they want to view some content or jump around on a page, that should all work without JavaScript. The best ways I can think of to do that are to make sure that you don’t hide content or gate any functionality behind JavaScript until after that file that powers it has loaded.

If you really want to maximize your reach, you should explore using polyfills. I think they’re absolutely amazing, they make the whole development process so much easier. If you haven’t checked out Polyfill.io yet, it’s a fantastic service that I can’t recommend enough.

Ethan:

Well Chris, this has been a really fantastic chat. I know I’ve walked away with more resources than I can throw a stick at, and I’m sure our listeners did, too. So, seriously, thank you so much for your time.

Chris:

Thanks for having me, Ethan. This was great.

Karen:

Thanks to everyone for listening to this episode of a responsive web design podcast.

If your company wants to go responsive but you need help getting started, we offer a two-day onsite workshop to help you make it happen. We also offer these workshops to the public, so please go to responsivewebdesign.com and see when we’ll be in a city near you.

If you want even more from us, you can sign up for our newsletter, subscribe to this podcast, and read full transcripts of every podcast episode at responsivewebdesign.com.

Thanks for listening, and we’ll be back next week.