I want to be a better Software engineer, and one of the ways that I think that I could be a better engineer is start poking into things that I haven’t learned before. There’s mobile development and other aspects of web programming that do interest me. As such, I’ve been attending a local Remix meetup, and I thought that I could start learning Remix and present something.
Previously, a lot of my web programming experience has been in Next.JS, and I’ll admit that I was maybe getting bored with Next.JS. Plus, I knew that there was so much to web programming that didn’t involve Next.JS. I need a break from Next.JS.
And so I’ve been hearing a bunch about Remix, and other frameworks. I was in contact with people that preferred Remix over Next.JS, so I decided to learn a little bit about Remix. I read that the creators of Remix really want to promote following web standards and having a simple framework that doesn’t follow hypes. Versus, Next.JS kind of does its own thing, and it definitely follows the hype train sometimes to its own disadvantage.
Now, before I get deeper, as I looked through Remix documentation and practiced developing in Remix, there are similar prinicples with Remix and Next.JS. In my perception, some people just like to be in different camps and go after all the gimmicky things, and I don’t think this is entirely beneficial. There are many ways to solve a problem when it comes to coding, and I believe I can learn from everyone. That’s generally my approach to the world now-a-days. Anyway…
What are the similar prinicples of Remix and Next.JS? One, both really try to remove a lot of React processes from the browser and instead place the processes in the server. That follows a trend to remove processing power from a client’s device. As well, if some interactivity is needed, then both frameworks will send some JS for the user. Two, both have data loading techniques. They are done differently, of course, nonetheless they are similar. Three, both frameworks have some sort of routing and link system. I’m not sure if I’d prefer Next.JS page routing or Remix routing, even then both seem to work greatly. Yes, I didn’t menion the App Router in Next.JS. That seems like it’s getting gimmicky and a bit much.
But I want to talk about Remix more. I do like the attempt to follow web standards. Following web standards could teach people how the web works. Thanks to Remix, I’ve started to use forms more. Otherwise, I would just have a client side form with JS. I do like that there are action functions to handle any form submission. This reminds me of PHP (I’ll stop right there hehe). It is nice that Remix will still completely work if the user has disabled JS. This does seem a little gimmicky to me however, because JS is universal anyway. Only the paranoid people would probably have JS disabled. I do like that Remix gives use of head links and meta tags. It seems useful to me to allow each page route to have objects describing that info, versus getting a Head tag in Next.JS.
What about things that I don’t like with Remix? One, it seems to have trouble resovling ESM imports still. For example, if I want to use react-icons/fa, I get an error saying is not supported resolving ES modules. I have to attach /index.js to the end of it for it to be used in the Remix app. Now there may be some fix or configuration, but I would expect this module system to not be a problem especially if ESM should be universal by now. Another thing I don’t like is if I get a runtime error in the Remix application. In my experience, I have had to restart the Remix server. I’m pretty sure other frameworks that I’ve used would do the restart on its own.
Overall, it’s been a positive experience learning Remix. It was a fairly easy pickup, seeing that I knew the priniciples of Next.JS and JavaScript fairly well. I will try and continue to learn other things, I’ve got my eye of mobile development, and I wonder all the things that I can learn there.