Ian Mulvany

March 2, 2022

remix vs, well, vs lots of other things

Looking at the remix framework - https://remix.run/docs- we are experimenting with this right now at work. 

I am well past deeply understanding how many of these frameworks operate, and anything much beyond MVC is a bit beyond me, but we have very good people working on this right now. 

We have been using Vercel for a while with static site generation. 

I read through the remix vs next.js blog post - https://remix.run/blog/remix-vs-next and I _think_ my takeaways from this post are:

At the moment we drive site performance from our vercel setup by using static site generation, and then pushing static sites to edge on Cloud Flare. This is fast because we never hit a server when the reader hits the page, but it does mean for any content re-fresh we have to rebuild any pages, or page component, that needs to be updated. 

However the advantage is that we are only building against the schedule of content creation, and not on the schedule of content being read. One other downside is that we would have to shoehorn in dynamic components on the page, e.g. personalisation. (This is probably not so bad, as it is likely that we would use some 3rd party drop-in javascript component in any case, rather than roll our own bespoke personalisation code). 

What this article is saying is that remix gets to performance not from using SSG, but from using cache invalidation in a smart way. So core logic remains on the server, but remix uses an optimised set of HTML directives to only check back on the server as infrequently as possible, so it kind of looks like SSG, in terms of content hanging around on edge, but because it is server backed, you don’t have to delegate a ton of JS to client and edge that end up increasing your payload at edge. I think that's what it’s saying? 

On top of that you might be able to deploy the server side application at edge too, given the right way of doing it.