9 ms·

Remix: On Rails

95 points by goranmoomin 5y ago

lefrenchy 5y ago
I may have missed it, but what makes Remix able to run SSR at the edge? Can you not do that with NextJS?
- Rauchg 5y ago
  You absolutely can! The data loader concept in Remix is semantically equivalent to `getServerSideProps` 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 https://vercel.com/edge)
  - DenseComet 5y ago
    I was under the impression that most of Next's server side capabilities, outside of the recently introduced middleware and react server components, required a node environment. I know Vercel does offer multiregion capabilities for enterprise and a bunch of smart things to make sites faster, but its still not the same as being able to do everything on edge the way remix advertises.
- Tomuus 5y ago
  One of my favourite things about Remix, and where it beats Next IMO, is that you can deploy it anywhere. Bring your own server. Whereas trying to deploy Next.js anywhere other than Vercel is a nightmare.
  - playpause 5y ago
    > Whereas trying to deploy Next.js anywhere other than Vercel is a nightmare. I’ve never heard this before. Why is it a nightmare? Isn’t it just a Node app?
  - jstummbillig 5y ago
    > 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 https://nextjs.org/docs/deployment#nodejs-server
  - nsonha 5y ago
    I made my blog with Next.js which is deployed with github actions on gh pages, there was some tricky thing about static paths but that might have been fixed and if it was anywhere close to "a nightmare", I would remember.
  - andrewingram 5y ago
    This is (mostly) untrue. It's easy to deploy Next anywhere you can run a node server. What's more fiddly is deploying it somewhere that has its own special environment, like AWS Lambda, Cloudflare Workers, Netlify etc; basically "serverless". But adaptors do exist for most of these to make it fairly painless, they're just not part of Next itself. 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.
  - freedomben 5y ago
    I run 3 non trivial Next.js apps in prod. While I have used Vercel in the past, I'm not currently. One is completely SSG (served by nginx) which is absolutely amazing and is the killer feature that keeps me going back to next.js. The other two have node because they use next/Image. I do really wish there were a compatible Image with SSG, but it is absolutely not hard to run a node app in prod, and there's no difference between a node app and a next.js that needs node.
jackconsidine 5y ago
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. [1] https://koptional.com/article/remix-fullstack-paradigm-pros-and-cons.html#a-short-intro https://koptional.com/article/remix-fullstack-paradigm-pros-...
- fastball 5y ago
  Is Remix really moving away from REST + SPA? 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.
  - vosper 5y ago
    There’s no REST in Remix, at least not in the original sense of REST. 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)
syspec 5y ago
Is this a backend framework built on top of NodeJS? It looks slick, but I can't find the backend docs
- jackconsidine 5y ago
  It's actually a full-stack framework. The Remix build process effectively splits it into a separate frontend and backend, though single files have both bits of code
tshaddox 5y ago
> 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. 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).
xrd 5y ago
I would love to hear someone compare this to SvelteKit, and their different adaptors, like Vercel or Cloudflare workers. i.e.: https://developers.cloudflare.com/pages/framework-guides/deploy-a-svelte-site https://developers.cloudflare.com/pages/framework-guides/dep...
- leerob 5y ago
  Remix uses React. SvelteKit uses, well, Svelte. Both have been designed to adapt to any hosting platform, whether it's serverless or Edge optimized, or a regular Node.js server.
  - xrd 5y ago
    Yes, my intention with the question was that Remix seems to be saying we have some special optimizations that make this edge-native, which I interpreted to mean, we make React work magically better on the edge. There has always been a problem with taking front-end code and making it talk to the backend, and when you add a new backend like workers (and start storing data inside CloudFlare KV, etc) then it suddenly looks more and more complicated. After reading about Remix, it seems like they are suggesting they make it so your React hooks have some special logic that makes them work with edge compute more seamlessly. I know SvelteKit is thinking about the same kind of thing (with SSR, for example) and loader functions but I don't know enough about either to compare them.
teeray 5y ago
There really should be a sentence early on describing what Remix is. I thought it was a gem or something.
qudat 5y ago
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. 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.
vosper 5y ago
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. 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.
- dmitriid 5y ago
  > plus the minimum JS that’s needed for interactivity. remix's landing page uses 270 KB of Javascript split into 15 chunks. And it's static text with a couple of images. minimum
- tshaddox 5y ago
  Remix has no partial hydration features, right? Presumably it will work fine with React 18’s SSR Suspense features, but I’m not aware of any partial hydration features in Remix. Of course you can easily turn off JavaScript altogether in Remix by not including script tags in the HTML, but that’s not partial hydration.
  - andrewingram 5y ago
    I believe you're right, Remix has no such features. Ultimately Remix can be thought of as a compiler that eliminates a lot of the boilerplate for which we could already do perfectly well back in 2015 (ish) with React Router 2 and 3. 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.
  - vosper 5y ago
    Looks like you are correct, I don't know where I got the idea that Remix does partial hydration from: https://github.com/remix-run/remix/discussions/680 https://github.com/remix-run/remix/discussions/680
Zababa 5y ago
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. 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://redwoodjs.com/, https://news.ycombinator.com/item?id=22537944 https://news.ycombinator.com/item?id=22537944 [2]: https://remix.run/ https://remix.run/ [3]: https://remix.run/docs/en/v1/pages/philosophy https://remix.run/docs/en/v1/pages/philosophy
- qudat 5y ago
  The current trend in the react ecosystem is to move more towards a "traditional" website where more of the code will be run on the server. 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.
- porker 5y ago
  > 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. 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...
cientifico 5y ago
Rails was done by a product guy to solve one need. Most of the "the new rails" challengers are made by engineers. 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.
- vosper 5y ago
  > So far, any framework I saw that claims to be the new rails, is speaking about features and the million things you can do. I don’t think Remix themselves are claiming to be the new Rails.
- raihansaputra 5y ago
  I very much agree. The fact that Rails (`master/main` branch even) is used unmodified by Basecamp, Shopify, and GitHub (and maybe GitLab), and features are added by extracting implementation from running apps, Rails just comes from and developed by very different needs than Remix in this example.
  - ksec 5y ago
    Not Gitlab, they stick to stable branch and upgrade tends to be latest version minus one. Although I do hope they hop on to the train.
    - raihansaputra 5y ago
      Using actual stable branches is still a very good sign. Instagram forked their own Django and Python. Stable Django is used by some companies too, though (Sentry for example).
- 5y ago
dmitriid 5y ago
> 16 years ago, David Heinemeier Hansson (DHH) took the stage and delivered one of the most impressive code demos the world has ever seen. 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. [1] https://www.youtube.com/watch?v=MZvmYaFkNJI https://www.youtube.com/watch?v=MZvmYaFkNJI
- jack_riminton 5y ago
  Exactly, just use rails
- nsonha 5y ago
  anyone can give us a run down what was demoed? I find the claim that first version of Rails beats EVERYTHING in existence today (except Phoenix you said, does that mean Phoenix is superior than everything else?) very dubious.
  - dmitriid 5y ago
    The original "How to build a blog in 15 minutes with Rails" from 2005: https://www.youtube.com/watch?v=Gzj723LkRJY https://www.youtube.com/watch?v=Gzj723LkRJY 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.
    - nsonha 5y ago
      I didn't say javascript. other languages exist you know. 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
      - dmitriid 5y ago
        > I build my blog in next in like 5 mins and dont need to spin up a freaking db for it. 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.
robertwt7 5y ago
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? 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..
- gherkinnn 5y ago
  Agreed. Remix is pretty good for what it is, but it lacks a lot to be a “one person framework”. A database, for example.
  - vosper 5y ago
    Which one-person frameworks include a database? Or do you mean that they have their own DAL included, like Django does?
    - gherkinnn 5y ago
      You are correct. I lazily used “db” instead. Remix still requires an API.
- deleted 5y ago
  [deleted]
deleted 5y ago
[deleted]
dinosaurs 5y ago
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.
- rio517 5y ago
  What's your take on Elixir/Phoenix?
- thr0wawayf00 5y ago
  Agreed, and as innovative as react was for web app development, I find myself hoping that something like Svelte takes off instead. Not having to deal with the virtual DOM, JSX, etc. is the next big barrier for app development IMO, it's just an unnecessary layer of complexity now that build tooling and browsers are catching up.
- weaksauce 5y ago
  and it just came out with a fairly significant update in the last few days too. exciting times, that
dadro 5y ago
The optics of the site currently being down does not instill much confidence in wanting to use this in production.
- mbavio 5y ago
  Hey, it's back up now, just so you know, it had nothing to do with the technology itself and a lot to do with me not doing a proper job at coding: https://news.ycombinator.com/item?id=29613528 https://news.ycombinator.com/item?id=29613528
AtroxDev 5y ago
I'm getting the following on visiting the page, couldn't have said it better: > Unexpected Server Error > Cannot destructure property 'series' of 'e' as it is undefined.
- qnsi 5y ago
  welcome to javascript
  - mbavio 5y ago
    Hey, OP here. The site was down because it exceeded the API calls limit of the headless CMS I'm using. 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!
rmetzler 5y ago
HTTP 500 Unexpected Server Error Cannot destructure property 'series' of 'e' as it is undefined.
- mbavio 5y ago
  Thank you for reporting it, should be back to normal now!
0x142857 5y ago
this is ironic https://s2.loli.net/2021/12/18/E7faXl2AnVbr5W9.png https://s2.loli.net/2021/12/18/E7faXl2AnVbr5W9.png
strogonoff 5y ago
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.
tao_oat 5y ago
The article seems to be suffering from the Hacker News effect. Here's a mirror: https://web.archive.org/web/20211218090314/https://marbiano.dev/into-remix/on-rails https://web.archive.org/web/20211218090314/https://marbiano....
- mbavio 5y ago
  Thank you for adding the link, you are a life savior! Indeed it was the HN effect, but in a very weird way as I described here: https://news.ycombinator.com/item?id=29613528 https://news.ycombinator.com/item?id=29613528
cutler 5y ago
Blitz.js is the real contender for the Rails in JS crown not Remix or Redwood.
- acemarke 5y ago
  Ironically, a couple days ago the Blitz lead posted an RFC proposing that they shift from being a fork of Next to being a separate lib focusing on the data/auth layer: https://github.com/blitz-js/blitz/discussions/3075 https://github.com/blitz-js/blitz/discussions/3075
deleted 5y ago
[deleted]

Remix: On Rails

95 points by goranmoomin 5y ago

lefrenchy 5y ago

I may have missed it, but what makes Remix able to run SSR at the edge? Can you not do that with NextJS?

Rauchg 5y ago
You absolutely can! The data loader concept in Remix is semantically equivalent to `getServerSideProps` 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 https://vercel.com/edge)
- DenseComet 5y ago
  I was under the impression that most of Next's server side capabilities, outside of the recently introduced middleware and react server components, required a node environment. I know Vercel does offer multiregion capabilities for enterprise and a bunch of smart things to make sites faster, but its still not the same as being able to do everything on edge the way remix advertises.
Tomuus 5y ago
One of my favourite things about Remix, and where it beats Next IMO, is that you can deploy it anywhere. Bring your own server. Whereas trying to deploy Next.js anywhere other than Vercel is a nightmare.
- playpause 5y ago
  > Whereas trying to deploy Next.js anywhere other than Vercel is a nightmare. I’ve never heard this before. Why is it a nightmare? Isn’t it just a Node app?
- jstummbillig 5y ago
  > 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 https://nextjs.org/docs/deployment#nodejs-server
- nsonha 5y ago
  I made my blog with Next.js which is deployed with github actions on gh pages, there was some tricky thing about static paths but that might have been fixed and if it was anywhere close to "a nightmare", I would remember.
- andrewingram 5y ago
  This is (mostly) untrue. It's easy to deploy Next anywhere you can run a node server. What's more fiddly is deploying it somewhere that has its own special environment, like AWS Lambda, Cloudflare Workers, Netlify etc; basically "serverless". But adaptors do exist for most of these to make it fairly painless, they're just not part of Next itself. 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.
- freedomben 5y ago
  I run 3 non trivial Next.js apps in prod. While I have used Vercel in the past, I'm not currently. One is completely SSG (served by nginx) which is absolutely amazing and is the killer feature that keeps me going back to next.js. The other two have node because they use next/Image. I do really wish there were a compatible Image with SSG, but it is absolutely not hard to run a node app in prod, and there's no difference between a node app and a next.js that needs node.

jackconsidine 5y ago

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. [1] https://koptional.com/article/remix-fullstack-paradigm-pros-and-cons.html#a-short-intro https://koptional.com/article/remix-fullstack-paradigm-pros-...

fastball 5y ago
Is Remix really moving away from REST + SPA? 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.
- vosper 5y ago
  There’s no REST in Remix, at least not in the original sense of REST. 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)

syspec 5y ago

Is this a backend framework built on top of NodeJS? It looks slick, but I can't find the backend docs

jackconsidine 5y ago
It's actually a full-stack framework. The Remix build process effectively splits it into a separate frontend and backend, though single files have both bits of code

tshaddox 5y ago

> 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. 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).

xrd 5y ago

I would love to hear someone compare this to SvelteKit, and their different adaptors, like Vercel or Cloudflare workers. i.e.: https://developers.cloudflare.com/pages/framework-guides/deploy-a-svelte-site https://developers.cloudflare.com/pages/framework-guides/dep...

leerob 5y ago
Remix uses React. SvelteKit uses, well, Svelte. Both have been designed to adapt to any hosting platform, whether it's serverless or Edge optimized, or a regular Node.js server.
- xrd 5y ago
  Yes, my intention with the question was that Remix seems to be saying we have some special optimizations that make this edge-native, which I interpreted to mean, we make React work magically better on the edge. There has always been a problem with taking front-end code and making it talk to the backend, and when you add a new backend like workers (and start storing data inside CloudFlare KV, etc) then it suddenly looks more and more complicated. After reading about Remix, it seems like they are suggesting they make it so your React hooks have some special logic that makes them work with edge compute more seamlessly. I know SvelteKit is thinking about the same kind of thing (with SSR, for example) and loader functions but I don't know enough about either to compare them.

teeray 5y ago

There really should be a sentence early on describing what Remix is. I thought it was a gem or something.

qudat 5y ago

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. 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.

vosper 5y ago

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. 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.

dmitriid 5y ago
> plus the minimum JS that’s needed for interactivity. remix's landing page uses 270 KB of Javascript split into 15 chunks. And it's static text with a couple of images. minimum
tshaddox 5y ago
Remix has no partial hydration features, right? Presumably it will work fine with React 18’s SSR Suspense features, but I’m not aware of any partial hydration features in Remix. Of course you can easily turn off JavaScript altogether in Remix by not including script tags in the HTML, but that’s not partial hydration.
- andrewingram 5y ago
  I believe you're right, Remix has no such features. Ultimately Remix can be thought of as a compiler that eliminates a lot of the boilerplate for which we could already do perfectly well back in 2015 (ish) with React Router 2 and 3. 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.
- vosper 5y ago
  Looks like you are correct, I don't know where I got the idea that Remix does partial hydration from: https://github.com/remix-run/remix/discussions/680 https://github.com/remix-run/remix/discussions/680

Zababa 5y ago

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. 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://redwoodjs.com/, https://news.ycombinator.com/item?id=22537944 https://news.ycombinator.com/item?id=22537944 [2]: https://remix.run/ https://remix.run/ [3]: https://remix.run/docs/en/v1/pages/philosophy https://remix.run/docs/en/v1/pages/philosophy

qudat 5y ago
The current trend in the react ecosystem is to move more towards a "traditional" website where more of the code will be run on the server. 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.
porker 5y ago
> 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. 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...

cientifico 5y ago

Rails was done by a product guy to solve one need. Most of the "the new rails" challengers are made by engineers. 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.

vosper 5y ago
> So far, any framework I saw that claims to be the new rails, is speaking about features and the million things you can do. I don’t think Remix themselves are claiming to be the new Rails.
raihansaputra 5y ago
I very much agree. The fact that Rails (`master/main` branch even) is used unmodified by Basecamp, Shopify, and GitHub (and maybe GitLab), and features are added by extracting implementation from running apps, Rails just comes from and developed by very different needs than Remix in this example.
- ksec 5y ago
  Not Gitlab, they stick to stable branch and upgrade tends to be latest version minus one. Although I do hope they hop on to the train.
  - raihansaputra 5y ago
    Using actual stable branches is still a very good sign. Instagram forked their own Django and Python. Stable Django is used by some companies too, though (Sentry for example).
5y ago

dmitriid 5y ago

> 16 years ago, David Heinemeier Hansson (DHH) took the stage and delivered one of the most impressive code demos the world has ever seen. 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. [1] https://www.youtube.com/watch?v=MZvmYaFkNJI https://www.youtube.com/watch?v=MZvmYaFkNJI

jack_riminton 5y ago
Exactly, just use rails
nsonha 5y ago
anyone can give us a run down what was demoed? I find the claim that first version of Rails beats EVERYTHING in existence today (except Phoenix you said, does that mean Phoenix is superior than everything else?) very dubious.
- dmitriid 5y ago
  The original "How to build a blog in 15 minutes with Rails" from 2005: https://www.youtube.com/watch?v=Gzj723LkRJY https://www.youtube.com/watch?v=Gzj723LkRJY 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.
  - nsonha 5y ago
    I didn't say javascript. other languages exist you know. 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
    - dmitriid 5y ago
      > I build my blog in next in like 5 mins and dont need to spin up a freaking db for it. 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.

robertwt7 5y ago

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? 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..

gherkinnn 5y ago
Agreed. Remix is pretty good for what it is, but it lacks a lot to be a “one person framework”. A database, for example.
- vosper 5y ago
  Which one-person frameworks include a database? Or do you mean that they have their own DAL included, like Django does?
  - gherkinnn 5y ago
    You are correct. I lazily used “db” instead. Remix still requires an API.
deleted 5y ago
[deleted]

deleted 5y ago

[deleted]

dinosaurs 5y ago

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.

rio517 5y ago
What's your take on Elixir/Phoenix?
thr0wawayf00 5y ago
Agreed, and as innovative as react was for web app development, I find myself hoping that something like Svelte takes off instead. Not having to deal with the virtual DOM, JSX, etc. is the next big barrier for app development IMO, it's just an unnecessary layer of complexity now that build tooling and browsers are catching up.
weaksauce 5y ago
and it just came out with a fairly significant update in the last few days too. exciting times, that

dadro 5y ago

The optics of the site currently being down does not instill much confidence in wanting to use this in production.

mbavio 5y ago
Hey, it's back up now, just so you know, it had nothing to do with the technology itself and a lot to do with me not doing a proper job at coding: https://news.ycombinator.com/item?id=29613528 https://news.ycombinator.com/item?id=29613528

AtroxDev 5y ago

I'm getting the following on visiting the page, couldn't have said it better: > Unexpected Server Error > Cannot destructure property 'series' of 'e' as it is undefined.

qnsi 5y ago
welcome to javascript
- mbavio 5y ago
  Hey, OP here. The site was down because it exceeded the API calls limit of the headless CMS I'm using. 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!

rmetzler 5y ago

HTTP 500 Unexpected Server Error Cannot destructure property 'series' of 'e' as it is undefined.

mbavio 5y ago
Thank you for reporting it, should be back to normal now!

0x142857 5y ago

this is ironic https://s2.loli.net/2021/12/18/E7faXl2AnVbr5W9.png https://s2.loli.net/2021/12/18/E7faXl2AnVbr5W9.png

strogonoff 5y ago

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.

tao_oat 5y ago

The article seems to be suffering from the Hacker News effect. Here's a mirror: https://web.archive.org/web/20211218090314/https://marbiano.dev/into-remix/on-rails https://web.archive.org/web/20211218090314/https://marbiano....

mbavio 5y ago
Thank you for adding the link, you are a life savior! Indeed it was the HN effect, but in a very weird way as I described here: https://news.ycombinator.com/item?id=29613528 https://news.ycombinator.com/item?id=29613528

cutler 5y ago

Blitz.js is the real contender for the Rails in JS crown not Remix or Redwood.

acemarke 5y ago
Ironically, a couple days ago the Blitz lead posted an RFC proposing that they shift from being a fork of Next to being a separate lib focusing on the data/auth layer: https://github.com/blitz-js/blitz/discussions/3075 https://github.com/blitz-js/blitz/discussions/3075

deleted 5y ago

[deleted]