A Front End Journey

It seems I can’t stop myself from having ideas for side projects, and where I can squeeze a few hours out to actually start them. Many of these projects require some form of frontend with varying degrees of complexity. With one of my most recent projects I decided to do a little dive and see which frameworks would be the best. The goal was to get something up and running in as little time as possible, while giving the option for turning this into a production product down the line.

The Idea

I am busy launching an API to provide travel advice data from various government sources. The idea of this API is to answer the questions “where can I travel now?” and “what is the latest news for this country?”. The application of this API is in travel websites, think flights or hotels, and at search time having real time information displayed to you: you enter in JFK airport, and immediately you are able to see the latest travel advice for the US as well as an associated level on international travel.

The API is built in Go, of course, and I wanted to build a simple website where a user could answer those two questions above. My go to would probably be React for any sufficiently complex website, but I also wanted to look at Vue, Meteor and Expo (web).

React

I decided to try React first. I’ve had a decent amount of experience using react and redux, both on web and mobile, but these have been “take the long route”. I normally started with a simple application and then added components as needed, developing along some given standards to get to a decent place. I learned this initial from working through a fantastic tutorial.

The first point of frustration was when I could not find a project that conformed to my understanding of a project layout. Every React and Redux start kit I found followed different layouts and internal structures. Why? I get that there are different ways of doing things, but finding ten different “recommended” boilerplates is confusing. It also seems the new standards are sufficiently different from the old standards, requiring a separate learning exercise.

Of course, it could be that my understanding of what a React and Redux project is is incorrect or outdated. Even so, the gap from where I was to where I needed to be to get anything written and running was too big. In some aspects it would mean learning from scratch.

Meteor

The next option was to look at Meteor. I’d worked with it several years ago and was really impressed by the speed of getting things done. I built a side project to watch anime and keep track of where you were, list your starred shows and give a better viewing experience. The thinking was “Netflix for anime” so the name of the project was Animetflix (this was something I built for myself, not for public use). The experience was awesome, and the team seem to have kept improving the stack.

After downloading the latest version, I managed to get a small test program up and running nicely. Working between the frontend and the server is seamless and really straightforward. I got API calls working and data displaying in no time, and could have easily built the rest of the solution, but stopped due to the architecture.

Meteor has a server built in, whereas for this project I only needed the frontend. If I continued the capability of Meteor would be wasted and I would have an over-engineered application. I’m happy I got to take a look at Meteor though, for some simple three-tier apps I’d definitely consider it.

Expo

I have worked with Expo before when making mobile applications, especially Fight A Bear, and thought I’d take a look and see what the web version of Expo could offer. There is some detail on deploying websites using Expo, which seemed interesting, so I decided to take a quick look.

Expo has always been a pleasure to work with, and some of the improvements they’ve made recently make it even better. It does come with some limitations, and two different types of workflow, but for most projects you shouldn’t come up against these. With my Expo projects, I use the React/Redux pattern but normally put this in place manually. This requires some scaffolding work, and while it isn’t hugely time consuming I wanted to use this project to see what I could get done in as little time as possible.

I decided to take a look at my last option, Vue, before making the call on which framework to use.

Vue

I’d dabbled a bit with Vue previously and found it easy and super intuitive. To start, I created a project with the Vue cli and after reading a few docs and some quick development work I had exactly the website I wanted to build. It took significantly quicker than any of the other technologies above, even Expo which I had good familiarity with. While I know React, I’m clearly a little out of the loop and it took me longer to try and find out what’s happening with things like Redux slices than it did to get the entire Vue project up and running.

After building out several other pages and adding the functionality I needed, I built and deployed the site to S3. All of this development took maybe two hours in total, including learning best practices, getting up to speed with where Vue is at currently and ending up with a three page application consuming API endpoints and displaying the data.

Moving Forward

Since then, I signed up to the Vue Mastery course and am currently making my way through all of the courses, starting right from the beginner ones. There have been so many “oh wow” moments while learning about Vue that I doubt I’ll voluntarily start a new project using another framework.

When learning React it took some time to get my head around how things worked and connected to one another - it was foreign to my understanding. Vue just makes sense to me, and this isn’t to say it’s better or worse - I just get it easier than I get React (or similar other frameworks).

I’m really looking forward to learning more about Vue and building applications with it. For the first time in a while I am genuinely excited about a framework.