That was the reality I found myself in at a recent design sprint where the iHub Software Consulting team together with iHub Research and the KRA innovation team, took 5 days to re-imagine the tax filing experience of the average Kenyan. You can check out the prototype by going to https://easytax.ihub.co.ke/
I placed my bet on Preact after I read Uber shipped out it’s mobile web client app at a total bundle size of 50kb and the fact that I recently finished a great React Courseon Udemy which got me longing for a chance to apply the knowledge on a problem in a production setting.
What is Preact
Preact is a fast 3kb alternative to React with the same modern API. It provides the thinnest possible Virtual DOM abstraction on top of the DOM, has one of the fastest Virtual DOM libraries out there thanks to a simple and predictable diff implementation and it allows you to seamlessly use thousands of Components available in the React ecosystem.
In simpler terms: it works similar to React, it's closer to the metal(actual DOM) and updates the DOM using a similar pattern to React.
Here are some of the qualities that made me not regret choosing Preact as a tool to building out my prototype.
1. Easy to get started
Getting from zero to productive has been simplified by great tooling such as Facebooks' create-react-app library. Running create-react-app name-of-app gives you a ready to go app structure without having you decide on fundamentals like build scripts and ES6 Babel plugin configs as well. Greater build tool and configuration control is afforded by the tool when you run npm run eject. This allows you to access the Webpack build configuration and modify settings at a granular level. I was up and running in under 10 minutes which made me happy.
2. You are still writing React
If you are familiar with writing React syntax, then you can easily switch to the Preact library using a bridge package called Preact-compat. You can find out how to do so here. It has a minimal cost of switching and still allows you to access to the core functionality of the React library. To see the subtle differences between the two you can read this
3. Components and JSX for Html are good for productivity
- Greater speed when coming up with reusable elements: Having your HTML markup and logic in one file/component speeds up the process of slicing the designs. I get to re-use with ease, and enhance without adding too much boilerplate code.
- It’s still HTML markup you’re writing: JSX offers you a way to supercharge your HTML markup more openly and sanely in my opinion. Plus, it offers support for the full HTML spec including Aria Labels as well Sure I'll have to get used to camelCasing my attributes but it’s something that becomes second nature after writing a few components.
- Increased focus on writing App Code and not on boilerplates: This one was a silent realisation after I had written a couple of components for the prototype which never required any state. I realised that the amount of pure ES6 and JS code outweighed the boilerplate code: or as I call it; the code that helps you write your own code. Be wary of frameworks which need you to write more framework code in order to write your own code.
4. Access to the Rich React Plugin Ecosystem
Prototyping relies a lot on moving iteratively which means using pre-built components and pieces of logic where possible. After all, it’s only meant to communicate a possible solution to a problem in a short amount of time. Some of the pre-built solutions which proved to be lifesavers were:
- React Intl: For Internationalisation support.
- React Modal: For quick and light modal interactions. No bootstrap and fully customisable.
- React Burger Menu: For off canvas navigation support.
- React Router: For routing which gives that multi-page feel in a Single Page App.
- Axios: For making XMLHttpRequests from the browser using Promises. It has great REST syntax support.
5. Did I mention the small bundle size?
Preact is 3kb of library code. 3, people!!! Just 3. Which means that your plugins and actual app code will make up the larger part of the bundle size. Ideally, this is how every framework should be. This leaves us free to see the impact of smart import practices when working with plugins. For example.
Instead of importing the entire lodash library in order to use an orderBy function like so:
You can just import the function you wish to use an have Webpack only import that instead of the entire library
The same for other plugins. Import only what you need for a smaller plugin footprint in your code.
There are more aspects about Preact that I appreciated but those are what stood out for me.
Do you believe there’s something better and faster I would have used to accomplish what I wanted to in even lesser time? Do you agree or disagree with my reasons? Whatever you feel and want to ask, I’d like to hear it in the comment section below.
You can play around with the prototype we came up with here: https://easytax.ihub.co.ke/ (I took another 2 days to refine it ;)