About appZuka - Our Journey

The Journey So Far

I started coding in Basic and Assembly language on a UK101 and went through Pascal and C on various platforms over the next couple of decades, both in personal projects and professionally in a research environment.

PHP and Drupal

My journey in web development started around 2009, where I selected the Drupal platform. I chose Drupal because it was a popular open source platform which was more customisable than Wordpress. Given that I approach web design as a coder Drupal gave me a platform to develop websites quickly using a template but the ability to customise pages to my requirements. This was my first exposure to PHP.

Ruby on Rails

I am constantly looking into new technologies and came across Rails. Initially, I decided not to pursue Rails because it required learning a new language, Ruby, to get started. At some point, I went through a tutorial to get a basic Rails site running and found Ruby to be an enjoyable and productive language. I spent several years with Rails as my main platform and still love Ruby.

Angular and React

While looking at new technologies I saw the buzz around ember and backbone. Initially, I did not see the benefits a client-side framework would bring as I was using a powerful server-side framework in Rails. I developed a site in angular and saw how powerful the client side framework was. One benefit for the sites I was developing is that a client-side framework opened up the possibility of no longer having to maintain a server.

Before settling on Angular I developed a site using React and found it more suited to my style. I like the one-way binding and React is more suited to the smaller applications I develop. That is not to say that Angular is an inferior framework, just that for my purposes, I prefer React.

Elm

There is always another framework and I came across Elm. I developed a test site in Elm and really fell in love with the language and platform. I had tried functional programming using Haskell but never found a project to use it on. Elm is the first time I used functional programming and saw how it allowed me to create more reliable code. I also liked Elm’s data flow architecture with messages and update functions. Elm promises no runtime errors, which is very attractive as a developer.

After looking into Elm I decided to take a step back and focus on React. The reasons were that the language was not mature enough and the developer community was too small. Looking back several years later this was the right decision. At the time Elm was on version 0.18 and as I write this it is still on 0.19 with no timeline. Many of the benefits of Elm are available in React using Typescript, Flow and Redux. It is possible to write clean functional code in Javascript. I take the point of Elm aficionados that Javascript permits bad code so there is always a temptation to code quickly with the intention to clean the code later. With the huge community of Javascript/Typescript/React I believe I am more productive than I could have been in Elm. However, I believe I am a better Javascript coder because I learnt Elm and I strive to maintain the code quality Elm forces on developers.

Managing Build Complexity

After developing a number of sites using React I wanted more control over the code. In particular, I wanted to control over code splitting and when components are rendered to optimise performance and achieve high Lighthouse scores. Sites created using create-react-app contain a huge amount of hidden configuration which is hard to control. For this reason, I started creating apps from scratch using Webpack as the build tool.

That does not mean I am not a fan of create-react-app. It is a great tool for people getting started in React, as I once was. It allows you to get your first app up and running and concentrate on building components and provides some great developer features such as hot code reloading. On the downside, it makes quite a large number of opinionated decisions about the build environment (babel, webpack, no-sass). You can get control over all of this by ejecting your app, but your app still has all these build dependencies.

At the time I was using create-react-app it was using Webpack3 and an old version of React. I had also added Redux and Redux-Saga as a way to manage the state in the app including for asynchronous events. (Redux adds a lot of boilerplate but came naturally after Elm as Redux is built on the Elm architecture). React-router was being used to manage routes as that seemed to be the standard package, although that again was stuck on an old version. Upgrading the app was problematic because of all the dependencies introduced by create-react-app and the extra packages I added. If any of these packages or their dependencies had not been upgraded to use the latest package the entire bundle could not be updated. Even if you were able to update, you would never be sure that everything would work as expected.

Webpack

There is so much included in the webpack configuration from create-react-app it would have been hard to remove the bits I did not want without breaking the system. Having become confident in using React I decided to build an app starting from a scratch using a vanilla WebPack configuration. It turns out that many of the features in create-react-app come from Webpack, not React. This includes the build process, clearly, but also the hot-reloading during development and the ability to import css, svg, images, etc.

Starting from a blank configuration gave me the freedom to select the options I wanted. I chose TypeScript over Babel and Flow, partly because of the tight integration of TypeScript in VS Code and partly to reduce dependencies (see this [tech note|/technotes/coding/typescript] for further details). I also chose sass, which was not included in create-react-app.

Webpack is more than a bundler, it is a platform. I use the WebPack configuration and custom plugins to achieve everything I need in the build process including:

  • Adding a timestamp and git reference to the site footer
  • Embedding development or production options into the site during build (for example, Google Analytics, JavaScript error logging, setting pages to be indexed or not indexed by Google.)
  • Compressing and fingerprinting the assets the assets

The only other build tool I use is npm. The scripts in package.json start webpack with the required options. Previously I had used bower and gulp and have found npm and webpack to be a perfect combination which achieves all I need.

The result is that I have come to depend heavily on Webpack, having stated that I keep dependencies to a minimum. I believe this makes sense as this one tool is very powerful. Learning to use it has enabled me to stop being dependent on many packages which were black boxes to me.

Virtual Dom & Incremental Dom