Andrew Welch · Insights · #frontend #craftcms #best-practices

Published , updated · 5 min read ·

Please consider 🎗 sponsoring me 🎗 to keep writing articles like this.

Frontend Dev Best Practices for 2017

If you’re a fron­tend web devel­op­er, here are some best prac­tices you might con­sid­er explor­ing or adopt­ing in 2017

With the new year begin­ning, it’s a good time to take a fresh look at things, and see if we can’t do a bit better.

What fol­lows is a list of best prac­tices, tech­nolo­gies, and method­olo­gies that I think we as fron­tend web devel­op­ers should be doing. Take em or leave em, or cher­ry-pick as desired!

Link One New Thing

For each new project that you do, instead of whip­ping out your boil­er­plate and fir­ing it up, con­sid­er instead adopt­ing one new thing.

Maybe there’s a tech­nique you’ve read about that you’ve want­ed to try. Or a new tech­nol­o­gy you’ve want­ed to explore. While it’s tempt­ing to just go with what we know, the tech­nol­o­gy world march­es inex­orably for­ward. If you don’t keep pace with it, you’ll fall behind, too.

So we don’t want that hap­pen­ing! Instead, pick just one new thing for every project, and give it a go. I per­son­al­ly have a list of technologies/​methodologies/​design pat­terns I want to try out, and I try to match what’s on that list with the next project to see what’s a good fit.

And then I do it.

While this can add a lit­tle bit to the time the project takes, it’s rarely as much as you might think.

The value you’re adding to the project will balance out the time it takes to learn the new best practice.

If you don’t find your­self eager to try out a new piece of tech­nol­o­gy or method­ol­o­gy or design pat­tern, you may be in the wrong busi­ness. The tech world is dif­fi­cult enough as it is, if you lack the pas­sion for it, it’s going to be a tough row to hoe.

Link https & http2

Every new site you build should be run­ning https and http2. Full stop. 

For https, the time is now, and giv­en that LetsEn­crypt will give you a free cer­tifi­cate, there’s real­ly no excuse not to do it. Google has long count­ed https as a rank­ing sig­nal, mean­ing that web­sites run­ning https will have a slight boost on the Search Engine Results Page (SERP).

Addi­tion­al­ly, start­ing in Jan­u­ary 2017, Google will begin a process of mark­ing web­sites as non-secure in Chrome if they are not run­ning https. So just do it.

It is also the time to be run­ning http2 as well. The old­er http1.1 spec has been around since 1997. Though it has been revised sev­er­al times since then, it’s get­ting a bit long in the tooth, and does not work well with the way mod­ern web­sites are designed and delivered.

There is zero reason to put up any new websites in 2017 that are not both https and http2. So let’s do it.

http2 is back­wards com­pat­i­ble; it will degrade grace­ful­ly to http1.1 for old­er devices. It also works far bet­ter with high laten­cy, low­er band­width con­nec­tions such as mobile devices, and offers bet­ter per­for­mance for every­one, regard­less of the type of device.

Link No More Shared Hosting

With the rise of fan­tas­tic VPS ser­vices such as Lin­ode, Dig­i­tal Ocean, Vul­tr and oth­ers, there’s no rea­son to be using old-school shared host­ing setups. You get a deter­min­is­tic amount of CPU, stor­age, and band­width that is not impact­ed by any­one else’s website.

And you can very eas­i­ly upgrade or down­grade that ser­vice as your needs change.

These ser­vices are all price-com­pet­i­tive with shared host­ing, and the advan­tages are legion. So cut the cord, and just stop using shared hosting.

The time you will save not having to wrangle with some weird GoDaddy shared hosting issue alone makes it worthwhile.

The biggest argu­ment I hear for not using one of these excel­lent VPS ser­vices is that the client does­n’t want to man­age their own serv­er. That’s fine, they should­n’t have to!

First of all, Lin­ode offers man­aged host­ing, but more impor­tant­ly, if you use a pro­vi­sion­ing ser­vice like Forge, Server​Pi​lot​.io, or Cloud­Ways, they take care of installing crit­i­cal updates for you.

They also take care of pro­vi­sion­ing your serv­er with a mod­ern lay­er of tools & infra­struc­ture. That means you get PHP7, Node­JS, Nginx — what­ev­er you want. I can’t tell you how many times I’ve seen old-school shared host­ing envi­ron­ments that lag sig­nif­i­cant­ly behind what is a mod­ern stack these days.

If your cur­rent host­ing provider does­n’t offer PHP7 or has shared host­ing envi­ron­ments — switch! Check out the How Agen­cies & Free­lancers Should Do Web Host­ing arti­cle for more on this!

Link Performance as a Feature

I’ve focused quite a bit on web­site per­for­mance in my Cre­at­ing Opti­mized Images in Craft CMS and A Pret­ty Web­site Isn’t Enough arti­cles, because I think it’s important.

What I want you to be think­ing about in 2017 is per­for­mance as a fea­ture. That means that you under­stand and con­vey to your clients why per­for­mance is a crit­i­cal part of their web­site, and as such should be rolled into the pro­pos­al as a first class bul­let point: Per­for­mance Optimization.

Impress upon them that best looking design & wittiest marketing message mean absolutely nothing if the user never sees it. The slower your website is, the more likely it is the user will not wait for it to load.

That means you will do things like pro­file your web­site using per­for­mance tools such as Google Page­Speed Insights, Web​PageTest​.org, and GTmetrix​.com as part of the devel­op­ment & QA process.

It also means you will be doing things like Crit­i­calC­SS, load your JavaScripts asyn­chro­nous­ly, use judi­cious caching, opti­mize your images, and oth­er per­for­mance-relat­ed methodologies.

It may also mean that you con­sid­er Google AMP, Face­book Instant Arti­cles, and/​or Apple News if they make sense for your project.

Link Say Goodbye to Themes & Frameworks

Themes and Frame­works like Twit­ter Boot­strap, Foun­da­tion and Seman­tic-UI are fan­tas­tic for get­ting things up and run­ning quick­ly — at least once you have learned them. They do require that you buy into their way of doing things, and spend the time learn­ing them before they are useful.

The pay­off is that you have a huge set of CSS and JavaScript that you can then use to build your web­site. The down­side is that you then have a huge set of CSS and JavaScript that you can then use to build your website.

Bloat is a huge problem with all of these frameworks. It’s not their fault, it’s just the nature of trying to provide a comprehensive framework.

I was look­ing into using Seman­tic-UI a bit ago, but the full size of the CSS was pos­i­tive­ly mon­strous, even after it was mini­fied and gzip’d. Like all of the frame­works, you can build only the com­po­nents you need… but even so, just build­ing a but­ton result­ed in 60k of CSS. For a button!

Need­less to say, that exer­cise end­ed quick­ly. Instead what I do these days is I start out with just normalize.css and Flexbox­Grid. Then I just add in what­ev­er cus­tom CSS is need­ed for the project.

The entire site.combined.min.css for this very web­site that you’re read­ing is 38k which includes normalize.css and Flexbox­Grid… and that’s before being gzip’d.

I’m plan­ning to explore Tachyons (sans grid) as a way to have a nice, light­weight base to start with in the future (it’s on my One New Thing” list). I’m also plan­ning to eval­u­ate Bul­ma, which is a nice light­weight frame­work built on top of Flexbox, but I’m unlike­ly to go with YAF (Yet Anoth­er Framework).

I feel like this is a nat­ur­al evo­lu­tion of fron­tend web devel­op­ers. I’ve talked with many peo­ple who start­ed out writ­ing their own CSS, then found & fell in love with one frame­work or anoth­er (and all the time they could save!), and then when the hon­ey­moon was over, they went back to their own cus­tom starter SASS for websites.

So some­thing you might con­sid­er as well is cut­ting the cord from these larg­er frame­works, and allow­ing your­self some design & devel­op­men­tal free­dom. Free­dom to make some­thing unique, instead of some­thing cookie-cutter.

Link Use a Workflow Automation Tool

Web devel­op­ment is more about build­ing a very focused cus­tom appli­ca­tion these days. As such, you real­ly need a fron­tend work­flow automa­tion tool if you’re going to keep your sanity.

Whether that means grunt or gulp or npm scripts is up to you. The real point is that you start using one. I per­son­al­ly use Gulp for most projects, but I’m cer­tain­ly not mar­ried to it.

First you’ll need to set up a good package.json method­ol­o­gy as described in the A Bet­ter package.json for the Fron­tend article.

Then once you’ve set up a nice gulpfile.js (or what­ev­er), you will find that the effort you put in upfront is def­i­nite­ly worth it.

You’ll be able to spend more time working on the actual website, and letting your workflow automation take care of the busywork.

While it may seem daunt­ing, there are plen­ty of starter scripts out there for each of the afore­men­tioned automa­tion tools. Some pain upfront, yes, but ulti­mate­ly you’ll be far bet­ter off for it.

Link Consider Exploring VueJS

I’ve writ­ten about Vue­JS in the Using Vue­JS 2.0 with Craft CMS and Lazy Load­ing with the Ele­ment API & Vue­JS arti­cles, so per­haps obvi­ous­ly I think it’s worth a look.

I real­ize that the JavaScript world seems like a whirl­wind of buzz­words and tech­nolo­gies (all at ver­sion 0.1.9!), but Vue­JS real­ly is worth a look from fron­tend web developers.

VueJS really does make building interfaces and interaction on the frontend fun again.

The thing I like about Vue­JS is that the learn­ing curve isn’t too steep, and you can pick and choose what pieces you want to use. Want to just use it to aug­ment your UX in places where you used to use jQuery? Fine! Want to build a full-on web app”? Fine!

Vue’s got your back.

Link Use A VM for Local Dev

We typ­i­cal­ly work on fron­tend web­site projects on our local machines, and then push them to stag­ing or pro­duc­tion as dis­cussed in the Data­base & Asset Sync­ing Between Envi­ron­ments in Craft CMS article.

When I’m dis­cussing local dev, I mean that you should be using some kind of lay­er on top of your actu­al com­put­er. The rea­son is sim­ple: we want to be able to cre­ate a local dev envi­ron­ment that match­es our pro­duc­tion envi­ron­ment as close­ly as pos­si­ble, but also does­n’t impact the com­put­er we work on.

It’s pretty awful if you screw up the computer you use for work while installing some piece of tech that you need for your current project.

Also if we’re work­ing on a team, it will real­ly help to have some lay­er of abstrac­tion that you are all using. The way to min­i­mize envi­ron­men­tal-relat­ed errors is to standardize.

There are some great choic­es out there: Home­stead, Valet, MAMP, WAMP, Dock­er, and so on. As with a num­ber of things I’ve men­tioned here, it mat­ters less what you’re using, and just that you’re using one of the many tools available.

If you’re not cur­rent­ly using some kind of VM lay­er for local dev, make it a goal for 2017 to start using one.

Link Stay Inspired

I try to stay inspired by look­ing around at all of the cool things that peo­ple are doing with tech­nol­o­gy these days. While it can be over­whelm­ing at times, it’s also won­der­ful­ly over­whelm­ing. Things are pro­gress­ing at such a fast pace with all of the open source projects and com­mu­ni­ties that are spring­ing up — the results are pret­ty amazing.

There are a ton of oth­er things I could men­tion here that mer­it a look in 2017, but I tried to touch upon the things I’ve seen fron­tend devs doing (or not doing), and focus on those.

I think the real take-away here is that the ever-mov­ing bar of best prac­tices” focus­es on two things:

  1. Allow­ing you to pro­duce bet­ter qual­i­ty work for your clients
  2. Allow­ing you to work more effec­tive­ly & efficiently

These are uni­ver­sal goals that will nev­er change, even if the route to get there seems to change every year. Keep­ing your head in the game is what will keep you on track.

Hap­py 2017 everyone!