Why is slow route transition which is waiting on the loader to resolve all data better than a SSG site?

[vidrepar]

Why is slow route transition which is waiting on the loader to resolve all data better than a SSG site?

When I go from my index page to the /posts page and I'm waiting for my loader to resolve all async data next things happen on the client:

1. Route changes right away
2. Old data is still shown; New page component is still not loaded
3. The new page is rendered once loader resolves

There's this slow/strange behavior in case there's a slow call to a 3rd party service inside of my loader. I tried to find resources that address this in remix but no luck. Isn't it better to have a SSG site in this situation?

What am I missing?

[hollandThomas]

Remix does not solve this by itself. In short, you will need to make your backend fast. That can entail any number of things. In your case, if a 3rd party service is consistently slow, you probably want to add some caching layer on your server for that service.

If this is unfamiliar to you, a Google search for "Node.js Redis API Cache" should yield some good results. It might even be a good idea to add an appropriate example to this repo

[ccssmnn]

@hollandThomas is right.

Remix does only SSR on each request. This makes developing a remix app straightforward. For performance reasons, you would enable caching. There is a great video about http caching and different caching strategies here

SSG is just caching at built-time. With remix, you would cache responses at runtime.

Being able to serve cached content right from the CDN is as fast as it gets. When you want to serve fresh content fast, you need to make your data sources fast to reduce the time remix is waiting for the data before rendering the page. But as you have mentioned SSG, you would probably Cache on the CDN.

What am I missing?

Only allowing one rendering strategy makes remix so simple and enjoyable. Caching, Edge-Computing, Fast Datasources will do the rest when it comes to performance.

[vidrepar]

Thanks for explanations @ccssmnn , @hollandThomas,

I love a lot about Remix.

I've tried caching (eg "Cache-Control": "max-age=300, s-maxage=3600" ) and it works great. However, that behavior will still happen if the site is not cached (1st time or after a certain period of time).

Yes, Redis or Cache on the CDN might solve this better, but then, the simplicity that Remix is being sold on is not that simple anymore. Syntax yes, overall DX not so anymore.

Where's the simplicity when I have to:

• setup performance monitoring from the get-go
• deal with cache from the get-go
• and do performance optimizations from the get-go

Especially from the beginning, most of the projects don't have the resources to afford this.

To be clear:

• I'm not saying that Remix's approach is not the future.
• I'm not saying you shouldn't cache in any way or do performance optimizations.

[ccssmnn]

What I like is "the flow", sorry, I don't have another word for that. Remix follows one way of generating pages, loading data, dealing with mutations. This one way is suitable for requirements I have faced so far. The simplicity is, that it's this one way. Let me describe it.

When I build a route:

1. What data do I need? → Loader
2. What should it look like? → export default.

Your page with fresh content on every request is ready, even without any client-side JS, if you want. Simple. But then:

• Do I require mutations? → Action + Form
• Can I cache the content? → headers

Every piece is additive and only adds its own minimal layer of complexity. Especially, the communication back to the server with actions is a breeze. And you are free to do whatever you can imagine for every route.

Other frameworks might feel simpler for one specific use case, but only because they have made the decisions for you, abstracting them away. When you want to change the default behavior, you fall into a hole of complexity, if it is even possible to change it. Let me describe, why I prefer the remix flow against two other frameworks I worked with.

Coming from Gatsby:

1. What data do I need?
2. Public data? → Find a Gatsby Plugin or manually integrate the data into the Gatsby Data Layer
3. Private Data? → No SSG Possible. Go with CSR.
4. What should it look like?
5. Is it a page or a template? → Define look in pages or templates folders, different usage for SSG
6. Do I show "private data"? → Send Statically generated spinners until I can fetch data on the client.
7. Is the private UI more complex? → Now I have to deal with client-side routing as well.

• Do I require mutations? → custom API route in another file, manual communication, suddenly requires a different deployment
• Can I cache the content? → Statically generated pages are fine. But what about APIs for private data?

Coming from NextJS:

1. What data do I need?
2. Is it static? → getStaticProps
3. Is it dynamic? → getServerSideProps
4. Is it private? → Fetch in on the client with swr + API route in another file or use getServerSideProps, they recommend swr.
5. What should it look like? → export default

• Do I require mutations? → custom API route in another file, manual communication
• Can I cache the content? → Tricky, set custom headers per route in next.config.js or change your SSG to ISR

Most paths you choose with Gatsby / NextJS will have a negative impact on the UX because you send more javascript, only show content, after you fetched data on the client and so on. The DX suffers because there are so many ways for different requirements. Remix handles them all with one way of approaching your app.

[sergiodxa]

@ccssmnn that comment should be a blog post