Development stacks. Not a remotely new concept but an everchanging one nonetheless.

It’s somewhat of an unwritten requirement that, as web developers, we keep up to date with the rapid evolution of the various technologies that make up the industry. And although I’m personally of the belief that this forced adherence to embracing change is ultimately a good thing, there are certainly arguments for both sides.

The rapid expansion and open-source nature of many of these tools means that the potential for what we can do in the browser is increasing exponentially. Not only that, but also the improved accessibility to these technologies means that the talent pool widens further, allowing to expand more and the cycle continues.

This is all well and good, however, there are some downsides to the ever-changing nature of this beast. Some technologies can end up becoming 'buzzword-ish', used by people hiring as a false yardstick for which to measure talent or suitability. And whilst the abundance of options for tools, frameworks, plug-ins and packages can be seen as a good thing, it can leave you feeling a little overwhelmed and wondering if you’re still relevant.

The languages and libraries we, as developers, choose to invest in often demand a substantial amount of time and energy before they’re able to be integrated into production projects. So if you’re in the market for a new framework and aren’t sure where to turn, here’s what we’ve found works best for us!

Setting the foundations

If it ain't broke, don’t fix it… right?!

Soon to be coming up on its eighth birthday, React is one of the most popular javascript libraries around for front-end development, and despite the lack of new features in its latest major release, React 17 promises major improvements to maintainability, boosting the longevity of your sites and saving you future headaches.

Its large userbase (Stack Overflow's Annual Developer Survey named it the second most popular web framework) means that there is a ton of knowledge already out there and if you happen to run into an issue, nine times out of ten, someone else has already had (and fixed) the same problem. What’s more, it’s large hook library and state management capabilities mean it’s just super easy to make it do what you want, which is all anyone can really ask for.

In short: React is tried and tested and for the types of sites that we build, it’s by far the most fit for purpose.

A match made in heaven

‘Oh, Gatsby… How do I love thee? Let me count the ways…’

*clears throat*

Sonnets aside, if React is our cake, then Gatsby is the icing. It just makes the whole experience — for the developer building the site and the end-user consuming it — much more enjoyable.

Being built on top of React, Gatsby.js, for us, is the perfect tool to take it that bit further; adding in a ton of powerful resources and integrations.

With performance at its core, building a static site with Gatsby is a walk in the park, and their huge library of both official and community-made plugins means you have access to tools like gatsby-image, allowing you to lazy load an entire srcSet of GraphQL queried images with just a few lines of code!

There solid and intuitive API twinned with an abundance of useful documentation means it’s super easy to do (or find out how to do) things like use node to create multiple pages from blog post or case study data, plus it’s super flexible in terms of CMS integration too (more on that later…).

Gatsby gang, keep doing what you’re doing — we love ya!

Looking the part

Of course, there’s no point in having a well-functioning, lightning-fast website if it doesn’t look good, right…? Cue Styled Components and Scss.

Whilst both of these are perfectly adequate (and in fact, very powerful) tools in their own right, testing with both has led me to prefer using them in conjunction rather than exclusively. They’re equally useful in isolation and simply serve different purposes when it comes to the development process.

I’m still not 100% certain that they’ll both be used here for good, but for now, this solution works quite nicely.

Styled Components allows us to create a series of reusable, styled React components (the clue’s in the name) each with multiple variants if necessary which are controlled by props. It’s a super easy system to get started with and really useful for creating the building blocks of your sites like sections and containers that you know are going to be reused.

I personally like it as it feels like a much cleaner solution than having reams of individual stylesheets and the components look aesthetically much neater than their JSX counterparts. Another bonus is that styling the components uses Scss syntax which is great for keeping things concise and preventing us from having to learn a whole new set of syntax.

Speaking of Scss, once the broader, lower-specificity, Styled Components have been created, all subsequent styles are handled using Scss stylesheets. Scss is an incredible addition to the way we write CSS thanks to things like its nesting abilities, @rules, maps, booleans, etc. I feel it’s a lot like a fusion of CSS and javascript and is really intuitive to write. There's a ton of good community resources out there offering functions and mixins which you can incorporate across your projects.

Scss is perfect for dealing with the higher-specificity cases that would be too convoluted for Styled Components to handle and also allows us to set up some global styles for things like typography and configs for colours and other variables.

Something in the way you move

Subtle animations are what makes a website sing and can be the thing to take a good project to a great one. Having said that, no animation should be used at the cost of overall site performance — after all, you user won't be there to even see the animations if they’re deterred from or unable to use your site.

For the majority of our animations, we use Framer Motion. It’s a fantastic tool that’s super easy to get to grips with and has a really active and engaging community, plus, it integrates seamlessly with our Styled Components (check out the snippet below if you're curious how!).

The defining feature of Framer Motion, in my opinion, has to be their AnimatePresence functionality which allows components to animate as they’re mounted and unmounted from the React tree.

This is great for efficiency as we’re actually removing things from the React tree rather than just hiding them with an opacity: 0, as well as things like SPA page transitions where we’re only removing certain content and keeping headers and footers, etc.

It is possible to rig Framer Motion up with IntersectionObserver in order to run animations as elements scroll into view but for those cases, I much prefer using GSAP. Although it means using an additional library, there are some things that GSAP really just excels in:

• Their ScrollTrigger plugin allows for super simple scroll based animations including things like scrubbing animations linked to scroll position.

• Their .scrollerProxy() method permits linking ScrollTrigger with third-party smooth scrolling libraries (or one of your own!)

• Their SplitText plugin is incredible for animating titles and paragraphs where the content per line may change depending on the device. Just link the animation with the target and it will wrap each line of text in an individual div (with a class of your choice if necessary).

Overall, whilst I’m yet to find a tool that does everything, these two work very nicely in tandem.

Losing your head isn’t such a bad thing

So you’ve got an epic looking and website, animating beautifully and functioning like a well-oiled machine… now all you need to fill it up with content!

Content management systems are not always a requirement, however, being able to alter and add to its content without having to go into the source code and then redeploy the entire site is rarely a bad thing.

The argument about which headless CMS is better has been fought amongst developers for years but due to its simplicity, customisation, feature-set and compatibility with the rest of the stack, we use Sanity.

I really like what the guys over there have done. Sanity is a perfect blend of high-grade functionality without feeling intimidating (for us or our clients!). The client portal is super easy to use and able to be customised and branded as much as you like.

The data is queried using GraphQL (or their own GROQ if you’re really adventurous) which integrates nicely with Gatsby and the freedom you have to manipulate the schema means you can essentially create a Gutenberg-style page builder of your own custom components!

(this may sound a little abstract at the moment but I want to cover the whole process in-depth in a future article… so try to just roll with it!)

I’m well aware of the other headless CMSs out there but have never really looked beyond their landing pages. Right now Sanity gives us everything we need so I can’t complain, however, I’d I’m always open to hearing arguments for why the alternatives may be better!

Honourable Mentions — You-Know-Who

Would an article on web development in 2020 be complete without talking about TypeScript?

Currently taking the world by storm and showing no signs of slowing down, TypeScript is Microsoft’s own super-set of javascript used to build robust components and help in preemptively catching errors (like you needed to be told). In fact, looking again at Stack Overflow’s Annual Developer Survey, TypeScript is ranked eighth in terms of most popular programming language amongst professional developers, now overtaking C and C++.

I made the switch from JS earlier this year and I can honestly say I’ve never looked back. Writing normal Javascript now just feels unsafe; I’ve become totally reliant on the safety net of TypeScript and it’s strictness.

I like that it yells at me for the smallest mistakes rather than letting hit Cmd+S and cross my fingers! It makes me feel much more confident in the code that I write.

Although it took a little while to learn and get used to, the benefits it offers and time it will save you, in the long run, are totally worth.

Being a somewhat ‘early adopter’ (I’m aware it’s over eight years old now but a lot of people are still yet to make the jump!) means there are certain caveats to using TypeScript, like packages you use not being typed. However, there are ever-expanding resources like DefinatelyTyped to help with that and I personally feel that the TypeScript world takeover is only just beginning and in time it may even replace javascript.

If you’re interested in taking the plunge with TS and are keen to find out more, I really recommend checking out this video in order to see some of the real-world benefits and how easy it is top get started.

Thanks

There you have it — a little look into the tools we use to make our sites and why we’re so fond of them.

Of course, there are plenty of smaller add-ons and plugins that get used on a more project-by-project basis, but these are the building blocks of most of what we do.

If you liked what you heard or had any suggestions for technologies we should be looking to include in the future, feel free to get in touch or shoot us a response — we’d love to hear from you!