Today the Remix Run Supporter Preview finally launched. Remix is a new React framework.
One of the thing that excites me the most about Remix is t...
For further actions, you may consider blocking this person and/or reporting abuse
Nice writeup, Nader!
One thing I'm still confused about, what's the difference between this and Next.js, or other up-and-coming meta React frameworks like RedwoodJS or Blitz.js? I've read a few pieces on Remix and can't for the life of me figure out what the value proposition is over these free and open source alternatives.
The most striking difference between Remix and Next is that Remix supports Nested Routes.
In Next.js each route is totally independent so when you transition to a route all previous components get unmounted and the next page's components get mounted.
Suppose you render a sidebar in /dashboard. When you go to /dashboard/admin that sidebar won't exist now. To sidestep this issue you'd make layout components and reuse them in every route. However, since the component gets unmounted during the transition they will lose their internal state. If the sidebar had a search field and the user had entered some text in it, that text will be lost on page transition.
In Remix, since it supports nested routes you can choose which part of the dashboard page remains for /dashboard only and which part remains the same for /dashboard and /dashboard/admin. This is a lot less wasteful IMO.
Another benefit of nested routes is that you can get granular data from your loaders. If a user goes from /dashboard to /dashboard/admin, the data of /dashboard need not sent again.
This is just what I've gathered from reading the newsletter. I expect a lot of innovations on top of nested routes.
Regarding comparison with Blitz- Blitz is a framework built on top of Next.js and it owns even more of your stack. Its aim is to give you Ruby on Rails like developer productivity. It includes doing database queries and other superb stuff out of the box. I expect something like it can be built on top of Remix too.
I'm not sure if that's entirety true. Next.js SSR on internal routing would not request a new page/HTML, instead it requests the JSON output of the getServerSideProps of the new page, and then Next.js on the client end, hydrates your new page using that JSON.
Hi Ahmad!
You're totally right in what you're saying. However, the intention of my comment had nothing to do with requesting new HTML. It might have come across that way. Can you point me to the line which is false in my comment?
I'm not trying to point where you're false or not. 😂
I think you believe that the entire page render happens again and again with Next.js which I believe is not true.
SSR DIRECT PAGE REQUEST
When you request this page directly (by entering the page URL in the browser), the page is pre-rendered by the server and sent to the client.
STEP #1: Server pre-renders the page with dynamic data
STEP #2: Client shows the pre-rendered page
SSR CLIENT-SIDE PAGE REQUEST
When you request this page on the client-side page transitions through next/link or next/router (by clicking an internal link on a page)
STEP #1: Next.js sends an API request to the server
STEP #2: Server runs the getServerSideProps
STEP #3: Server returns resulting JSON as a response
STEP #4: Next.js uses this JSON response to render the page
Now mix this with SSG where parts of your page are static. Like you mentioned the sidebar. That can be completely static with no JavaScript at all. Hence creating a hybrid SSR, CSR, SSG page with Next.js can improve perf a lot here.
I think by the word 'render' we're talking different things. By render I just mean re-render of React component. It has nothing to do with going to server. I'm just saying components of dashboard page won't render on dashboard/about by default so you need Layout components. But that leads to an issue of loosing internal state even though its a client side transition.
I think Adam has explained the problem really well.
adamwathan.me/2019/10/17/persisten...
You can handle that with React memorization to a point. The concurrent mode would make things much better. But hey, I get what you mean.
But the point being made is that the way components are NOT reused in every route, and sharing the data between components when it comes to nested routing of remix is way more convenient. Static Rendering/SSR is an entirely different topic and it has to do nothing with routing ain't it?
SSR has a lot to do with routing when you use Next.js. There's a difference in how routing works when you have an SSR page with Next.js.
How does SSR have anything to do with routing? I think the first user that replied to my comment made a fair point, it's something that I've struggled with personally, and afaik, that has nothing to do with whether or not a page is server-side rendered. Afaik very page component in NextJS gets unmounted before the next page component is mounted, whether or not the page is SSR'd.
Thanks for sharing your early evaluation of the product Nader. It’s interesting that they expose the request and response and the route story is pretty interesting using parameters as part of the file name. I wonder if they will delve into static site generation (SSG) to be embraced in the Jam Stack ecosystem. I saw Jay Phelps talk yesterday about ESR (Edge Slice Rerendering), so I’ve got that on the brain too. 🧠
Looking forward to your next post!
I need to check that talk out!! Thanks for sharing.
I've heard about Remix, but never tried it out and I probably never will either given the fact that it's paid-only. Maybe that will only be the case till they're production-ready? I really don't know.
If they plan on doing this post-production, it will just introduce segregation to a community that is already struggling with finding good solutions to problems and hence fail as a solution.
The problems that Remix attempts to solve are already solved by frameworks like NextJS (can't say for sure because I just read their docs) and NextJS, in particular, has a very bright future (attended the NextJS conf and it was brilliant). There are plenty of free alternative solutions to the problems Remix has outlined if frameworks like NextJS are overkill.
What would be great is if they focused more on their value proposition or how they plan to solve problems better/differently compared to existing solutions. That way it's easier for us as devs to make a decision as to whether or not Remix is something we should be excited about.
I explain the difference between Remix and Next here dev.to/itaditya/comment/17blp
Do you think going back to SSR is a step back from the JAMStack, or do you think it's simply for other kind of applications?
I think that Jamstack is starting to become an outdated term, especially with the advancements you're seeing that move out of the static world and into the hybrid world (though I'm sure the people making $ off of Jamstack will probably evolve their "definition" to suit their needs). I think that something like Remix would be ideal as a replacement for something like a traditionally server-rendered site that has highly dynamic data and a lot of routes. So maybe for instance a replacement for a rails, python, or PHP site. I don't think it really competes with Next.js as it doesn't offer SSG (this is of course just my take).
What do you mean by outdated?
I had the impression that JAMStack always was hybrid (CSR+SSG).
I think that most people consider only SSG to be Jamstack (but some consider Next.js to also be, even with the hyvbrid approach), and have read stuff from people at Netlify (like this post) that drive that message home, but I think they'll be evolving that definition IMO as the modern web continues to evolve.
I see.
Thanks for your insights :)
I could not agree more :).
By the way, what do you think of Next.js 10?
Regardless of how you feel about the pricing, it really is one hell of a bold approach to monetizing OSS. I have a feeling it will take off.
Thank you , Nadar. This is a good start for the developers.
I want to try my hands on it...though 250 USD just to try would be a huge cost.
Excellent review, Nader. I'm actually knee deep in the documentation already. Looks interesting. 👌
Thanks for the post, this helps a lot in understanding the base idea and concept of remix. 🎉
Great to hear!!