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.
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.
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.
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.
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.
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
> 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).
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.
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.
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.
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.
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.
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.
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.
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.
> 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...
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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
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?
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.
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.
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 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.
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
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.
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.
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:
88 comments
[ 3.0 ms ] story [ 178 ms ] threadWe 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.
I’ve never heard this before. Why is it a nightmare? Isn’t it just a Node app?
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.
[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)
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).
i.e.: https://developers.cloudflare.com/pages/framework-guides/dep...
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.
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's landing page uses 270 KB of Javascript split into 15 chunks. And it's static text with a couple of images.
minimum
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.
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
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...
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.
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.
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.
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.
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
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.
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.
> 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!
Unexpected Server Error
Cannot destructure property 'series' of 'e' as it is undefined.
https://s2.loli.net/2021/12/18/E7faXl2AnVbr5W9.png
https://github.com/blitz-js/blitz/discussions/3075