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!
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.
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.
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!
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!
Performance as a Feature
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.
It may also mean that you consider Google AMP, Facebook Instant Articles, and/or Apple News if they make sense for your project.
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!
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.
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.
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.
Consider Exploring VueJS
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.
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.
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!