Rails was done by a product guy to solve one need. Most of the "the new rails" challengers are made by engineers.<p>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.<p>So far, any framework I saw that claims to be the new rails, is speaking about features and the million things you can do.<p>It feels like Rails was done by a product guy, and all alternatives were done by engineers.<p>From reading the article, remix feels like the best way to deploy to edge. An engineering problem. Not a user one.
I'm getting the following on visiting the page, couldn't have said it better:<p>> Unexpected Server Error<p>> Cannot destructure property 'series' of 'e' as it is undefined.
I haven’t tried Remix, but I’ve seen the demos and read the docs. It looks promising but from what I’ve seen I think you can hardly call it the next Rails. The older I get, the more experienced I get, the more I think back of my Rails days as an amazing time. The framework had/has it all. I haven’t found anything that comes close to the developer experience and how easy and structured it is to work with.
> We could probably add some SSG functionality very easily, but it’s just not that compelling when you can run your app at the edge for pennies. I mean seriously. You sacrifice so much flexibility when you prerender everything. But when you’re running your app at the edge on CF workers you can have SSG speed without sacrificing the flexibility of SSR.<p>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.<p>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 <i>maybe</i> 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).
IMO the big deal in Remix is partial hydration with React (not trivial to roll your own and do it well) and shipping perfectly functional websites without the need for JS.<p>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.<p>Astro is also doing partial hydration for a number of frameworks, but it’s static only so it’s much more limited.
I'm going to play the role of the skeptic here, but the last time I heard about a new Rails for JS was in the context of RedwoodJS [1] a year and half ago. I don't think it delivered on that, at least from a popularity point of view, as I've only heard about it once or twice since.<p>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.<p>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.<p>[1]: <a href="https://redwoodjs.com/" rel="nofollow">https://redwoodjs.com/</a>, <a href="https://news.ycombinator.com/item?id=22537944" rel="nofollow">https://news.ycombinator.com/item?id=22537944</a><p>[2]: <a href="https://remix.run/" rel="nofollow">https://remix.run/</a><p>[3]: <a href="https://remix.run/docs/en/v1/pages/philosophy" rel="nofollow">https://remix.run/docs/en/v1/pages/philosophy</a>
The article seems to be suffering from the Hacker News effect. Here's a mirror: <a href="https://web.archive.org/web/20211218090314/https://marbiano.dev/into-remix/on-rails" rel="nofollow">https://web.archive.org/web/20211218090314/https://marbiano....</a>
I only tried the tutorial in remix and still don't get the use cases, probably because it's a new way of development compared to the traditional MVC?<p>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<p>Probably because it's unopinionated? for instance how would you setup middleware, events, logging, etc?<p>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?<p>Maybe the docs need to be better. or i'm just not good with new stuff..
Intrigued by Remix but ultimately didn't see anything super appealing. I already use react-router v6 and can pretty quickly plumb things together to get up and running with an SPA. Organizing code by feature already colocates code together which I've been doing for years in react/redux.<p>SSR adds a tinge of complexity but can be accomplished in ~200 lines of code and proper data fetching abstractions.<p>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.<p>Regardless I'm keeping my eye on remix to see what they come up with next.
I would love to hear someone compare this to SvelteKit, and their different adaptors, like Vercel or Cloudflare workers.<p>i.e.: <a href="https://developers.cloudflare.com/pages/framework-guides/deploy-a-svelte-site" rel="nofollow">https://developers.cloudflare.com/pages/framework-guides/dep...</a>
> 16 years ago, David Heinemeier Hansson (DHH) took the stage and delivered one of the most impressive code demos the world has ever seen.<p>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.<p>[1] <a href="https://www.youtube.com/watch?v=MZvmYaFkNJI" rel="nofollow">https://www.youtube.com/watch?v=MZvmYaFkNJI</a>
Interesting take. I had the experience with Remix and drew the comparison to Tailwind.css [1]. I get the sense that Remix's move away from REST + SPA will be polarizing because of the magnitude of the shift, but tremendously productive for many developers who embrace it.<p>[1] <a href="https://koptional.com/article/remix-fullstack-paradigm-pros-and-cons.html#a-short-intro" rel="nofollow">https://koptional.com/article/remix-fullstack-paradigm-pros-...</a>
this is ironic<p><a href="https://s2.loli.net/2021/12/18/E7faXl2AnVbr5W9.png" rel="nofollow">https://s2.loli.net/2021/12/18/E7faXl2AnVbr5W9.png</a>
Remix seems quite appealing, but I wish they went with Qwik’s model rather than SSR HTML + hydrated React. I wonder if their architecture allows to plug it in under the hood.