I like to describe myself as a fullstack developer. I know that’s a very vague, slightly hand-wavey definition of the work I do and I also know that it’s a term that is becoming rather hard to define. For me, it specifies someone who has experience and is comfortable in working both frontend markup and scripting, as well as some kind of server side scripting and database management. For me, WordPress has ticked all of those boxes throughout my career and it’s a platform that is currently growing in some interesting ways, however I’m conscious that there are other technologies emerging that I need to emerse myself in. One of these I mentioned last week is CraftCMS, an incredibly flexible PHP based CMS solution that looks very much like a more open WordPress alternative. Another alternative for site building is the emerging JAMstack movement; I’ve finally dipped my toe in here and, I’ll tell you what – the water is super warm and inviting.
So what is the JAMstack? Well, there’s a whole host of info available on the great JAMstack.org website, but in a nutshell it’s about creating static pages using some form of site builder, so that you can deliver lightweight content to users without heavy server side lifting or database integration. Basically how I built websites when I started out in this game 15 years ago but without having to hand craft each page individually. The interesting thing about this whole movement is that the “stack” isn’t a rigid stack like, say, LAMP – JAM can be anything you as a developer needs it to be, so long as you can get good, servable markup out of the back end. There are some interesting standards for development and delivery emerging, however, such as using GitHub to serve pre-rendered code and having your hosting service pick up new commits, render them and host the markup in a creamy continuous integration kind of way. But at its core, a lot of what JAMstack is about is where I’ve been playing with Gulp for the last couple of years – streamlining workflows, improving reusability and simplifying deliverability.
I got started using the Gatsby site builder, mainly because my good friend Kieran was also tinkering with it. There’s a load of really good documentation on how to get things started on the Gatsby site but if you’re familiar with NPM/Gulp style workflows then you should be able to just jump on in. One of the first things that struck me about Gatsby is that it uses React for building its pages. I wrote a post just over a month back about my thoughts and resistances to front end frameworks such as React, but my main takeaway from it was that I really needed to have some kind of specific focus to understand why I would want to use one of them. Gatsby has given me that with React. Sure, it feels totally alien to someone who has worked for years with complete control over every element on the page to suddenly have to start focussing on distinct chunks of layout and content, but it only took a couple of hours to get my head into the flow and produce a site.
That site is called The Fantastic Site and is hosted on Netlify here. If you want to look at the development code that sits behind it, you can get to that on GitHub here. I like this method of deployment. I use GitHub for version control anyway so the act of signing up (for free!) to Netlify and connecting it to GitHub, pulling through the sites repository, pointing it to the public folder and telling it what command to run to build the site is just… well, gif in 3… 2… 1…
It is by far the easiest way I’ve ever had to deploy a site. Continuous integragion on Netlify’s end monitors the repository and pulls in any new commits to build. Using VSCode I can do all of this from one window. This is seriously going to change the way I approach developing simple sites.
That’s the caveat at the moment though – simple sites. The JAMstack concept is focussed on the front end experience, and there is an intersting array of CMS solutions around to help bring non-coders into the mix for content management, but what of ecommerce sites and other complex apps? I think there’s possibilities but having just scratched the surface I’m not sure what those look like so, time to dive deeper!
What I do like about JAMstack, though is that it doesn’t make me work in a way I’m uncomfortable with. It challenges me to think differently and be critical of my code and the way I string components together, which is always good! As developers we should be constantly striving to improve the work we do and build better standards for ourselves, lest we get complacent.
I do have a couple of concerns, though – with this approach will we lose some of the fundamental knowledge of how websites work? Of why the markup we’re writing matters and of the backend tech that’s in place to host the products we’re building? That’s probably my ingrained skepticism at work; I’ve never really trusted the idea of things like magic page builders in WordPress, for example, or tools that let novices “build a website in minutes” – what are these things doing behind the scenes?
There’s also the fact that Gatsby as an environment is, as with most NPM driven workflows, very plugin central! So far I’ve needed to install a new module to compile SCSS as well as a new module to add elements into the Head of my pages! To that end, the actual building process is massively developer focussed, but that’s something I love – the act of building, of refining and finally delivering while always questioning “Is there a better way of doing this?”
If you’re a web developer, either front or back end, I recommend you try putting something together using a JAMstack environment. It’s certainly an eye opener and it’s definitely something I’m going to be building on in the future!
As always, you know where the comments are! Shout up if you have any. 🙂