Remix: On Rails
marbiano.dev
marbiano.dev
Rails took a need: creating a blog engine; and make everything needed to have the simplest and most understandable way of doing it. Going through that example was like: -"Ahh makes sense.". Features were secondary and the focus was on the solution. It was about solving one specific use case and grow from there.
So far, any framework I saw that claims to be the new rails, is speaking about features and the million things you can do.
It feels like Rails was done by a product guy, and all alternatives were done by engineers.
From reading the article, remix feels like the best way to deploy to edge. An engineering problem. Not a user one.
I don’t think Remix themselves are claiming to be the new Rails.
Modern Rails has been adapted to modern standards and trends but is still a "basecamp framework", with some additions to also be a "hey.com framework".
Basecamp is a small company, intentionally, so it makes sense that DHH is more of a "product guy", or at least has more of a product sense than your typically insulated enterprise engineer.
For whatever reason there doesn't seem to be a huge overlap between people drawn to traditional engineering and linguistics.
I've repeatedly observed that some people have an affinity for the hardware (and are closer in disposition to engineers in other disciplines), some for the software, and only a smaller subset really enjoys both.
So much of what makes api's, languages and complex sytems easy to reason about are their linguistic ergonomics.
It's just a feeling but I hold the position that there is still a lot of room for improvement in language ergonomics and density, and that we're still closer to latin than english in both linguistic efficiency & developer tools.
https://www.realclearscience.com/blog/2015/06/whats_the_most...
I think DHH (and rails by extension) is an engineer with strong linguistic affinity biased towards financial utility. So it's no wonder that first blog video blew so many minds.
The fact that all alternatives you see are done by engineers doesn’t feel that shocking because, well, all software frameworks require them to be built by software engineers.
Some are lucky to have a good sense of customer/user needs and the desire to build products too. Frameworks like Remix are thinking about balancing good UX, DX an what the tech of today can today and not simply solving engineering problems.
> Unexpected Server Error
> Cannot destructure property 'series' of 'e' as it is undefined.
I forgot to add some basic caching to the site, and it absolutely backfired when the "HN effect" happened on a Saturday while I was on a fishing trip. Perks of the modern like.
It's back up now, hope you enjoy the reading!
Kinda true, except that with no focus on cache hit rate and no discussion of (for example) pre-warming HTTP caches, this is mostly unrealized for a large class of websites. When you’re running on a CDN with a large number of nodes (like Cloudflare), with a lot of dynamic pages that change frequently, and a geographically broad visitor base, you’re likely to have a bad cache hit rate in production. And the trouble is you won’t really notice it for your demo tweets, because you’re gonna get mostly cache hits from your own CDN node.
There have been demo tweets from Remix (and other similar frameworks too, I suspect) that boast about their 50ms response times and attribute that to computing at the edge, but really they’re just setting a generous max-age and getting a 50ms cache hit from the traditional CDN (not edge compute) node. One such demo I saw on Twitter had a much more bog-standard React SSR response time of more like 350ms when you get a cache miss. At that point you’re not getting anything from Remix related to “edge compute” other than maybe the slightly reduced network latency from server to client (but that’s unlikely to matter much when it’s 300ms to do the React SSR render).
It’s the framework that lets you develop in React + Typescript, without thinking about what’s server-side and what’s not, which also lets users consume pure, well-structured HTML plus the minimum JS that’s needed for interactivity.
Astro is also doing partial hydration for a number of frameworks, but it’s static only so it’s much more limited.
There's a bit more to it than that (mainly some magic related forms and data reloading), but if you were hand-rolling your own React SSR code back then, you'll find that the overall capabilities of Remix are somewhat similar -- just much less verbose.
remix's landing page uses 270 KB of Javascript split into 15 chunks. And it's static text with a couple of images.
minimum
Looking at the website of Remix [2] itself, it feels a bit weird. I may be missing something, but it feels like what Remix offers is what traditional server-side rendered HTML already does. Fetching a document and then all the JS instead of JS fetching JS? That sounds like how a classic website works. HTML forms with server-side validation? Same thing here. The part about error boundaries is interesting, and it looks like an exception mechanism for different part of a web page. I like the idea, though I've always heard that it's important to separate logic from presentation, and this seems to go in the opposite direction.
Considering the philosophy page [3], maybe that's the whole point and the goal is to build on existing React skills/codebases to go back to a traditional way of doing web applications? I'll be honest, I'm a bit confused here. I've never worked with the React ecosystem, so maybe that's why I don't understand everything.
[1]: https://redwoodjs.com/, https://news.ycombinator.com/item?id=22537944
[2]: https://remix.run/
In the case of react server components, the idea is that some pieces of the view can be exclusively rendered on the server and then the client hydrates the rest with interactive components.
Ah but they've managed to make what's old new again - and hype it to a level getting on for when Rails was first introduced...
I thought it's still missing a lot of stuff compared to rails / other battery included frameworks? The closest one comparable right now is redwoodJS
Probably because it's unopinionated? for instance how would you setup middleware, events, logging, etc?
Battery included frameworks like django, laravel, rails, all have extensive docs and way to setup everything. Also jumping between those frameworks already gave you familiarity due to the mvc structure. Now i'm probably just confused, from mvc, to spa and api, now to SSR with data fetching and processing happening all in 1 file?
Maybe the docs need to be better. or i'm just not good with new stuff..
Remix still requires an API.
SSR adds a tinge of complexity but can be accomplished in ~200 lines of code and proper data fetching abstractions.
To be fair, I also cannot stand rails or other batteries-included frameworks. My general perspective is they are great until they are not and then you'll be scouring docs/stack overflow to figure out how to bend it to your use-case. And after hours of reading you come to the conclusion that it cannot do what you want it to do and then you open an issue and hope the maintainers will accommodate.
Regardless I'm keeping my eye on remix to see what they come up with next.
Unexpected Server Error
Cannot destructure property 'series' of 'e' as it is undefined.
i.e.: https://developers.cloudflare.com/pages/framework-guides/dep...
16 years later there's no tech stack that can replicate this demo (except Elixir LiveView [1]). And yet we're told tech has progressed.
I've yet to see a single video like that from any of the new remixes/redwoods/nexts/nuxts/<god there are so many of them> And one that doesn't require 270 KB of Javascript to display a static page like Remix's landing page.
I build my blog in next in like 5 mins and dont need to spin up a freaking db for it.
your reply is really on point btw, I ask if any one has a list of features and you say here is a video watch it and make the list
Yeah, you built your static site using about a million dependencies etc.
Now try building it with a DB, because that's what a lot of sites require. And yup, rails could easily give you that 16 years ago, with scaffolding and what not.
> i ask if any one has a list of features and you say here is a video watch it
Because the video is quite short, and shows things unachievable with most (or all?) current frameworks. Like building a fully-functional DB-enabled app in under 15 minutes with introspection.
What things? you are wasting a lot of words and saying nothing. I'm watching the video and see nothing impressive. I mean it sounded impressive back in the day, but today? Symphony for example can do all of this. Not that I like PHP it's just the only framework I know, but there are plenty of those in existence
Let me quote that for you:
--- start quote ---
building a fully-functional DB-enabled app in under 15 minutes with introspection [etc].
--- end quote ---
who makes claims like "Rails is the only framework that has database with introspection"? What do you think the word "framework" means and what do you think other frameworks do?
Those are the name of 2 random frameworks, one js and one python, name ONE thing Rails can do that these cant
I clean forgot about Django. I haven't used it in over 10 years.
No idea what Nest is.
> name ONE thing Rails can do that these cant
No-no-no. Lets start from "here's a demo that build an actual functioning db-enabled app in 15 minutes that doesn't require 100 lines of code to just display a static page"
I suggest you don't make comment about things you've never used. To have a hello world static page in nextjs you just need a single file with a single line. To have a database set up it takes... 15 mins too. You are pulling 100 lines of code out of your arse.
In my country Ruby/Rails was never a thing, so hiring and building a team would require a lot more effort.
[1] https://koptional.com/article/remix-fullstack-paradigm-pros-...
I got the sense that they're just co-locating the two things in the same file.
It's like how CSS-in-JSS didn't get rid of CSS, it just put it in the JS file.
But that’s also true of most JS web frameworks, where many use REST to mean “some API endpoints that speak JSON”.
(You could do REST with Remix, but I really don’t think that’s what they’re going for)
We are making sure both Remix and Next.js work excellently at the edge by compiling down to our Edge Functions primitive (https://vercel.com/edge)
Whereas trying to deploy Next.js anywhere other than Vercel is a nightmare.
If it ever was, this certainly isn't true right now.
I have very recently built a small, perfectly capable website with a colorful mix of Next.js functionality and deployed it on my own server.
Happy to report that it really is as simple as the docs make it seem: https://nextjs.org/docs/deployment#nodejs-server
The advantage of Remix in this area is less that they've written their own adaptors for these platforms (do we really care who writes them, as long as they exist?), but more that the level of abstraction they've chosen appears to make it _easier_ to write these adaptors.
Edit: Something I missed, is that Remix does appear to work on Deno, whilst Next doesn't.
I’ve never heard this before. Why is it a nightmare? Isn’t it just a Node app?