2ndFeb2022

I've been working on rebuilding my site using the latest and greatest framework of the moment Remix and have to say it's taking me back to my old days as a PHP developer. Making database calls in the same file as the view has vibes from my early days as a developer when PHP development was either cowboy style or massively corporate with no middle ground.

Thankfully Remix builds on years of sensible decision making and has a very straightforward mental model that fits very nicely with React and modern web development so it's unfair to be make that connection. I'm enjoying the way that we finally seem to have a framework that keeps the old-school Web Developers happy whilst catering to the tastes of the modern Developer. Remix does this by leveraging good old fashioned platform features and progressive enhancement whilst using modern browser APIs for wrangling data, cookies etc. This leads to less JS being sent to the client and significantly eases the challenge of having client-side and server-side validation being handled gracefully.

Remix isn't just useful for static sites, I've written a very simple blog and journal writing tool for this site using Remix that's backed by Firebase and have so far found it mostly a pleasure. There have been some gotchas during my time with Remix, some of it the pains of learning any new framework and some a lacking in Remix as it currently is (I'm using 1.1.3 as I write this).

Some Pains

  • With Remix, there's a hidden Server/Client split that it's easy to forget that you're writing code that is going to be server-side rendered (SSR). This is my fault as the docs are quite clear about this but it can be easy to start building standard React Components and want to add in a loader function (which you can only use on files under the /app/routes directory, but it's easy in the early days to get confused.

  • Importing an npm package can sometimes be a lottery as to whether it'll cause your app to throw a hissy fit. This is because of the nature of how Remix smoothes over the Server/Client split, you'll import something that doesn't work in both environments and so you have to tell Remix that this is a server or client only file by modifying the file name to be someFile.server.ts. I've had this problem when importing node only code to be used in the loader or action functions only and the Remix dev server isn't happy with.

  • Uploading files - I'm working on a Journal where I'd like to make photo heavy pages and trying to upload to Cloudinary through my simple blogging backend has proven to be more difficult than expected. There's a workaround for uploading large files and I'll be trying that so that I can make progress.

These pain points are mostly problems on my side of things, picking up a new framework takes a while to get your head around and I'm sure that any rough edges will be smoothed over in no time at all. The documentation site is great, things like deployment have proven to be a breeze and it's clear that Remix has a very strong vision and is blazing a trail in the right direction for all users of the web.

Overall I'm really happy with Remix and looking forward to using it not just on this site but in commercial work as well and am loving the fact that I'm picking up knowledge of #theplatform.