Learning InertiaJS and building a task list

I use task lists extensively to organize my life both work and at home. Over the years I’ve used tools like Things.app and Todoist. While I like lots about Todoist there are a few aspects I miss from Things like the ‘evening’ view and task descriptions. The subtask model that Todoist uses is overcomplicated and I miss the simple subtask list from Things. I had a bit of time this winter due pandemic and my city being under a stay-at-home order since December. I decided to use this time to learn some new libraries and a new domain. Building a task list seemed like an interesting way to explore InertiaJS , Reach and potentially build a task list that blended what I liked of each tool I’ve used.

No API

While I really like the interactivity that client rendered applications can provide, I dislike the complexity the incur around build tooling and the overhead of having to build an API. Server rendered applications are much simpler to build and debug, as they have fewer layers and state lives in fewer places.

Inertia strikes a lovely balance between client and server rendering. By rendering a large part of the page on the server you can skip using client side routing, most state management and a formal API. Instead your template variables are converted to JSON and included in the HTML. This state is then used to hydrate the client side code for a given page or view. This leads to simpler client side code and faster page renders as there are no API requests to make before content is rendered.

While pages are initially rendered as HTML with embedded JSON payloads, any links, form submissions, or XHR responses made through Inertia can do partial reloads via JSON responses. This allows your application to benefit from the best of server and client rendering.

Forms and Redirects

Being able to use basic HTML forms to do most of the create and update requests is a benefit that I underestimated. Not having to manage form input state, marshall forms that into API requests and then handle the response and client state updates is a huge productivity benefit. Instead of needing to use complex form building UI toolkits, I’ve been able to do most of what I need with simple HTML elements and compact components for validation errors and flash/toast messages. When a form is completed successfully you can use a plain HTTP redirect to the new page, and Inertia will ensure follow the redirect and load the JSON version of the new page. This makes forms quite pleasant to work with, and feel really snappy.

If your application updates can’t be decomposed into form submits and redirects, you can still use XHR requests and client side state management. I found when I needed to use client-side state the difference in complexity was dramatic and felt unpleasant in comparison to form submits and redirects. I’ve been trying to rethink flows into page loads where possible.

Ecosystem support

Another great thing about Inertia is that it plays well with a variety of server frameworks, and client frameworks. While I used CakePHP and React, you can also use Laravel, Django, or Rails on the server and Vue on the front-end.

If you’re looking for a way to power up your server rendered applications, or want a simpler client rendered application experience I recommend you give Inertia a try. If you’re interested in the task list I’m working on you can find it on GitHub . It is still under development, but if you find it useful I’d love to hear any feedback you have on it.