Frontend frameworks are a bit like Hansel – they’re so hot right now. As someone who’s been wrangling web code for over 15 years (yeah, whatever, grandad…) I’m acutely aware that tech never ever stands still – there’s always a new way of doing things that either provides a timesaver, or makes your code more efficient, or means you don’t have to think about the tedious tasks all the time.

Gulp and Node.js have been the biggie for me of late and while I don’t profess to being utterly proficient at them, dropping them into my workflow has helped speed up my development process over the last year and opened me up to considering new technologies in my projects. You can read about some of my adventures on this site, starting here!

So now I’m turning my attention to frontend frameworks, something I’ve been meaning to do for some time now. Everywhere you look, someone is after a developer who knows Angular, or React, or Vue or some other esoteric Javascript madness that wholly changes the way you look at frontend development for better or worse. Look, when I started doing web development professionally I was coding raw HTML in notepad, doing everything by hand. It was a damn chore and yes, things have come a heck of a long way since those stoneage days but I can’t help but look at some of these frameworks and wonder – are we overthinking things?

That’s not to say I think they’re pointless and anyone who uses them is stupid; far from it – I was reading this article by Brian Barbour on Dev the other day, which I kind of agree with and kind of don’t. I think it’s absolutely important to understand what things like React, or Angular can do and where they might be able to slot into your toolbox (I talked about my thoughts on tools and toolboxes here – again, you can use a hammer to smash a screw into a wall but why would you when a screwdriver works just fine?) but I can’t help but wonder if some folks learn frameworks purely because they are the new hotness rather than actually understanding what they can do and how they can help projects. And, like Brian posits in that article, are we relying too much on frameworks to automate too much of the development process and losing that understanding of the coding fundamentals that sit underneath.

“But Andrew!” I hear the yoof coders cry, “You’re just a crusty old dinosaur who doesn’t understand what us cool kids do!”


Time I got my “How do you do, fellow kids!” on and learn myself some of this frontend framework goodness!

My philosophy has always been that learning something new is most beneficial when you have an actual, immediate application for it. When I was looking into Node.js I had a very small app that I was working on that PHP felt a little heavy for, so that was a great opportunity to deep dive into how Node could help me there. For this particular exercise I looked to the University of Lincoln Library website, something that I work on a lot in my day job.

A little background, the site is built on Capita’s Prism search engine and, while it works, it isn’t the best fit for the task. The templating engine is very limited and unrefined so a lot of major changes are done through DOM manipulation in JQuery. It’s a bit messy and, while I’ve done some work on it over the last year or so to make some sense of the scripts that are in play and refine the code a little, it’s not perfect.

I thought that this would be a good test case to understand how perhaps one of these frameworks could reduce the reliance on JQuery, perhaps to the point that it wasn’t required any more, and replicate some of the functions I’d implemented with less code requirements. As I’d already put a lot of work into pushing the template into a Node environment with rendering functions for the HTML and JS (HTML is all coded in Pug which lets me take a modular approach to building the homepage across the different site flavours we have) I really needed something that I could drop into this without too much hastle.

Looking into the different, popular frameworks that are out there I decided to look at Vue. I’d already played with it a little previously so I was kind of familiar with how it worked and it would sit alongside the JQuery I’d already written so that I could gradually implement some changes over time.

To start playing, I focussed on the search bar of the homepage. Let’s talk a little about what’s happening here. We have three landing pages for searches that pull results from different sources. To simplify the user experience here I implemented a JQuery driven set of radio buttons that not only alter the destination of the form, but also change the Advanced Search link to point to the relevant place. It’s a bit of code soup that first requires the stock form to be reconfigured via DOM manipulation (as we can’t actually edit the form template) before firing off a function to ensure that the correct links are set based on the current search facet in the querystring. There’s then a watcher that is set up to fire that same function off every time the radio buttons are changed. Messy messy code spaghetti.

So, I took the HTML of the form and dropped it into a new Node project, included the Vue libraries and started looking at what I’d need to do to replicate the functionality from the JQuery. Colour me surprised at how darn easy it was. I’ve pushed the code to GitHub here so you can have a look and a play with it if you want, but here’s the core HTML (sorry for all the gt’s – thought I’d try the code embed block in Guttenberg!):

<form class="form-horizontal" id="searchform" action="#" method="get" autocomplete="off">
    <div class="formElement input-group">
        <input class="search-input ui-autocomplete-input form-control" id="s" type="text" maxlength="1000" value="" placeholder="Search The Library" autocomplete="off" role="search" /><span class="input-group-btn"><button class="btn btn-primary" id="searchsubmit" type="submit">Search</button></span>
    <div class="d-flex justify-content-end">
        <a v-bind:href="links[searchradio]">Advanced Search</a>
    <div class="search-radios d-flex justify-content-center pt-2">
        <label class="p-2" v-for="radio in radios"><input type="radio" name="target" v-bind:value="radio.value" v-model="searchradio" />{{ radio.text }}</label><input type="hidden" name="facet[0]" value="fulltext:yes" />

And the Vue function:

new Vue({
    el: '#searchform',
    data: {
        searchradio: getParameterByName('target', 'eds'),
        radios: [
            { text: 'Find books', value: 'catalogue' },
            { text: 'Find books and articles', value: 'eds' },
            { text: 'Find library information', value: 'all' }
        links: {
            catalogue: 'advancedsearch',
            eds: ',guest,shib&custid=s4895734&groupid=main&site=eds&authpid=eds',
            all: ''

So the first thing to look at is the HTML – to let Vue do it’s thing, I’ve had to make some changes here, adding v-bind elements so that the various bits of data from the function can be injected in the right places, but it’s also let me strip out repeated elements like the radio buttons and the multiple links. This is the key bit for me here – in the JQuery iteration I had multiple Advanced Search links that I toggled the visibility on depending on the radio button selected ; here I can use the value from the radio buttons to change the href on the fly and one of the best parts? Because of a helper function I wrote (getParameterByName) I can just grab the query string on initiation of the Vue function and it’ll do all the set up for me. No timed firing off of functions, no event sniffing.

Now, if you’re unfamiliar with Vue that probably made zero sense and, to be honest, this is about as advanced as I’ve gotten with the framework, but it’s opened my eyes to the possibility of having it, in certain instances, replace JQuery in my projects. I need to do more exploration work but so far I’m happy with Vue in that I can see a realistic application for it in my toolbox. Angular and React? Not so much at the moment but that should come with time.

What’s the takeaway from all of this ramble then? I think, at their core, frontend frameworks are something that developers should certainly be aware of and should strive to understand where they can compliment projects and speed up workflow, but just make sure that you’re not using a hammer to bang in a screw!

As always, shout up in the comments if you’ve got any thoughts.