Published , updated · 5 min read · RSS Feed
Please consider 🎗 sponsoring me 🎗 to keep writing articles like this.
Frontend Dev Best Practices for 2017
If you’re a frontend web developer, here are some best practices you might consider exploring or adopting in 2017
With the new year beginning, it’s a good time to take a fresh look at things, and see if we can’t do a bit better.
What follows is a list of best practices, technologies, and methodologies that I think we as frontend web developers should be doing. Take ’em or leave ’em, or cherry-pick as desired!
Link One New Thing
For each new project that you do, instead of whipping out your boilerplate and firing it up, consider instead adopting one new thing.
Maybe there’s a technique you’ve read about that you’ve wanted to try. Or a new technology you’ve wanted to explore. While it’s tempting to just go with what we know, the technology world marches inexorably forward. If you don’t keep pace with it, you’ll fall behind, too.
So we don’t want that happening! Instead, pick just one new thing for every project, and give it a go. I personally have a list of technologies/methodologies/design patterns 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 little 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 yourself eager to try out a new piece of technology or methodology or design pattern, you may be in the wrong business. The tech world is difficult enough as it is, if you lack the passion for it, it’s going to be a tough row to hoe.
Link https & http2
Every new site you build should be running https and http2. Full stop.
For https, the time is now, and given that LetsEncrypt will give you a free certificate, there’s really no excuse not to do it. Google has long counted https as a ranking signal, meaning that websites running https will have a slight boost on the Search Engine Results Page (SERP).
Additionally, starting in January 2017, Google will begin a process of marking websites as non-secure in Chrome if they are not running https. So just do it.
It is also the time to be running http2 as well. The older http1.1 spec has been around since 1997. Though it has been revised several times since then, it’s getting a bit long in the tooth, and does not work well with the way modern websites 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 backwards compatible; it will degrade gracefully to http1.1 for older devices. It also works far better with high latency, lower bandwidth connections such as mobile devices, and offers better performance for everyone, regardless of the type of device.
Link No More Shared Hosting
With the rise of fantastic VPS services such as Linode, Digital Ocean, Vultr and others, there’s no reason to be using old-school shared hosting setups. You get a deterministic amount of CPU, storage, and bandwidth that is not impacted by anyone else’s website.
And you can very easily upgrade or downgrade that service as your needs change.
These services are all price-competitive with shared hosting, and the advantages 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 argument I hear for not using one of these excellent VPS services is that the client doesn’t want to manage their own server. That’s fine, they shouldn’t have to!
First of all, Linode offers managed hosting, but more importantly, if you use a provisioning service like Forge, ServerPilot.io, or CloudWays, they take care of installing critical updates for you.
They also take care of provisioning your server with a modern layer of tools & infrastructure. That means you get PHP7, NodeJS, Nginx — whatever you want. I can’t tell you how many times I’ve seen old-school shared hosting environments that lag significantly behind what is a modern stack these days.
If your current hosting provider doesn’t offer PHP7 or has shared hosting environments — switch! Check out the How Agencies & Freelancers Should Do Web Hosting article for more on this!
Link Performance as a Feature
I’ve focused quite a bit on website performance in my Creating Optimized Images in Craft CMS and A Pretty Website Isn’t Enough articles, because I think it’s important.
What I want you to be thinking about in 2017 is performance as a feature. That means that you understand and convey to your clients why performance is a critical part of their website, and as such should be rolled into the proposal as a first class bullet point: Performance 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 profile your website using performance tools such as Google PageSpeed Insights, WebPageTest.org, and GTmetrix.com as part of the development & QA process.
It may also mean that you consider Google AMP, Facebook Instant Articles, and/or Apple News if they make sense for your project.
Link Say Goodbye to Themes & Frameworks
Themes and Frameworks like Twitter Bootstrap, Foundation and Semantic-UI are fantastic for getting things up and running quickly — at least once you have learned them. They do require that you buy into their way of doing things, and spend the time learning them before they are useful.
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 looking into using Semantic-UI a bit ago, but the full size of the CSS was positively monstrous, even after it was minified and gzip’d. Like all of the frameworks, you can build only the components you need… but even so, just building a button resulted in 60k of CSS. For a button!
Needless to say, that exercise ended quickly. Instead what I do these days is I start out with just normalize.css and FlexboxGrid. Then I just add in whatever custom CSS is needed for the project.
The entire site.combined.min.css for this very website that you’re reading is 38k which includes normalize.css and FlexboxGrid… and that’s before being gzip’d.
I’m planning to explore Tachyons (sans grid) as a way to have a nice, lightweight base to start with in the future (it’s on my “One New Thing” list). I’m also planning to evaluate Bulma, which is a nice lightweight framework built on top of Flexbox, but I’m unlikely to go with YAF (Yet Another Framework).
I feel like this is a natural evolution of frontend web developers. I’ve talked with many people who started out writing their own CSS, then found & fell in love with one framework or another (and all the time they could save!), and then when the honeymoon was over, they went back to their own custom starter SASS for websites.
So something you might consider as well is cutting the cord from these larger frameworks, and allowing yourself some design & developmental freedom. Freedom to make something unique, instead of something cookie-cutter.
Link Use a Workflow Automation Tool
Web development is more about building a very focused custom application these days. As such, you really need a frontend workflow automation 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 personally use Gulp for most projects, but I’m certainly not married to it.
First you’ll need to set up a good package.json methodology as described in the A Better package.json for the Frontend article.
Then once you’ve set up a nice gulpfile.js (or whatever), you will find that the effort you put in upfront is definitely 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 daunting, there are plenty of starter scripts out there for each of the aforementioned automation tools. Some pain upfront, yes, but ultimately you’ll be far better off for it.
Link Consider Exploring VueJS
I’ve written about VueJS in the Using VueJS 2.0 with Craft CMS and Lazy Loading with the Element API & VueJS articles, so perhaps obviously I think it’s worth a look.
VueJS really does make building interfaces and interaction on the frontend fun again.
The thing I like about VueJS is that the learning curve isn’t too steep, and you can pick and choose what pieces you want to use. Want to just use it to augment 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 typically work on frontend website projects on our local machines, and then push them to staging or production as discussed in the Database & Asset Syncing Between Environments in Craft CMS article.
When I’m discussing local dev, I mean that you should be using some kind of layer on top of your actual computer. The reason is simple: we want to be able to create a local dev environment that matches our production environment as closely as possible, but also doesn’t impact the computer 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 working on a team, it will really help to have some layer of abstraction that you are all using. The way to minimize environmental-related errors is to standardize.
There are some great choices out there: Homestead, Valet, MAMP, WAMP, Docker, and so on. As with a number of things I’ve mentioned here, it matters less what you’re using, and just that you’re using one of the many tools available.
If you’re not currently using some kind of VM layer for local dev, make it a goal for 2017 to start using one.
Link Stay Inspired
I try to stay inspired by looking around at all of the cool things that people are doing with technology these days. While it can be overwhelming at times, it’s also wonderfully overwhelming. Things are progressing at such a fast pace with all of the open source projects and communities that are springing up — the results are pretty amazing.
There are a ton of other things I could mention here that merit a look in 2017, but I tried to touch upon the things I’ve seen frontend devs doing (or not doing), and focus on those.
I think the real take-away here is that the ever-moving bar of “best practices” focuses on two things:
- Allowing you to produce better quality work for your clients
- Allowing you to work more effectively & efficiently
These are universal goals that will never change, even if the route to get there seems to change every year. Keeping your head in the game is what will keep you on track.
Happy 2017 everyone!