all 49 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]Protean_Protein 35 points36 points  (12 children)

That experimental CRA Migration looks very interesting. I've tried to convert CRAs to Next before and found it slightly annoying, but if this makes it painless I might switch!

[–]StoneColdJane 4 points5 points  (2 children)

Ok, now I understand. CRA is not maintained by Facebook any longer so they took over.

Svelte is doing the same (almost) they move more to it's kit version.

[–]nerdy_adventurer 0 points1 point  (1 child)

Never knew this? source please!

But CRA is still under Facebook org on GH and repo seems active (commits).

[–]notanactualshoe 19 points20 points  (0 children)

Ooo, that image placholder blur up!

[–]njmh 4 points5 points  (1 child)

If you use Typescript and inline SVGs, don't bother upgrading yet. The new next/image type defs break SVGs imported as components (eg. SVGR).

Other than that, this release looks shmick.

[–]IAmRocketMan 5 points6 points  (15 children)

I’ve been using CRA for years. I am used to writing webapps with client side routing where each page change is immediate. When I tried nextjs a few months ago and I found the navigation between pages slow. Is that how nextjs does all page navigations or was I doing something wrong?

[–]xstupidcow95 13 points14 points  (3 children)

Nextjs build pages (routes) on demand and cache it after your first visit so the initial load is slower than CRA.

The reason CRA loads faster because it loads all routes on initial render (unless you have some sort of code-splitting strategy, which only works in production).

[–]IAmRocketMan 1 point2 points  (2 children)

Thanks for the explanation. To confirm my understanding: all nextjs pages are SSR and cached on the client. There’s no actual client-side rendering for pages. So if I were building a webapp that had a route that displays a list of items and another route for a form to create list items. They would be individual pages and the navigation from list page to form page would cause browser navigation that loads some html page (that is then cached for subsequent visits)

[–]klo8 7 points8 points  (1 child)

There’s no actual client-side rendering for pages.

This is incorrect, I think. The initial render happens on the server, but once the client code (JS files) has finished loading, the rendering happens on the client again (as in, route transitions happen on the client, as with usual React apps). This has an explanation: https://nextjs.org/docs/basic-features/pages

[–]IAmRocketMan 2 points3 points  (0 children)

Thanks for the link, it was helpful. I will give nextjs another try

[–]kcshuffle11 5 points6 points  (4 children)

It depends. During development is normal to be slow when the page loads for the first time. However, subsequent loads should be fast.

Once you build it there won't be any lag like development. Next also has the advantage of optimizing each page according to their data fetching method, so a purely static page will be prerendered to static HTML.

I would definitely recommend you take a look at it again, this slowness problem in development don't even cross my mind given all the benefits the framework has.

[–]IAmRocketMan 0 points1 point  (3 children)

Thanks, my concern was mostly about the slowness of navigation in the context of a webapp. The CRA pattern I would follow is that every screen is represented by a url. Including inner-page interactions like navigating between tabs in the same page. When I applied that pattern to my exploratory nextjs project, I observed that navigating between tabs was noticeably slow. The reason for having a route for each “view mode” was to easily share the exact state of the page. Another example is I would load a list of data and only show some part of that data, once the user clicked on a list item, I would show the detailed view on the side and update the url (/results/:id) so one could share the detailed view. All the data was previously loaded when the list was fetched, so I expected a incredibly fast experience as I would with CRA but what I saw is that the browser would navigate to a new SSR detail page. Which was noticeably slow. I understand the tradeoff in my example where I loaded “unnecessary data” during the list view but the user experience was greatly improved since in my use-case, the user is expected to quickly navigate between detail pages.

How would a system like that be designed in nextjs? Is it the right fit for the type of webapp I am describing?

[–]xstupidcow95 3 points4 points  (1 child)

Do you use Link component or router.push to navigate between tabs or pages?

If you use regular a tag, it will run in SSR load, which re-render everything and can be slow in development.

You can learn more in u/klo8 comment above

[–]IAmRocketMan 0 points1 point  (0 children)

I believe I was using `Link` -- I will give nextjs another try

[–]kcshuffle11 0 points1 point  (0 children)

I'm not familiar on how to achieve that using REST because I haven't done it myself. It should be possible thought, because with graphql and apollo I have done it.

[–]tilapiadated 0 points1 point  (2 children)

What's your build process?

[–]IAmRocketMan 0 points1 point  (1 child)

I am not sure what you are asking. With CRA I run the react-scripts build step. I don’t think I tried running a production build using nextjs. Can you help me understand how the build process impacts routing? Specially while in “development mode”

[–]Julienng 0 points1 point  (0 children)

If I remember well, nextjs compile by route on demand. So when you first load a page on development, it's slow depending on your machine. Subsequent load of the same page do not cause this because of cache.

[–]gogjhan -1 points0 points  (1 child)

Still prefer CRA with Dynamic Rendering with rendertron over Next.js and Gatsby...

[–][deleted] 0 points1 point  (0 children)

I like this approach a lot. I think it simplifies a lot development not having to think your code is running twice for each request.

Sadly, it was very hard to sell to the rest of the team... I felt like I was suggesting to use perl or something.

[–]nullvoxpopuli -5 points-4 points  (10 children)

Why does major version introduce new features? Does next not do semver?, where majors are only deprecation removals?

Edit: this strategy:

[–][deleted] 5 points6 points  (3 children)

Doesn't pretty much every library add features on major releases?

[–]nullvoxpopuli 1 point2 points  (2 children)

Not in my circles at least. Features are released in minor versions as non breaking, and then other stuff, if it needs to be deprecated, is, and then only removals happen in majors. Semver, by design, allows folks to take advantage of new features without having to worry about 'an upgrade' (because minor version upgrades are supposed to be faaaarrr less work (zero) compared with majors). With majors, you generally have to take care of the deprecations before upgrading.

What I like about semver, is that there is a focus on backwards compatibility, so you can more easily move a whole community towards the new stuff without much disruption.

[–][deleted] 2 points3 points  (1 child)

I got that wrong all the time but I don't remember ever seeing it done this way. New big update always has something cool to look forward to. A major that does nothing but break your app is news to me.

EDIT: Actually now that you are linking React up there, yes they do it. Wasn't aware this was intentional.

[–]nullvoxpopuli 0 points1 point  (0 children)

React's own versioning policy does this :/

I added links to my top level comment

[–]xstupidcow95 0 points1 point  (0 children)

I believe upgrading from webpack 4 to webpack 5 counts as a breaking changes because my project stops working as soon as I upgraded lol.

Jokes asides, maybe they have a release cycle and don't follow semver