Remix: On Rails(marbiano.dev)
marbiano.dev
Remix: On Rails
https://marbiano.dev/into-remix/on-rails
88 comments
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.
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.
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).
> 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.
I don’t think Remix themselves are claiming to be the new Rails.
Rails is an open source sourftware with hundreds if not thousands of contributors, its at version 7 now, if you think it's been "written by a product guy" you don't know what you're saying.
I think he was referring to the genesis of Rails, not the evolved product.
[deleted]
Rails was originally created for, most intents and purposes, of building Basecamp and solving Basecamp problems. That's why Rails is good at building things that are similar to Basecamp and adjacent use cases.
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.
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.
IIRC Rails was actually extracted from Basecamp. The "DHH makes a blog" video was the hello world demo that made Rails famous.
I used to work for Highrise (after it spun out from Basecamp), and if you looked through the early commits, there was definitely some functionality that were ancestors of Rails features.
And DHH is a software engineer. The grandparent comment sounds like he isn't.
He's a software engineer with a business background (his degree is from Copenhagen Business School), who thinks about problems both ways.
Purely anecdotally, but there's a weird thing with software engineering and architecture where it's heavily linguistic compared to older engineering disciplines.
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.
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.
DHH is a business person that solves problems, who just happens to know how to write code :)
DHH is a software writer :)
This isn’t how I see it really. It doesn’t make sense to label DHH as just a product guy. He is an engineer that designed a software framework.
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.
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.
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.
> Unexpected Server Error
> Cannot destructure property 'series' of 'e' as it is undefined.
welcome to javascript
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!
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!
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.
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.
What's your take on Elixir/Phoenix?
and it just came out with a fairly significant update in the last few days too. exciting times, that
> 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).
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).
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.
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.
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.
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
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.
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.
NextJS also does the same thing, it's just server side rendering
Big difference from what I can see with my 2 hours with remix vs my hundreds of hours with Next is that you can do it on a component by component basis instead of a page by page bases. Also, POSTing data is a whole different beast.
Partial hydration is not the same thing as what NextJS does, but, as others have pointed out, I was wrong about Remix doing partial hydration.
> 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
remix's landing page uses 270 KB of Javascript split into 15 chunks. And it's static text with a couple of images.
minimum
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://news.ycombinator.com/item?id=22537944
[2]: https://remix.run/
[3]: https://remix.run/docs/en/v1/pages/philosophy
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/
[3]: https://remix.run/docs/en/v1/pages/philosophy
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.
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.
> 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...
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...
The optics of the site currently being down does not instill much confidence in wanting to use this in production.
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
The article seems to be suffering from the Hacker News effect. Here's a mirror: https://web.archive.org/web/20211218090314/https://marbiano....
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
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..
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..
[deleted]
Agreed. Remix is pretty good for what it is, but it lacks a lot to be a “one person framework”. A database, for example.
There really should be a sentence early on describing what Remix is. I thought it was a gem or something.
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.
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.
Blitz.js is the real contender for the Rails in JS crown not Remix or Redwood.
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
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/dep...
i.e.: https://developers.cloudflare.com/pages/framework-guides/dep...
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.
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.
> 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
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
What about Laravel? I haven't used Rails or Laravel, but I am currently evaluating Laravel. It seems like it does exactly the same as Rails. Laravel got Livewire.
In my country Ruby/Rails was never a thing, so hiring and building a team would require a lot more effort.
In my country Ruby/Rails was never a thing, so hiring and building a team would require a lot more effort.
Exactly, just use rails
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.
The original "How to build a blog in 15 minutes with Rails" from 2005: 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.
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 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
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
> 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.
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.
> things unachievable with most (or all?) current frameworks.
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
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
> What things?
Let me quote that for you:
--- start quote ---
building a fully-functional DB-enabled app in under 15 minutes with introspection [etc].
--- end quote ---
Let me quote that for you:
--- start quote ---
building a fully-functional DB-enabled app in under 15 minutes with introspection [etc].
--- end quote ---
any framework can do that? Next can do that too, I only mentioned static web because i think it's pretty absurd to spin up a database for a blog.
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?
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?
Nest and django
Those are the name of 2 random frameworks, one js and one python, name ONE thing Rails can do that these cant
Those are the name of 2 random frameworks, one js and one python, name ONE thing Rails can do that these cant
> Nest and django
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 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"
> 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.
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.
[deleted]
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-...
[1] https://koptional.com/article/remix-fullstack-paradigm-pros-...
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.
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.
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)
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)
[deleted]
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.
Is this a backend framework built on top of NodeJS?
It looks slick, but I can't find the backend docs
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
I may have missed it, but what makes Remix able to run SSR at the edge? Can you not do that with NextJS?
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)
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)
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.
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.
Whereas trying to deploy Next.js anywhere other than Vercel is a nightmare.
> 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
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
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.
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 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.
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.
> 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?
I’ve never heard this before. Why is it a nightmare? Isn’t it just a Node app?
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.