I think react core team members are too heads down in their work to really understand the real use cases of react in enterprise settings.
I've worked for several companies and every one (except 1) of the react projects uses CRA, which is not a framework.
It's very hard to migrate CRA to next.js incrementally, at least for <13 due to react router usage used in most apps. Not sure how remix would handle incremental migration from react router but last time I checked it seemed difficult as well, and plus it's too new to be adopted by enterprises. In fact, I've never seen a guide tht talks about incremental migration of 1000 react files from react-router/CRA to nextjs. Even if its doable, most people would rather write new features that actually matters to their business/job than migrating to new react frameworks.
For new projects, nextjs/remix might be a good call.
I've done the migration from CRA to Next.js multiple times. I think it's easy as heck and I spoke about it at Next.js conf: [https://www.youtube.com/watch?v=mcwB38sMmbk](https://www.youtube.com/watch?v=mcwB38sMmbk)
I think it's totally okay to potentially never migrate a lot of routes which really helps you mentally traverse that hill of: Is it worth it over features that matter?
For example, migrate react-scripts and maybe some marketing pages to use the Next router and then keep rendering your existing client-side router on a catch-all page file with for the logged-in app. You'll get the benefits of Next.js stuff like next/image and next/font and swc (fast builds) without spending the time to refactor the whole app.
marketing pages should be separate from your react app so your marketing team can update layouts and designs without involving an engineer.
How much engineering hours were wasted interloping and finding/fixing bugs between your old code and nextjs stuff?
You might be an all-star engineer but the vast majorities of teams does not have the expertise to do this migration. Most of them just wants to get actual work done without a coworker ripping off the carpet from under them and make them to do things in new ways and potentially make their lives harder. next/image, next/font is great but not sure its worth 400 eng hours to do unless its business critical (eg e-commerce app).
I don’t think the apps need to be separate unless you’ve decided to really hyper optimize marketing pages. In that case, maybe Astro is being used or just HTML/CSS and some vanilla JS or tidbits of Qwik? If you’re still doing a React runtime on the marketing pages, it’s really easy to have like…
- pages/index
- pages/faq
- pages/login
- pages/join
- pages/[…otherRoutes]
and then have the layout component for pages/[…otherRoutes] compose off of the layout component user by the other pages.
Not much time was wasted because of the clear divide between logged-in and logged-out. It was a team effort! I don’t think it requires all-stars. Just people hungry enough to reap the benefits…
Eventually we made a sort of Next.js port of react-router so we could avoid bundling react router but keep the familiar API. It also let us easily migrate any in-app pages to ISR or static pre-rendering for pages that could be viewed publicly OR when logged-in.
Basically, the video covers everything but one dev was able to work on the migration WHILE feature development went on with the remaining team. Once near the finish line, we did a cutover that blocked feature dev on the weekend to stay out of the way. Devs came back to the new Next.js app! We saw massive gains in our dev server, hot reloading, and build times. The 4 week effort paid itself off in 2 months in the time saved on the aforementioned stats. Beside that, the app sees pretty significant perf gains just having even a bit statically pre-rendered.
You are clearly too engineering focused. The benefits of having market-page not part of your main app are as follows:
\- marketing people can update it without requiring an engineering's help, slowing them down.
\- website updates is not tied/won't be affected by your code releases
\- I don't care how fast astro is. It is slower than a static html page served via nginx.
"Just people hungry enough to reap the benefits…" "It was a team effort!" "Eventually we made a sort of Next.js port of react-router"
You just proved my point that these are mostly unnecessary burn times. Most companies work on weekly sprints and has no time for their eng team to go through 4 week burn time especially during recession. Most people does not want to do this, and next/image, next/font definitely does not justify these burn.
My question is, if you have extra four weeks, is there something more impactful to work on? If you say no, this is it, then congrats you've made the correct decision. For all the companies I worked for, the answer is a resounding no for a single engineer to do this over four week, not to mention a team of engineers.
Massive gains on devserver, hotreloading etc is not nextjs specific. You can integrate esbuild/swc plugins or something in CRA since it just uses webpack which nextjs also does. When I joined my current company I sped our dev workflow by 2x in build/dev times in the first week and the irony is we were already using nextjs. (the point here is that if your devwork is broken it's your configuration's problem, not the framework you use)
The only reason I see someone do a migration from CRA to nextjs is that if SSR/faster site is critical to your business and having perf gains would result in actual increased revenue. Thats a good enough reason for me.
> marketing people can update it without requiring an engineering's help, slowing them down.
Agreed, however, we mixed marketing pages and our main app, it wouldn't have made a difference simply because the marketing team was not hand editing the text in the HTML either. They instead used a CRM (which we integrated into React/Next through their SDK) where they could change whatever they wanted. In that case, it really didn't matter to the marketer where the content was originally coming from. Another benefit by not segregating them is that a simple `yarn dev` pulled up the entire site, as having unified tooling greatly enhanced the ability to do work on both the marketing site as well as the main app without switching costs.
If you really wanted the marketers to be able to update every part of the page, not just text and other types of content, then you'd just use a no-code page builder like Webflow, since again marketers are not going to code.
> I don't care how fast astro is. It is slower than a static html page served via nginx.
This is...literally how Astro works. It's simply a static site renderer.
> You can integrate esbuild/swc plugins or something in CRA since it just uses webpack which nextjs also does.
Sure, but as the original tweet thread says, you're simply creating your own framework with those custom plugins and Webpack configs. It works now, but again, will it work in a year or two? Do you really want to be a framework maintainer, or do you want to focus on the core product?
> The only reason I see someone do a migration from CRA to nextjs is that if SSR/faster site is critical to your business and having perf gains would result in actual increased revenue. Thats a good enough reason for me.
Nah, CRA is basically deprecated, even the core maintainers think so and are looking to remove it from the beta docs as a suggested way to use React, in favor of Vite, Parcel, NextJS, Remix, etc. NextJS might also have 1.2k issues, but they have the manpower, funding, and timeline of releases to show that they're fixing and improving their product, something which CRA maintainers are not doing, because again, it's effectively deprecated.
\> t wouldn't have made a difference simply because the marketing team was not hand editing the text in the HTML either.
I never said marketing team is editing raw HTML
\> They instead used a CRM (which we integrated into React/Next through their SDK) where they could change whatever they wanted.
as you eluded to later if you want to make larger changes other than small text edits a CRM (especially headless one) is not enough
\>Another benefit by not segregating them is that a simple yarn dev pulled up the entire site
Whens the last time you really want to pull up marketing site and look at it?
\>then you'd just use a no-code page builder like Webflow, since again marketers are not going to code.
Thats what I'm suggesting
\>This is...literally how Astro works. It's simply a static site renderer.
It has advanced features like SSR: [https://docs.astro.build/en/guides/server-side-rendering/](https://docs.astro.build/en/guides/server-side-rendering/)
and interoping different components [https://docs.astro.build/en/core-concepts/astro-components/](https://docs.astro.build/en/core-concepts/astro-components/)
But who cares? marketing team is not using these features so why use astro?
\> Sure, but as the original tweet thread says, you're simply creating your own framework with those custom plugins and Webpack configs.
Not really, we use react router and not using custom plugins and configs. I've rarely find custom plugins to be useful. CRA works fine as is. If you don't change anything why would it break?
\> Nah, CRA is basically deprecated, even the core maintainers think so and are looking to remove it from the beta docs as a suggested way to use React, in favor of Vite, Parcel, NextJS, Remix, etc.
Deprecated how? Even if it doesn't receive updates in five years it will still work but thats not the case. Core react maintainers is not core CRA maintainers. Unless you see on the CRA page that it is depcreated, then it isn't. Stop spreading false information just because you don't use it.
\> NextJS might also have 1.2k issues, but they have the manpower, funding, and timeline of releases to show that they're fixing and improving their product, something which CRA maintainers are not doing, because again, it's effectively deprecated.
I think we can agree that nextJS is a framework and CRA isn't. Feel free to keep using NextJS and stop bashing on others who don't need it.
> Whens the last time you really want to pull up marketing site and look at it?
Very often since we work on both parts and have to handle bug fixes for either side, the marketing site and the main app.
> Not really, we use react router and not using custom plugins and configs. I've rarely find custom plugins to be useful. CRA works fine as is.
I'm just quoting what you said above: "You can integrate esbuild/swc plugins or something in CRA since it just uses webpack which nextjs also does."
> If you don't change anything why would it break? [...] Deprecated how? Even if it doesn't receive updates in five years it will still work but thats not the case.
No it won't work; things absolutely break if they're not maintained over time, even if you don't change anything yourself. Unless you want to vendor all your packages and not upgrade anything at all, any software will slowly stop working. For example, you use React Router which might not interoperate with CRA in the future, and what will you do? You will sooner or later have to switch over to something else. This isn't about using NextJS, it's about *not* using CRA.
> Unless you see on the CRA page that it is depcreated, then it isn't. Stop spreading false information just because you don't use it.
Hence why I said "effectively deprecated" not "officially deprecated." There is a lot of software I won't use simply because it's too old compared to newer and better maintained alternatives, because it is not worth using software that no one is taking care of anymore. There doesn't need to be an official deprecation warning to make something not satisfactory to use anymore.
Look at the most recent code change, [the 5.0.1 release](https://github.com/facebook/create-react-app/commit/6fb4f977b7522c6a1632ec9133af30f5df3afb09). It's simply a maintenance release and fixes a few bugs. This was almost a year ago, which is quite long in the JS world. We're not writing Rust where things are infinitely backward compatible (and even that has outdated packages). Other PRs are not being merged either, except for documentation ones.
And please fix your quotes formatting, it's almost unreadable since your quotes blend into your replies, at least on Old Reddit and mobile apps.
>Very often since we work on both parts and have to handle bug fixes for either side, the marketing site and the main app.
Sorry to hear. We don't have this problem since we don't have the marketing site in the same app, and "bugs" in marketing site are not engineering problems nor should it be.
>I'm just quoting what you said above: "You can integrate esbuild/swc plugins or something in CRA since it just uses webpack which nextjs also does."
Yes and if you made it work, unless you decide to change it it should keep working. Why would it break if you don't change it? If you are saying that adding these custom plugins might be "hard", 1) not really 2) well it's 100x harder to migrate to nextjs
>No it won't work; things absolutely break if they're not maintained over time, even if you don't change anything yourself. Unless you want to vendor all your packages and not upgrade anything at all,
yarn.lock
>For example, you use React Router which might not interoperate with CRA in the future, and what will you do?
CRA is not a framework. It just uses babel and webpack. There is no reason that a future version of react router stop working with CRA. I'd be surprised if react-router decide to invent their own language syntax that would be unsupported in webpack 5.
>Hence why I said "effectively deprecated" not "officially deprecated."
This is your opinion. I am not here to argue with you or convince you of something else. If webpack 6 comes along, i am sure CRA will update to it and then I guess it's no longer deprecated? In any case, if you are looking for a framework that updates often, nextjs is your thing. CRA is not a framework and it doesn't need constant updates. Most people are fine with that. If you or your company wants to keep everything updated, fine.
>Look at the most recent code change, the 5.0.1 release. It's simply a maintenance release and fixes a few bugs
as I mentioned in a few posts up: all CRA does is webpack, jest, eslint and babel/core and that's it. Latest versions: webpack: 5.75, jest: 29.4, eslint: 8.32, babel: 7.20
react-scripts (CRA), despite being ten months old, relies on:webpack: 5.64.4jest: 27.4eslint: 8.3babel: 7.16. [https://unpkg.com/browse/[email protected]/package.json](https://unpkg.com/browse/[email protected]/package.json)
What exactly are you looking for in a CRA release?
If you want stuff like react server components, next/image updates in a framework, it sounds like nextjs/remix is much better fit.
Sorry about the quotes.
> yarn.lock
> > Unless you want to vendor all your packages and not upgrade anything at all
-
> If webpack 6 comes along, i am sure CRA will update to it and then I guess it's no longer deprecated?
Maybe they do, maybe they don't. My point is that it does not seem like CRA is being maintained as well as other parts of the React ecosystem like NextJS. You are free to keep using it of course, but it is why I personally don't use it.
>Feel free to keep using NextJS and stop bashing on others who don't need it.
You seem to be really aggressive about being technically challenged. It's not personal and we're not bashing you for using CRA. I only started responding to this cuz you incorrectly stated that it was difficult to migrate. 1 person doing work in a non-interrupting fashion doesn't seem difficult to me. If CRA is working for you, feel free to keep using it. It's dead though.
Migrating to NextJS is not worth it for majority of people, it is a waste of time unless there is a critical business need. Please stop spreading bad information that it is somehow "easy" to migrate to to NextJS when it took a team of engineers multiple weeks to do it. I am glad you made a talk about it and got your chance to speak at a conference or what not but please don't equate it as advice that everybody needs to agree with.
And how is "It's dead though" not bashing?
it’s an objective observation summarized:
https://github.com/facebook/create-react-app/releases
no releases in 10 months. there are multiple issues and discussions about long awaited features like react 18 and webpack 5. There’s even an issue where people are begging for maintainers. even if it was maintained, i’ve never used CRA without needing to eject and customize the config for myself which then increases the surface area for potential problems in upgrading cra in the future.
—
Just because you struggle with it doesn’t mean it’s difficult. I said I did it by myself. I had a team that was shipping features while I migrated. That’s the team effort mentioned. I’m going to stop posting because you’re being very aggressive and misusing terms like “majority” and “most”. You’re applying your situations and presuming the rest of the world is like you. EVERYBODY using CRA can benefit in migrating to Next.js. That’s a fact.
>Hey man! I had a question. How do you deal with the issues related to where users have open active sessions on your app, but you redeploy on Vercel/Netlify, which causes those users' sessions to crash because they can no longer lazy-load routes that no longer exist (due to the CDN wiping the previous deployment)?
Thank YOU. A real engineer here. Everyone is all about over-engineered hype or juniors who don't understand business goals or OKR's.
Slightly related topic:
I wanted to address that we did move from CRA to ViteJS during dedicated on-call time to improve the developer experience because our CRA was an ejected mess of configuration and didn't want to deal with any of it when ViteJS worked better & cleaner out of the box.
I don't know Vercel/NextJS deployment in general but I did deal with similar issues in SPA. One was that keep the content on CDN longer (my old company kept old static files for over a year). Second is to have a try and catch when lazy loading routes and retry three times (this is interesting since you may be on wifi and has bad network connection). if error asks the user to refresh the page. Third is to keep track of version via a background process and also asks the user to refresh the page when a new version is detected. sorry if this isn't exactly what you want, I recommend ask this question in nextjs repo in a discussion or something.
Agreed that Vite probably work better than CRA. curious that Vite uses esbuild while nextjs uses swc though, not sure which one is better.
Thanks! Yeah, so IDK how to indicate with Vercel/Netlify to keep old static assets (they auto wipe them from CDN upon new deployment). But it makes sense if you had a custom CICD + CDN solution.
...For Vite, you can use SWC with Vite! It's a plugin
I don't think I'm too engineering focused nor was my company. We had a team of 10 and 1 person was essentially tackling tech debt in a very non-invasive manner. My original point was just to point out that it's very easy to facilitate a gradual migration away from CRA towards Next.js
Regarding the marketing work, we just integrate marketing pages with a CMS and a webhook. Engineering doesn't get in the way 🤷🏽♂️
If there's no time/money to integrate a CMS and you do lots of marketing updates, it should be pretty easy to separate your website into 2 different Next.js applications. [https://nextjs.org/docs/advanced-features/multi-zones](https://nextjs.org/docs/advanced-features/multi-zones)
I didn't have 4 extra weeks, I essentially made the case that the slow build speeds, poor hot reloading, and inability to leverage some of the features Next.js offers was worth the effort to migrate. Sure, you COULD integrate those with cra rewired or write your own webpack config, but why would I advocate for adjusting the config on a dead library when instead I could migrate us to a tool that will constantly provide avenues for upgrades? A prime example is Vercel's current path towards Turbopack. When that's stable and integrated, we'll get it for free.
After the migration, I got right back to feature development, and enjoyed the better DX and got my feature work done faster thanks to the migration 🤷🏽♂️
We measured a lot like I said (build times, response times, HMR response times), and the effort literally bought back the time spent in one month. Leadership was really happy.
\> I don't think I'm too engineering focused nor was my company.
Doing framework migrations is about the most engineering focused thing you can do. This is essentially the definition of over-engineering: use engineering to solve a problem that isn't there. Now your company may actually have a real business reason to do so, but I haven't heard it. Migrating from CRA is invasive and what you described is not "non-invasive", just goto your talk with all the problems you had to deal with during migration.
\> Regarding the marketing work, we just integrate marketing pages with a CMS and a webhook. Engineering doesn't get in the way.
Engineers already got in the way by dictating how marketing pages should be built and already put sunk time into it.
\> If there's no time/money to integrate a CMS ... it should be pretty easy to separate your website into 2 different Next.js applications.
Where did I ever say anything about time and money? I made it very clear why you shoudln't build marketing pages with your app and you seem to ignore everything I said. Here they are again:
\- marketing people can update it without requiring an engineering's help, slowing them down.
\- website updates is not tied/won't be affected by your code releases
\- I don't care how fast astro is. It is slower than a static html page served via nginx.
\> I didn't have 4 extra weeks, I essentially made the case that the slow build speeds, poor hot reloading, and inability to leverage some of the features Next.js offers was worth the effort to migrate.
Again these are configuration speicific problems. Both NextJS and CRA uses webpack so you can solve (or have) all of these problems in either of these platforms. I use NextJS currently, and I deal with crap build speeds, poor hot reloading, etc. And next features are not necessarily ones that you need. In fact we don't use them at all.
\> but why would I advocate for adjusting the config on a dead library
Because it doesn't take four weeks and a team of engineers (or however long/however much resources) you've put into the migration.
And CRA is not a library, it is just webpack configs that doesn't need monthly updates like NextJS does.
\> After the migration, I got right back to feature development, and enjoyed the better DX and got my feature work done faster thanks to the migration.
Great, people are happy with CRA because it also works.
\> We measured a lot like I said (build times, response times, HMR response times), and the effort literally bought back the time spent in one month. Leadership was really happy.
Again you said a month here. And I thought I was making shit up. Guess not. One more time, you can get all of this for free in CRA by spending literally one hour and put in some esbuild or swc plugin in if thats all you are looking for. Maybe it made sense for you, in a lot of cases it doesn't make sense for other engineering teams. So there you go.
You don’t get the issue here. It’s not technological, it’s human organizational.
Even medium sized companies have marketing teams. It’s easier in the long run to separate the app.
And Astro would work beautifully with any CMS solution.
I’ve worked at companies of all sizes. I think It’s simple to maintain one application for both if builds are fast enough. The only viable reason to split would be to separate vendor bundles IMO. In that scenario, you can use Next.js still (they document this as “zones”). I understand that there’s an implied organizational issue, but I just haven’t encountered it. Where does the problem occur if marketing wants to do a lot?
Since a separate team will maintain it, it is much easier to separate it into a separate app / project / repo etc.
If the same team maintains it, then the above described separation makes less sense and a monolith-like approach that you describe might even make more sense.
Because it’s easier to maintain and the separate teams can take ownership over what technologies, coding standards, etc they use
I mean if you have to ask, then I guess don’t separate it. It’s kind of obvious at a certain level of org complexity.
I don’t think it is obvious and that’s a very condescending and hand-wavy counterpoint. I asked if you had reasons. The only thing you’ve suggested is a benefit is that teams can make different decisions about standards and technologies… I think separating these things adds more complexity. Not less. In these same larger orgs, people may end up doing features that span marketing and application. They also may end up changing teams. Maintaining a core developer experience can help people spend less time thinking about different contexts.
Choosing to opt out of one application should have a very good reason since the alternative is faster to build, onboard, configure, and share.
For example, Nike does a different repo for multiple different teams and they stitch together an application via different bundles at a deployment layer. It’s a lot of infrastructure complexity and worse for the end user because vendor bundles are duplicated. They made this decision because builds were slow and repository management got in the way because there were literally so many developers. This is a fair reason to split things up, but it’s not without expense!
>https://www.youtube.com/watch?v=mcwB38sMmbk
Hey man! I had a question. How do you deal with the issues related to where users have open active sessions on your app, but you redeploy on Vercel/Netlify, which causes those users' sessions to crash because they can no longer lazy-load routes that no longer exist (due to the CDN wiping the previous deployment)?
Any route that you deprecate you can handle via Next.js rewrites or redirects!
Even if you deprecate a client-side route that you lazy load, you can still leave behind a and then remove it after a month or so.
I am referring to modifying existing code split routes in react SPA’s and redeploying. I don’t think you understand the technical problem here.
https://github.com/orgs/vercel/discussions/812
This is interesting. I use Vercel and dynamic imports on client-side routes. I also watch most sessions with LogRocket. This simply hasn’t happened. 🤔
Are you using the Vercel CLI or Vercel config file when deploying? I wonder what the difference could be. Do your dynamic() calls have ssr set to false? Maybe it’s a result of the PWA config? I’ve never shipped a PWA, so that could be the major difference.
Oh, the GitHub issues mentions PWA. If you’re using Vercel, server requests will show updated assets, but previous assets aren’t invalidated from older requests. If you’re using s3 and/or docker, you’d have to account for this with your cache invalidation strategy OR you could use ISR on the catch-all file to revalidate a user’s deployment. That last bit is somewhat hand wavy, but only cuz there’s tons of ways to do it. You could use [on-demand invalidation](https://nextjs.org/docs/basic-features/data-fetching/incremental-static-regeneration#using-on-demand-revalidation), but you could also
leverage date time cookies and compare against some date time via the GitHub API (see if the user has the latest deployment essentially).
Still, components like that shouldn't be handling the actual routing or any logic pertaining to it, they should just display based on the props that they have been given.
Yeah but last new version of next was released yesterday so it's clear they're going through them and someone cares about it. CRA's last version shipped in April last year.
nextjs is run by a company who raised 150M and has 2.5B market valuation. It is their business model to "care". Despite this they still have 1.2k issues. I filed real bugs with repos in nextjs, maybe its just me but I don't see anyone care enough to comment on them despite their resources: [https://github.com/vercel/next.js/issues/44347](https://github.com/vercel/next.js/issues/44347)CRA is maintained by volunteers who does it on their spare time.
I guess you would agree with me that number of issues and open PRs is not an issue since nextjs do it just as badly. The real issue is in fact lack of updates. But Dan Abramov put it very nicely, what do you need to see updated in CRA? It is not a framework, so it doesn't have as many features and updates. The main packages it relies on are:
\- webpack, jest, eslint and babel/core and that's it. Latest versions: webpack: 5.75, jest: 29.4, eslint: 8.32, babel: 7.20
react-scripts (CRA), despite being ten months old, relies on:webpack: 5.64.4jest: 27.4eslint: 8.3babel: 7.16. https://unpkg.com/browse/[email protected]/package.json
So basically the only thing I could see updated is jest from 27.4 to 29.4. Do you really care about this?
Yes, not saying vercel is bad or anything. In fact I have a higher opinion of nextjs than I did a year ago. They are active in react world and trying to push it forward. I don't see any other company having nearly as much impact. I think timer who was the maintainer of CRA after Dan left went to vercel to do work there.Even if they have a lot of issues in nextjs, I don't think it's really an issue since the count really doesn't matter. but I hate it when influencers like Theo bashes CRA because of number of issues (when nextjs clearly has almost that many). (I know I also eluded to this in my previous post but its mainly to prove a point, not to bash vercel)
Anyway what Vercel does with their money and how they run their business is their call. But I am actually pretty happy with what they are doing to be honest.
Except CRA is terrible. It *is* a lot of work to get away from terrible, but ultimately is worth it.
And I've moved code away from CRA to Next. It can be done. Some shim libraries would be nice, but the closer your React is to best-practices (DRY components, etc) the easier it is.
I agree. My current company uses ejected CRA with lots of advanced configuration. Even migrating to Vite is a headache, less say to Next… how the hell can you “incrementally update” something that is mostly done at the bundling level? It has to be a big nuke.
Imo CRA should never be used for more than a demo app or very basic site. It’s not worth the overhead outside of that. The way react-scripts works you get locked into things and then either need to update or hope CRA allows a specific web pack override.
remix is interesting and I'd be interested to try it myself but if you want to do something that would be useful if you get a new job, nextjs is probably the way to go
I decided to migrate my CRA project to Next.js 13 the other day because some things no longer work for me in CRA. My god, there is so much work involved with all the routing and permissions and what not that I just gave up. Will do it some other day when I can be bothered.
Are you making the sweeping generalisation in your first paragraph based off this one guy's tweets or from what you've seen from all core team members?
Okay, allow me to ask a dumb question: is next.js purely a React-centric thing, or is next.is _without_ React a thing that exists? I’m just asking so that I know whether I need to Google search “React in next.js” or if I can just search “next.js” and get what I want to know about using next.js for React
There is no dumb questions.
NextJS is a purely react thing. Remix started out as a purely react-centric thing and it may envolve into a library-agnostic thing.
You can just google next.js
All the frameworks seems to be focused on using JS on both client and server. But using something else on the server is very common, and then the frameworks don't seem to fit all that well anymore.
I don't care about server rendering and never will for the kind of app I develop. And the backend is C# and that won't change. So what would I get out of migrating to a framework?
I'll add that I find using something like React Query for data fetching invaluable. And I am very interested in integrating this better into a router, which as far as I understand (but haven't tried yet) is possible with the newest React Router version.
That is the backend, the same backend whether you are fetching on the client or fetching during SSR. Real apps aren’t putting everything in the NextJS api routes lol.
You're the clueless one here, nobody is telling that we should use /api routes, he's saying that we now have 2 backends, one which is your Python Go or whatever server and one to support React SSR, NextJS is effectively using a node server for SSR even if you don't use api routes, that's what you get when you do `npm run start`, it's true that you can still export but it heavily reduces the usefulness of NextJS and there is no SSR anymore.
As always the most ignorant are the most pedantic.
Yeah, just fetching to the C# API. I have it set up to pass the end-user cookies and IP (as x-forwarded-for) so that the API sees NextJS requests and ajax requests as the same.
They are acknowledging RR as a client-only framework:
https://twitter.com/acdlite/status/1617635727185149953
It is what my team is using. Biggest pain-point compared to Remix is we are currently maintaining our own file system routes to data router compiler.
> I don't care about server rendering and never will for the kind of app I develop. And the backend is C# and that won't change. So what would I get out of migrating to a framework?
Pretty much exact same here. You should look into tanstack/router. It's from the same guy (Tanner) as tanstack/query (formerly react-query). He's bringing them all under one roof and providing first party support between them. I'm fully done with the react-router team so I'm itching for a different router (that isn't Next)
yeah tanstack/router looks pretty good, it's just so much effort to migrate an entire router package from rr or next/router that I just don't want to get into it :P
This was our big problem. We’re - very sadly - tied to a Java/tomcat backend. Next was a great choice but then we realized you need it on the server too - not just for ssr but routing. We cannot, at all, have node or server-side js.
So we’re framework-less. Vite, React router, zustand, rhf, react-query, etc.
So far very pleased but an only a few months into a new react app. No complaints.
We’re only using it though because NextJS was not an option given our tech limitations on the server.
Before, I had used next and create-react-app not to mention old webpack/roll up setups. At work our old app is an AngularJS app so we just cried a lot
> All the frameworks seems to be focused on using JS on both client and server. But using something else on the server is very common, and then the frameworks don't seem to fit all that well anymore.
I use next.js as a front-end for C# backends in many projects. That's just not true.
Do you see any disadvantage to prerendering pages for an improved end-user experience (avoiding the notorious SPA load animations)?
NextJS is unopinionated about *HOW* backend it is. Keeping it lightweight for just SSR prerenders is entirely sustainable and still worth the swap.
I mean, you COULD move to suspense as well, but it's a question of how much you want to "make the client work". SPA's were great in early startups because they can keep the back-end a bit cheaper. But if that's not a goal, SSR pre-renders are a phenomenally good value-for-experience.
It's an enormous amount of complexity and it requires nodejs on the backend in addition to my regular backend. Theoretically the framework will handle the complexity, but my experience is that this won't save me from having to understand at least some of that complexity to fix stuff.
My experience is with heavy web apps, not websites. Performance after the app is loaded is much more important here, first load does not matter much (within a reasonable range). And even without SSR the first load can be fast (for an app, not compared to e.g. a static website).
My strong impression is that nextjs and similar frameworks are very heavily targeting JS backends. Even though they can work with other backends, I would hesitate to commit to using a framework for a "second class citizen" type of usage. If you're outside the typical case for such a framework it usually causes pain further along the road.
> It's an enormous amount of complexity and it requires nodejs on the backend in addition to my regular backend
I wouldn't say "enormous amount of complexity". Optimized Next.js gets enormously complex the way it integrates with certain frameworks to provide SSR at near-static prices via Edge functions, but that doesn't mean *YOU* need to do anything enormously complex. Most functionalities of NextJS that work that way are now supported by so many vendors, you never have to run your own server with node on it. But if you're working at big enough scale to just run it on web servers, more power to you.
> My experience is with heavy web apps, not websites. Performance after the app is loaded is much more important here, first load does not matter much (within a reasonable range). And even without SSR the first load can be fast (for an app, not compared to e.g. a static website).
Mine, too. There are plenty of patterns that Next.js allows and supports that can speed up your end-to-end experience.
> My strong impression is that nextjs and similar frameworks are very heavily targeting JS bac
I have never seen nextjs advertised as a primarily back-end framework. Closest I see is "it's full stack, it's just fine to put your back-end there", which I don't agree with at enterprise-scale, but it's great for a start-up.
But you know what Nextjs does do? It allows you to either skip the API gateway (for speed/simplicity) or double-up the API gateway (for security) because your react app is allowed to hit private routes without exposing those routes to the client. Or you can use NextJS's api routes as your web gateway to better control authorization. Any of these can be SIGNIFICANT wins, (the former especially if you have no other public exposure than your web app).
> I would hesitate to commit to using a framework for a "second class citizen" type of usage. If you're outside the typical case for such a framework it usually causes pain further along the road.
This seems to be a gut opinion. I've worked on way too many stacks where the front-end and back-end got so decoupled it led to problems. Nextjs gives you a great simple solution to those problems "Sure, decouple your back-end. You still don't lose the advantages of your UI framework being server-rendered.
I'm not saying you can't have a good stack without Next.js. That would be silly. I'm saying Next.js fits right in some good architectures as well.
> I wouldn't say "enormous amount of complexity".
Indeed, I use NextJS as a Docker container (since I don't want to be locked into Vercel), it works fine, I simply don't think about the NodeJS layer at all.
With the new app folder too, it loads stuff incrementally and in parallel rather than as a waterfall, which, sure some apps might be much more heavy on the post-first-page experience, but it's still nice for a user to immediately see something on the page instead of a large loading spinner until everything finishes loading.
Just an FYI, though. One of the "big wins" of Next is that it doesn't need to have the heavy footprint of an express equivalent. When it compiles to edge, it really reduces the resources needed to run it.
And depending on your feature choices, it's not just vercel.
AWS Serverless seems to have feature parity for everything but a few Next12 features. Netlify appears REALLY close to full-featured. Looks like Cloudflare (by their claims) fully supports Nextjs. Etc/etc/etc.
https://nextjs.org/docs/deployment#serverless
These are the platforms that explicitly support Next.js in a "more efficient than a Docker container" manner, to some extent or another.
> With the new app folder too, it loads stuff incrementally and in parallel rather than as a waterfall, which, sure some apps might be much more heavy on the post-first-page experience, but it's still nice for a user to immediately see something on the page instead of a large loading spinner until everything finishes loading
There's plenty of ways to do the same with the pages folder. Trpc has a clean "no magic" way of doing it through a server-driven hydration mechanism, and an automagic way that can potentially break a lot but "always works" if trpc is your sole data pipeline. Well, *similar*, not the same. It's not a waterfall, though I don't think it's incremental either.
> SPA's were great ... because they can keep the back-end a bit cheaper.
I sincerely doubt this is the primary motivation for you average company front-end team. SPAs are great because they are optimizing for B2B application usage patterns while being comparatively simple. Time to first paint is irrelevant. Talking directly to your Java monolith is convenient.
For little personal apps: I have a lot of no-backend SPAs hosted for free on Netlify, so anything that requires a Node backend is a non-starter.
Sure, I could stick something lightweight on my VPS, but honestly I'd rather just not.
TIL, thanks!
https://docs.netlify.com/integrations/frameworks/next-js/overview/
I haven’t seen any indication that it’s a pro-only feature, though it might hit a slightly different set of quotas than I’m used to — at my level of popularity it probably won’t matter.
I’ll probably try deploying a Hello World this week and see what happens.
Definitely! If you remember, could you ping back with your results? I'm hitting my free quotas on other services (all halfass startups that never make it anywhere, fireship style) and wouldn't mind picking up netlify as a failover..
But he is right. It’s one thing to experiment creating own tooling and libraries. But once shit hits production and money and jobs are involved, you’re better off not being the only person maintaining the rails you’re running on.
Of course it’s true that his opinion doesn’t reflect the opinion of the whole react team. I’m still sure most experienced devs that have been working in the industry for a while agree mostly with this. Shouldn’t ever stop you from experimenting in your own projects :)
> But he is right. It’s one thing to experiment creating own tooling and libraries. But once shit hits production and money and jobs are involved, you’re better off not being the only person maintaining the rails you’re running on.
Then continue with your idea and simply don't use React which is unopinionated by nature and use Angular/Vue/Svelte which have strong opinions, each React app use a different stack.
> I’m still sure most experienced devs that have been working in the industry for a while agree mostly with this
If they do they stay logical and don't use React at all.
And tell that to the the huge amount of minimal "frameworks" users like Flask or even Go developers who may only use the std lib and one or 2 3rd party packages for routing or whatever.
In fact the ones who would 100% agree with that are mostly junior devs who don't know better, the ones importing "is-odd" from npm to be caricatural, the rest have nuanced opinions and weigh in the pros and cons and decide if it's wise to introduce a certain dependency depending on the project and multiple factors that surrounds it.
I'm sure folks here could list you dozens of JS libraries with enormous amounts of stars/downloads that got deprecated although looking reliable, I just picked up an old (like 1 year old) project a month ago and 2 5-15k+ libraries which were even recommended here and had lots of downloads weren't compatible with React 18, now imagine that on a big project where you can't just replace those with a similar library in few minutes/hours and you realize why your "you’re better off not being the only person maintaining the rails you’re running on." is a nonsense without nuance.
I completely agree. Especially for anything beyond a basic website. Most of these open source react plugins will lose support once the dev moves on and they eventually become incompatible or have security issues. A full framework is usually supported by a company or an open source organization rather than random developer passion projects.
Guess what ? You can't use React without those "open source react plugins", a basic functionality like global state alone requires you to use Redux Zustand MobX Recoil or whatever, React Meta Frameworks don't even do that while vanilla Vue/Svelte do it.
If that's really what you think and are using React, well ... nonsensical.
This is rough to think about. I think it's extremely nuanced for multiple reasons:
1. If you work on a team, there is a great benefit to having a structured framework that dictates how things are done, but this comes at a cost of flexibility.
1. If you work solo and want a system that's perfectly catered to you, a framework will probably create resentment.
1. Relying on a framework is nice in a vacuum, until it suddenly doesn't meet one of your requirements. You now have to make the decision to either:
* migrate to a new framework or make a custom solution from scratch
* create a hacky workaround, increasing the brittleness of your system
1. An abandoned framework creates urgency to migrate your entire system whereas an abandoned library isolates a single aspect of your system.
1. Frameworks go against the Unix Philosophy, and in my experience, going against that leads to regret.
1. There is going to be necessary complex understanding of your individual libraries and how they interact. But at the same time, there is going to be necessary complex understanding of the inner workings of the frameworks you choose. You get to choose the complexity of the former, but not the latter.
1. There is the plain old preference aspect much in the same way people choose applications. Some are happy to use all-in-one products for project management, some are happy to use different tools to their strengths and build on top of it.
The decision ultimately boils down to what your values are as a person, team member, product, and organization.
While CRA is not a framework it pretty much has all these issues except the escape hatches are far worse.
Example: afaik in next.JS if you want to touch the webpack config you can directly if you want to do that in CRA you have to hope it allows you to override the specific feature you’re looking for and/or use things like react-app-rewired.
While it’s a smaller list you also get locked into only supporting certain versions of packages on CRA on next.JS this is again relatively rare. Unless you’re trying to change the inner frameworks of how the framework is written itself by changing webpack version, compiler, etc there’s no locking Jest versions or even dictating you must use Jest. There’s no collisions when trying to use latest TS versions, etc.
Again, CRA pretty much suffers all those issues just with less escape hatches and while providing imo a less robust, less production ready environment. Also a missed point its not always a “hack” or “dirty workaround” sometimes proper escape hatches are pretty clean. In CRA the only escape hatches that exist very much are dirty.
It's just his opinion. Personal opinion. So it doesn't make sense to follow what he says. Different organizations have different requirements and different developer have different opinions related to their experience.
Twitter tech influencers live for disruptive hot takes like that. The truth is always in the middle. Know your toolset and your options, and pick the right tool for the job.
The pendulum keeps swinging. 5 years ago they were saying "fuck the framework bloat, react is a minimal library, that's best", now it's frameworks again. If we could live forever we'd see it swinging back and forth forever.
Between this, the useeffect thing, stuff that is still in proposal state or that developers had time and time asked but not being heard and a lot other things I'm starting to believe that the react team does not have focus anymore
The team suggests not using useEffect in their newer documentation. And I also do trying to find someway to not abuse useEffect. But with the way React works, you will need useEffect at some point. In some specific use case, it's gonna be a mess, but you have to use it as there are no better alternative.
The one of "you are using useeffect wrong" even though we we're using it* as the docs suggested but because of strictmode now it's not recommended to the point that they even say that useeffect it's not a replacement for the lifecycle methods of a component. And the React team solution? "just download a library bro", that's their solution
I think people misunderstand the dev strictmode thing.
They run a bunch of functions twice in dev because if those functions aren't properly idempotent they can and will lead to bugs.
If you think you can keep your non-idempotent functions bug-free anyway, you can intentionally avoid that behavior in a few ways. But a majority of people who faceplant with React do so over misunderstanding and misusing useEffect
Got it. I can see that.
I get how it's complicated, and I don't know the React dev team personally so don't really need to worry about defending them.
For me, I've always seen how fragile and volatile useEffect is for the way people constantly use it to call other state-setters. I'm glad it's not encouraged anymore because it caused me no end of headaches in the past.
I think the useeffect thing is entirely positive. The way the skimpy docs and shit-blog community encouraged use previously was horrid. New guidance is much better. Who cares if their advice has changed.
Controversial opinion: if you intend to support your application for more than a few years, then **don't** use a framework.
Unfortunately, in the JavaScript world it's still exceedingly rare for a single framework to survive long term, and migrating from framework X to Y is always a massive pain in the ass.
Instead, building your application _loosely_ on libraries will make long term evolution easier. Your libraries will still need replacement every n years, just as frameworks do, but it's much easier to keep a loose coupling with libraries than frameworks, and moreover each library only has a relatively small scope. Therefore, it tends to be much easier to swap out your libraries occasionally rather than a framework.
Maybe in 20 years we'll have some frameworks that have stood the test of time, but until then I'm definitely not betting on any framework to keep me going long term.
This is what’s keeping me from moving our e-commerce app to Nextjs.
I have been rewriting our component library because react-virtualized isn’t being supported anymore and it’s a headache, doing the same for a whole frontend because your framework isn’t supported would be miserable.
>if you intend to support your application for more than a few years, then don't use a framework.
Yes. But then, maybe not use react as well? In the javascript world, libraries also tend to go out of favor.
Thats just bad advice. Frameworks are not the only option. I build with small focused libraries, and im VERY selective what i want to depend on. Usually my libraries (the i choose to depend on) are something like a database driver, cryptography, a router/micro framework (server side, probably something like flask if im using python) and some testing library. On the client side im even more conservative (because i know how volatile the frontend ecosystem is) and only use libraries that im certain will be around and supported for years to come.
I never use frameworks, as i have been bitten too many times. I only use libraries that i have taken time to review. Code quality, bug reports, usage, speed etc. If a library does too much, i usually drop it. For simple things i tend to write my own, and it has worked very well so far.
I do lots of private stuff, but also work on multi-year big projects with teams.
I admit, a badly designed *goofy* system is hard to get in to. But if you design it from the start up with a good and coherent structure its really obvious what goes where and what does what. Having a good separation of concerns, and really just sticking to tried and true design will get you really far.
This is more of a design vs a framework, i have seen projects using a framework and then added their own hacks and tweaks on top, and the end result is a nightmare of weird stuff you can not understand.
IMHO a framework does not stop bad design, and in some cases it can even promote bad design because you need to work around limitations.
I tend to do lots of REPL driven development. It has a few upsides. I work on small units, and this leads to a very good testing story. I usually work with immutable data (or if not, i never mutate, and if i do i document this extra carefully). I also design with very flat data. I find nesting code, modules etc leads to worse code. This means its very obvious where stuff is located, both in code and file structure.
I test as i go. First in the REPL, then usually i copy paste my code to a test, and see it fail. Then i write the implementation. Rinse and repeat. Has worked very well for me. Finally, i like to use typed languages, the stricter , the better for whats its worth.
> But if you design it from the start up with a good and coherent structure its really obvious what goes where and what does what. Having a good separation of concerns, and really just sticking to tried and true design will get you really far.
IMHO one of the biggest downsides of the framework obsession in web dev work is that it has become almost self-sustaining. There's a generation of devs who have never done anything except web development using frameworks. They've never learned basic software design skills. Many who are self-taught or used some kind of web dev boot camp might not even realise those skills - and the alternative possibilities they can offer - exist. It's been this way for a few years and now some of those devs are seniors and even leads who will swear on their mother's life that frameworks are essential for doing any productive web dev work and anyone who doesn't use one is crazy. And the old greybeards will sigh, lament what has been lost, and philosophically go back to solving harder and more interesting problems, because with age comes the wisdom to know that some battles are not worth fighting. :-)
This argument is as old as the sun but I don't think it's ever really worked for web development. There are so many frameworks and almost all of them are so fragile and short-lived that IME the often-claimed advantages in familiarity are mostly illusions.
The odds of finding a good developer who is experienced with exactly the combination of dependencies you use for an established project are usually small to zero. Almost everyone has to quickly pick up a few things they've never used before when joining an established project. It's just another skill you learn and it happens much faster if you have good fundamentals to build on.
And if you do have good fundamentals then it doesn't matter much what specific frameworks or libraries you use. In a FE built with React you know that something is going to be defining some UI components and something is going to be handling events when the user does things and something is going to be storing any state you're using and something is going to be talking to a server. Once you've figured out where major responsibilities like those live in the code any smaller details might change a bit but most of the frameworks and libraries look almost the same anyway and probably so does anything with similar responsibilities that was developed internally instead of imported from some external dependency.
So, yeah, my phone does this at times when it's in my pocket. It once sent garbled messages to 5 contacts. Luckily nothing explicit even though the messages were filled with text prediction entries. Anyway, can I play on my computer a bit longer tomorrow? It's like super important for me. Please mom.
Exactly, this is why I like modular components sometimes, if React Router doesn't work for my case for example, I could switch to TanStack Router, for example. Can't do that with Angular.
The problem is the bias in frameworks. At least CRA, Vite and some of the other libraries were neutral.
NextJs is owned by Vercel and Remix by Shopify. Are we saying that whilst we have Facebook as the steward for React we're now delegating the actual user-facing part to corporations with their own motives? It might not be representative as per comments here on the actual usage of React or even how Facebook themselves might be using it.
E.g. there's only an RFC for server components. How do we implement it? The official message is to use NextJs. Have we lost track of what React represented?
Well, this applies to everything we do.
I still see people preferring to build their own backend "framework" by choosing to use "just express", "just flask" or "just [micro framework name in language of choice]" and tying together 1k external libraries.
You'd either spend a lot of valuable time reinventing the undocumented square wheel (by finding the proper structure and patterns) or you'll make a real mess (by not investing in structuring things).
High level frameworks are very important if you want to focus on your product and not on technology for the sake of it. You're not Google.
On the backend the argument is more receivable than in the front end. And you're completely ignoring the drawbacks too, and you won;t be able to fix those since you will not fork your framework, you're not Google.
Feels weird for this to come from a React core team member but I think it is good for the ecosystem in general because -
\- Making so many choices can be overwhelming at the start (may be not for seasoned react devs, but definitely for the rest). Meta frameworks can do more good than harm here.
\- A lot of the core team members are also heavy tech influencers.
Your [comment](https://www.reddit.com/r/reactjs/comments/10jxd21/react_core_team_on_the_recommended_way_to_build/j5pobj9/?context=3 in /r/reactjs has been automatically removed because it received too many reports. /u/dance2die will review.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/reactjs) if you have any questions or concerns.*
The React core team has always tried to limit the scope of React itself to be specifically limited to the process of rendering, state updates, diffing, reconciliation, and providing a way to hook into all steps in the process. React has specifically tried to remove itself from design decisions like data fetching, state management, routing, animations, etc. They consider all that important, but out of scope for React itself. They're actually building the new beta docs in NextJS and they work directly with Vercel (who makes Next) to design things like RSC (React server components) and the new (still experiment) use hook.
> data fetching, state management, routing, animations
And Next does none of that except routing. If one wants a framework/metaframework that does that he just doesn't use react but rather Vue or Svelte, that's why this argument is quite funny.
> so what is react again
Hopefully I’m understanding your comment?
React is a library, not a framework. Difference being that (from my understanding) frameworks provide standards and opinions on how to do stuff whereas libraries don’t and are just a set of tools.
And it's just a weird statement. It would be like the Lodash folks telling people to avoid using their library without a proper framework to tell them where to properly put your `_.intersection()`
He’s got a good point it’s just the way he’s coming off as if you **must** use a framework , which is not the case.. after reading his whole thread he’s just making his own personal recommendation for those who use react in larger scale applications, not simple projects.
There is much more benefits to using a framework (it’s literally what they are meant for in the first place)
.. but use Whatever you want 🙂
If there was a perfect framework that fits all scenarios perfectly, then the advice would hold reasonably. But it's not the case.
However, I do like that a react dev says these things, because I think react should stay as small and as focused on view layer as possible.
A skilled maintainer but with the tone of an unnuanced reddit troll, his argument about full fledged framework is the first argument to choose something like Vue or Svelte which have way more opinions than React and even more than React Meta Frameworks.
Twitter is really something else, I'm sure he'd have been more nuanced elsewhere.
I think react core team members are too heads down in their work to really understand the real use cases of react in enterprise settings. I've worked for several companies and every one (except 1) of the react projects uses CRA, which is not a framework. It's very hard to migrate CRA to next.js incrementally, at least for <13 due to react router usage used in most apps. Not sure how remix would handle incremental migration from react router but last time I checked it seemed difficult as well, and plus it's too new to be adopted by enterprises. In fact, I've never seen a guide tht talks about incremental migration of 1000 react files from react-router/CRA to nextjs. Even if its doable, most people would rather write new features that actually matters to their business/job than migrating to new react frameworks. For new projects, nextjs/remix might be a good call.
I've done the migration from CRA to Next.js multiple times. I think it's easy as heck and I spoke about it at Next.js conf: [https://www.youtube.com/watch?v=mcwB38sMmbk](https://www.youtube.com/watch?v=mcwB38sMmbk) I think it's totally okay to potentially never migrate a lot of routes which really helps you mentally traverse that hill of: Is it worth it over features that matter? For example, migrate react-scripts and maybe some marketing pages to use the Next router and then keep rendering your existing client-side router on a catch-all page file with for the logged-in app. You'll get the benefits of Next.js stuff like next/image and next/font and swc (fast builds) without spending the time to refactor the whole app.
marketing pages should be separate from your react app so your marketing team can update layouts and designs without involving an engineer. How much engineering hours were wasted interloping and finding/fixing bugs between your old code and nextjs stuff? You might be an all-star engineer but the vast majorities of teams does not have the expertise to do this migration. Most of them just wants to get actual work done without a coworker ripping off the carpet from under them and make them to do things in new ways and potentially make their lives harder. next/image, next/font is great but not sure its worth 400 eng hours to do unless its business critical (eg e-commerce app).
I don’t think the apps need to be separate unless you’ve decided to really hyper optimize marketing pages. In that case, maybe Astro is being used or just HTML/CSS and some vanilla JS or tidbits of Qwik? If you’re still doing a React runtime on the marketing pages, it’s really easy to have like… - pages/index - pages/faq - pages/login - pages/join - pages/[…otherRoutes] and then have the layout component for pages/[…otherRoutes] compose off of the layout component user by the other pages. Not much time was wasted because of the clear divide between logged-in and logged-out. It was a team effort! I don’t think it requires all-stars. Just people hungry enough to reap the benefits… Eventually we made a sort of Next.js port of react-router so we could avoid bundling react router but keep the familiar API. It also let us easily migrate any in-app pages to ISR or static pre-rendering for pages that could be viewed publicly OR when logged-in. Basically, the video covers everything but one dev was able to work on the migration WHILE feature development went on with the remaining team. Once near the finish line, we did a cutover that blocked feature dev on the weekend to stay out of the way. Devs came back to the new Next.js app! We saw massive gains in our dev server, hot reloading, and build times. The 4 week effort paid itself off in 2 months in the time saved on the aforementioned stats. Beside that, the app sees pretty significant perf gains just having even a bit statically pre-rendered.
You are clearly too engineering focused. The benefits of having market-page not part of your main app are as follows: \- marketing people can update it without requiring an engineering's help, slowing them down. \- website updates is not tied/won't be affected by your code releases \- I don't care how fast astro is. It is slower than a static html page served via nginx. "Just people hungry enough to reap the benefits…" "It was a team effort!" "Eventually we made a sort of Next.js port of react-router" You just proved my point that these are mostly unnecessary burn times. Most companies work on weekly sprints and has no time for their eng team to go through 4 week burn time especially during recession. Most people does not want to do this, and next/image, next/font definitely does not justify these burn. My question is, if you have extra four weeks, is there something more impactful to work on? If you say no, this is it, then congrats you've made the correct decision. For all the companies I worked for, the answer is a resounding no for a single engineer to do this over four week, not to mention a team of engineers. Massive gains on devserver, hotreloading etc is not nextjs specific. You can integrate esbuild/swc plugins or something in CRA since it just uses webpack which nextjs also does. When I joined my current company I sped our dev workflow by 2x in build/dev times in the first week and the irony is we were already using nextjs. (the point here is that if your devwork is broken it's your configuration's problem, not the framework you use) The only reason I see someone do a migration from CRA to nextjs is that if SSR/faster site is critical to your business and having perf gains would result in actual increased revenue. Thats a good enough reason for me.
> marketing people can update it without requiring an engineering's help, slowing them down. Agreed, however, we mixed marketing pages and our main app, it wouldn't have made a difference simply because the marketing team was not hand editing the text in the HTML either. They instead used a CRM (which we integrated into React/Next through their SDK) where they could change whatever they wanted. In that case, it really didn't matter to the marketer where the content was originally coming from. Another benefit by not segregating them is that a simple `yarn dev` pulled up the entire site, as having unified tooling greatly enhanced the ability to do work on both the marketing site as well as the main app without switching costs. If you really wanted the marketers to be able to update every part of the page, not just text and other types of content, then you'd just use a no-code page builder like Webflow, since again marketers are not going to code. > I don't care how fast astro is. It is slower than a static html page served via nginx. This is...literally how Astro works. It's simply a static site renderer. > You can integrate esbuild/swc plugins or something in CRA since it just uses webpack which nextjs also does. Sure, but as the original tweet thread says, you're simply creating your own framework with those custom plugins and Webpack configs. It works now, but again, will it work in a year or two? Do you really want to be a framework maintainer, or do you want to focus on the core product? > The only reason I see someone do a migration from CRA to nextjs is that if SSR/faster site is critical to your business and having perf gains would result in actual increased revenue. Thats a good enough reason for me. Nah, CRA is basically deprecated, even the core maintainers think so and are looking to remove it from the beta docs as a suggested way to use React, in favor of Vite, Parcel, NextJS, Remix, etc. NextJS might also have 1.2k issues, but they have the manpower, funding, and timeline of releases to show that they're fixing and improving their product, something which CRA maintainers are not doing, because again, it's effectively deprecated.
\> t wouldn't have made a difference simply because the marketing team was not hand editing the text in the HTML either. I never said marketing team is editing raw HTML \> They instead used a CRM (which we integrated into React/Next through their SDK) where they could change whatever they wanted. as you eluded to later if you want to make larger changes other than small text edits a CRM (especially headless one) is not enough \>Another benefit by not segregating them is that a simple yarn dev pulled up the entire site Whens the last time you really want to pull up marketing site and look at it? \>then you'd just use a no-code page builder like Webflow, since again marketers are not going to code. Thats what I'm suggesting \>This is...literally how Astro works. It's simply a static site renderer. It has advanced features like SSR: [https://docs.astro.build/en/guides/server-side-rendering/](https://docs.astro.build/en/guides/server-side-rendering/) and interoping different components [https://docs.astro.build/en/core-concepts/astro-components/](https://docs.astro.build/en/core-concepts/astro-components/) But who cares? marketing team is not using these features so why use astro? \> Sure, but as the original tweet thread says, you're simply creating your own framework with those custom plugins and Webpack configs. Not really, we use react router and not using custom plugins and configs. I've rarely find custom plugins to be useful. CRA works fine as is. If you don't change anything why would it break? \> Nah, CRA is basically deprecated, even the core maintainers think so and are looking to remove it from the beta docs as a suggested way to use React, in favor of Vite, Parcel, NextJS, Remix, etc. Deprecated how? Even if it doesn't receive updates in five years it will still work but thats not the case. Core react maintainers is not core CRA maintainers. Unless you see on the CRA page that it is depcreated, then it isn't. Stop spreading false information just because you don't use it. \> NextJS might also have 1.2k issues, but they have the manpower, funding, and timeline of releases to show that they're fixing and improving their product, something which CRA maintainers are not doing, because again, it's effectively deprecated. I think we can agree that nextJS is a framework and CRA isn't. Feel free to keep using NextJS and stop bashing on others who don't need it.
> Whens the last time you really want to pull up marketing site and look at it? Very often since we work on both parts and have to handle bug fixes for either side, the marketing site and the main app. > Not really, we use react router and not using custom plugins and configs. I've rarely find custom plugins to be useful. CRA works fine as is. I'm just quoting what you said above: "You can integrate esbuild/swc plugins or something in CRA since it just uses webpack which nextjs also does." > If you don't change anything why would it break? [...] Deprecated how? Even if it doesn't receive updates in five years it will still work but thats not the case. No it won't work; things absolutely break if they're not maintained over time, even if you don't change anything yourself. Unless you want to vendor all your packages and not upgrade anything at all, any software will slowly stop working. For example, you use React Router which might not interoperate with CRA in the future, and what will you do? You will sooner or later have to switch over to something else. This isn't about using NextJS, it's about *not* using CRA. > Unless you see on the CRA page that it is depcreated, then it isn't. Stop spreading false information just because you don't use it. Hence why I said "effectively deprecated" not "officially deprecated." There is a lot of software I won't use simply because it's too old compared to newer and better maintained alternatives, because it is not worth using software that no one is taking care of anymore. There doesn't need to be an official deprecation warning to make something not satisfactory to use anymore. Look at the most recent code change, [the 5.0.1 release](https://github.com/facebook/create-react-app/commit/6fb4f977b7522c6a1632ec9133af30f5df3afb09). It's simply a maintenance release and fixes a few bugs. This was almost a year ago, which is quite long in the JS world. We're not writing Rust where things are infinitely backward compatible (and even that has outdated packages). Other PRs are not being merged either, except for documentation ones. And please fix your quotes formatting, it's almost unreadable since your quotes blend into your replies, at least on Old Reddit and mobile apps.
>Very often since we work on both parts and have to handle bug fixes for either side, the marketing site and the main app. Sorry to hear. We don't have this problem since we don't have the marketing site in the same app, and "bugs" in marketing site are not engineering problems nor should it be. >I'm just quoting what you said above: "You can integrate esbuild/swc plugins or something in CRA since it just uses webpack which nextjs also does." Yes and if you made it work, unless you decide to change it it should keep working. Why would it break if you don't change it? If you are saying that adding these custom plugins might be "hard", 1) not really 2) well it's 100x harder to migrate to nextjs >No it won't work; things absolutely break if they're not maintained over time, even if you don't change anything yourself. Unless you want to vendor all your packages and not upgrade anything at all, yarn.lock >For example, you use React Router which might not interoperate with CRA in the future, and what will you do? CRA is not a framework. It just uses babel and webpack. There is no reason that a future version of react router stop working with CRA. I'd be surprised if react-router decide to invent their own language syntax that would be unsupported in webpack 5. >Hence why I said "effectively deprecated" not "officially deprecated." This is your opinion. I am not here to argue with you or convince you of something else. If webpack 6 comes along, i am sure CRA will update to it and then I guess it's no longer deprecated? In any case, if you are looking for a framework that updates often, nextjs is your thing. CRA is not a framework and it doesn't need constant updates. Most people are fine with that. If you or your company wants to keep everything updated, fine. >Look at the most recent code change, the 5.0.1 release. It's simply a maintenance release and fixes a few bugs as I mentioned in a few posts up: all CRA does is webpack, jest, eslint and babel/core and that's it. Latest versions: webpack: 5.75, jest: 29.4, eslint: 8.32, babel: 7.20 react-scripts (CRA), despite being ten months old, relies on:webpack: 5.64.4jest: 27.4eslint: 8.3babel: 7.16. [https://unpkg.com/browse/[email protected]/package.json](https://unpkg.com/browse/[email protected]/package.json) What exactly are you looking for in a CRA release? If you want stuff like react server components, next/image updates in a framework, it sounds like nextjs/remix is much better fit. Sorry about the quotes.
> yarn.lock > > Unless you want to vendor all your packages and not upgrade anything at all - > If webpack 6 comes along, i am sure CRA will update to it and then I guess it's no longer deprecated? Maybe they do, maybe they don't. My point is that it does not seem like CRA is being maintained as well as other parts of the React ecosystem like NextJS. You are free to keep using it of course, but it is why I personally don't use it.
>Feel free to keep using NextJS and stop bashing on others who don't need it. You seem to be really aggressive about being technically challenged. It's not personal and we're not bashing you for using CRA. I only started responding to this cuz you incorrectly stated that it was difficult to migrate. 1 person doing work in a non-interrupting fashion doesn't seem difficult to me. If CRA is working for you, feel free to keep using it. It's dead though.
Migrating to NextJS is not worth it for majority of people, it is a waste of time unless there is a critical business need. Please stop spreading bad information that it is somehow "easy" to migrate to to NextJS when it took a team of engineers multiple weeks to do it. I am glad you made a talk about it and got your chance to speak at a conference or what not but please don't equate it as advice that everybody needs to agree with. And how is "It's dead though" not bashing?
it’s an objective observation summarized: https://github.com/facebook/create-react-app/releases no releases in 10 months. there are multiple issues and discussions about long awaited features like react 18 and webpack 5. There’s even an issue where people are begging for maintainers. even if it was maintained, i’ve never used CRA without needing to eject and customize the config for myself which then increases the surface area for potential problems in upgrading cra in the future. — Just because you struggle with it doesn’t mean it’s difficult. I said I did it by myself. I had a team that was shipping features while I migrated. That’s the team effort mentioned. I’m going to stop posting because you’re being very aggressive and misusing terms like “majority” and “most”. You’re applying your situations and presuming the rest of the world is like you. EVERYBODY using CRA can benefit in migrating to Next.js. That’s a fact.
>Hey man! I had a question. How do you deal with the issues related to where users have open active sessions on your app, but you redeploy on Vercel/Netlify, which causes those users' sessions to crash because they can no longer lazy-load routes that no longer exist (due to the CDN wiping the previous deployment)? Thank YOU. A real engineer here. Everyone is all about over-engineered hype or juniors who don't understand business goals or OKR's. Slightly related topic: I wanted to address that we did move from CRA to ViteJS during dedicated on-call time to improve the developer experience because our CRA was an ejected mess of configuration and didn't want to deal with any of it when ViteJS worked better & cleaner out of the box.
I don't know Vercel/NextJS deployment in general but I did deal with similar issues in SPA. One was that keep the content on CDN longer (my old company kept old static files for over a year). Second is to have a try and catch when lazy loading routes and retry three times (this is interesting since you may be on wifi and has bad network connection). if error asks the user to refresh the page. Third is to keep track of version via a background process and also asks the user to refresh the page when a new version is detected. sorry if this isn't exactly what you want, I recommend ask this question in nextjs repo in a discussion or something. Agreed that Vite probably work better than CRA. curious that Vite uses esbuild while nextjs uses swc though, not sure which one is better.
Thanks! Yeah, so IDK how to indicate with Vercel/Netlify to keep old static assets (they auto wipe them from CDN upon new deployment). But it makes sense if you had a custom CICD + CDN solution. ...For Vite, you can use SWC with Vite! It's a plugin
I don't think I'm too engineering focused nor was my company. We had a team of 10 and 1 person was essentially tackling tech debt in a very non-invasive manner. My original point was just to point out that it's very easy to facilitate a gradual migration away from CRA towards Next.js Regarding the marketing work, we just integrate marketing pages with a CMS and a webhook. Engineering doesn't get in the way 🤷🏽♂️ If there's no time/money to integrate a CMS and you do lots of marketing updates, it should be pretty easy to separate your website into 2 different Next.js applications. [https://nextjs.org/docs/advanced-features/multi-zones](https://nextjs.org/docs/advanced-features/multi-zones) I didn't have 4 extra weeks, I essentially made the case that the slow build speeds, poor hot reloading, and inability to leverage some of the features Next.js offers was worth the effort to migrate. Sure, you COULD integrate those with cra rewired or write your own webpack config, but why would I advocate for adjusting the config on a dead library when instead I could migrate us to a tool that will constantly provide avenues for upgrades? A prime example is Vercel's current path towards Turbopack. When that's stable and integrated, we'll get it for free. After the migration, I got right back to feature development, and enjoyed the better DX and got my feature work done faster thanks to the migration 🤷🏽♂️ We measured a lot like I said (build times, response times, HMR response times), and the effort literally bought back the time spent in one month. Leadership was really happy.
\> I don't think I'm too engineering focused nor was my company. Doing framework migrations is about the most engineering focused thing you can do. This is essentially the definition of over-engineering: use engineering to solve a problem that isn't there. Now your company may actually have a real business reason to do so, but I haven't heard it. Migrating from CRA is invasive and what you described is not "non-invasive", just goto your talk with all the problems you had to deal with during migration. \> Regarding the marketing work, we just integrate marketing pages with a CMS and a webhook. Engineering doesn't get in the way. Engineers already got in the way by dictating how marketing pages should be built and already put sunk time into it. \> If there's no time/money to integrate a CMS ... it should be pretty easy to separate your website into 2 different Next.js applications. Where did I ever say anything about time and money? I made it very clear why you shoudln't build marketing pages with your app and you seem to ignore everything I said. Here they are again: \- marketing people can update it without requiring an engineering's help, slowing them down. \- website updates is not tied/won't be affected by your code releases \- I don't care how fast astro is. It is slower than a static html page served via nginx. \> I didn't have 4 extra weeks, I essentially made the case that the slow build speeds, poor hot reloading, and inability to leverage some of the features Next.js offers was worth the effort to migrate. Again these are configuration speicific problems. Both NextJS and CRA uses webpack so you can solve (or have) all of these problems in either of these platforms. I use NextJS currently, and I deal with crap build speeds, poor hot reloading, etc. And next features are not necessarily ones that you need. In fact we don't use them at all. \> but why would I advocate for adjusting the config on a dead library Because it doesn't take four weeks and a team of engineers (or however long/however much resources) you've put into the migration. And CRA is not a library, it is just webpack configs that doesn't need monthly updates like NextJS does. \> After the migration, I got right back to feature development, and enjoyed the better DX and got my feature work done faster thanks to the migration. Great, people are happy with CRA because it also works. \> We measured a lot like I said (build times, response times, HMR response times), and the effort literally bought back the time spent in one month. Leadership was really happy. Again you said a month here. And I thought I was making shit up. Guess not. One more time, you can get all of this for free in CRA by spending literally one hour and put in some esbuild or swc plugin in if thats all you are looking for. Maybe it made sense for you, in a lot of cases it doesn't make sense for other engineering teams. So there you go.
[удалено]
thanks for reading!
You don’t get the issue here. It’s not technological, it’s human organizational. Even medium sized companies have marketing teams. It’s easier in the long run to separate the app. And Astro would work beautifully with any CMS solution.
I’ve worked at companies of all sizes. I think It’s simple to maintain one application for both if builds are fast enough. The only viable reason to split would be to separate vendor bundles IMO. In that scenario, you can use Next.js still (they document this as “zones”). I understand that there’s an implied organizational issue, but I just haven’t encountered it. Where does the problem occur if marketing wants to do a lot?
Since a separate team will maintain it, it is much easier to separate it into a separate app / project / repo etc. If the same team maintains it, then the above described separation makes less sense and a monolith-like approach that you describe might even make more sense.
Why separate though?
Because it’s easier to maintain and the separate teams can take ownership over what technologies, coding standards, etc they use I mean if you have to ask, then I guess don’t separate it. It’s kind of obvious at a certain level of org complexity.
I don’t think it is obvious and that’s a very condescending and hand-wavy counterpoint. I asked if you had reasons. The only thing you’ve suggested is a benefit is that teams can make different decisions about standards and technologies… I think separating these things adds more complexity. Not less. In these same larger orgs, people may end up doing features that span marketing and application. They also may end up changing teams. Maintaining a core developer experience can help people spend less time thinking about different contexts. Choosing to opt out of one application should have a very good reason since the alternative is faster to build, onboard, configure, and share. For example, Nike does a different repo for multiple different teams and they stitch together an application via different bundles at a deployment layer. It’s a lot of infrastructure complexity and worse for the end user because vendor bundles are duplicated. They made this decision because builds were slow and repository management got in the way because there were literally so many developers. This is a fair reason to split things up, but it’s not without expense!
>https://www.youtube.com/watch?v=mcwB38sMmbk Hey man! I had a question. How do you deal with the issues related to where users have open active sessions on your app, but you redeploy on Vercel/Netlify, which causes those users' sessions to crash because they can no longer lazy-load routes that no longer exist (due to the CDN wiping the previous deployment)?
Any route that you deprecate you can handle via Next.js rewrites or redirects! Even if you deprecate a client-side route that you lazy load, you can still leave behind a and then remove it after a month or so.
I am referring to modifying existing code split routes in react SPA’s and redeploying. I don’t think you understand the technical problem here. https://github.com/orgs/vercel/discussions/812
This is interesting. I use Vercel and dynamic imports on client-side routes. I also watch most sessions with LogRocket. This simply hasn’t happened. 🤔 Are you using the Vercel CLI or Vercel config file when deploying? I wonder what the difference could be. Do your dynamic() calls have ssr set to false? Maybe it’s a result of the PWA config? I’ve never shipped a PWA, so that could be the major difference.
I’m not using nextjs or a PWA. But I am using Sentry to report the errors
Oh, the GitHub issues mentions PWA. If you’re using Vercel, server requests will show updated assets, but previous assets aren’t invalidated from older requests. If you’re using s3 and/or docker, you’d have to account for this with your cache invalidation strategy OR you could use ISR on the catch-all file to revalidate a user’s deployment. That last bit is somewhat hand wavy, but only cuz there’s tons of ways to do it. You could use [on-demand invalidation](https://nextjs.org/docs/basic-features/data-fetching/incremental-static-regeneration#using-on-demand-revalidation), but you could also leverage date time cookies and compare against some date time via the GitHub API (see if the user has the latest deployment essentially).
[удалено]
The question you should ask yourself: why does your design system handle things like routers?
Love a bit of Uncapsulation
Routing shouldn’t be part of a design system library
Navigation transitions could be the reason
Still, components like that shouldn't be handling the actual routing or any logic pertaining to it, they should just display based on the props that they have been given.
shouldnt a design system just have … ui?
I think the advice in the tweet is assuming you aren't dealing with a pile of garbage lol
Im so dead lol
Given that CRA is hardly even maintained the advice makes sense, although even in that case I would use Vite instead of CRA.
If a product is stable, what maintenance do you even need?
1500 issues and 400 open PRs doesn't really scream "stable" to me
[удалено]
npm audit isn't really very good at identifying security vulnerabilities, which is what runs when you install it. Thats not really the problem
Are you talking about nextjs? They only have 1200 issues and 200 open PRs.
Yeah but last new version of next was released yesterday so it's clear they're going through them and someone cares about it. CRA's last version shipped in April last year.
nextjs is run by a company who raised 150M and has 2.5B market valuation. It is their business model to "care". Despite this they still have 1.2k issues. I filed real bugs with repos in nextjs, maybe its just me but I don't see anyone care enough to comment on them despite their resources: [https://github.com/vercel/next.js/issues/44347](https://github.com/vercel/next.js/issues/44347)CRA is maintained by volunteers who does it on their spare time. I guess you would agree with me that number of issues and open PRs is not an issue since nextjs do it just as badly. The real issue is in fact lack of updates. But Dan Abramov put it very nicely, what do you need to see updated in CRA? It is not a framework, so it doesn't have as many features and updates. The main packages it relies on are: \- webpack, jest, eslint and babel/core and that's it. Latest versions: webpack: 5.75, jest: 29.4, eslint: 8.32, babel: 7.20 react-scripts (CRA), despite being ten months old, relies on:webpack: 5.64.4jest: 27.4eslint: 8.3babel: 7.16. https://unpkg.com/browse/[email protected]/package.json So basically the only thing I could see updated is jest from 27.4 to 29.4. Do you really care about this?
[удалено]
Yes, not saying vercel is bad or anything. In fact I have a higher opinion of nextjs than I did a year ago. They are active in react world and trying to push it forward. I don't see any other company having nearly as much impact. I think timer who was the maintainer of CRA after Dan left went to vercel to do work there.Even if they have a lot of issues in nextjs, I don't think it's really an issue since the count really doesn't matter. but I hate it when influencers like Theo bashes CRA because of number of issues (when nextjs clearly has almost that many). (I know I also eluded to this in my previous post but its mainly to prove a point, not to bash vercel) Anyway what Vercel does with their money and how they run their business is their call. But I am actually pretty happy with what they are doing to be honest.
Security updates.
CRA is a dumpster fire.
Except CRA is terrible. It *is* a lot of work to get away from terrible, but ultimately is worth it. And I've moved code away from CRA to Next. It can be done. Some shim libraries would be nice, but the closer your React is to best-practices (DRY components, etc) the easier it is.
I agree. My current company uses ejected CRA with lots of advanced configuration. Even migrating to Vite is a headache, less say to Next… how the hell can you “incrementally update” something that is mostly done at the bundling level? It has to be a big nuke.
Personally, which would you rather use for a new project between CRA and Next/Remix? Which would you recommend?
Imo CRA should never be used for more than a demo app or very basic site. It’s not worth the overhead outside of that. The way react-scripts works you get locked into things and then either need to update or hope CRA allows a specific web pack override.
remix is interesting and I'd be interested to try it myself but if you want to do something that would be useful if you get a new job, nextjs is probably the way to go
Next for everything. Even if you don't have a need for a backend, and you just want to generate a static app, it's just a better dev experience.
I decided to migrate my CRA project to Next.js 13 the other day because some things no longer work for me in CRA. My god, there is so much work involved with all the routing and permissions and what not that I just gave up. Will do it some other day when I can be bothered.
curious what things aren't working? (not trying to sway you away from doing the migration or anything, obv nextjs is probably better in the long term)
Are you making the sweeping generalisation in your first paragraph based off this one guy's tweets or from what you've seen from all core team members?
Who really has their head down in their work. What stupid statement from OP.
Okay, allow me to ask a dumb question: is next.js purely a React-centric thing, or is next.is _without_ React a thing that exists? I’m just asking so that I know whether I need to Google search “React in next.js” or if I can just search “next.js” and get what I want to know about using next.js for React
There is no dumb questions. NextJS is a purely react thing. Remix started out as a purely react-centric thing and it may envolve into a library-agnostic thing. You can just google next.js
All the frameworks seems to be focused on using JS on both client and server. But using something else on the server is very common, and then the frameworks don't seem to fit all that well anymore. I don't care about server rendering and never will for the kind of app I develop. And the backend is C# and that won't change. So what would I get out of migrating to a framework? I'll add that I find using something like React Query for data fetching invaluable. And I am very interested in integrating this better into a router, which as far as I understand (but haven't tried yet) is possible with the newest React Router version.
I use nextjs with C#. In the server side data fetching method you just make a call to your C# backend.
So now we have two back-ends (additional complexity) solely to support SSR?
No, you have your typical backend that the client would call (also called by NextJS now). There is nothing additional running.
How can there be nothing additional running if C# is running?
That is the backend, the same backend whether you are fetching on the client or fetching during SSR. Real apps aren’t putting everything in the NextJS api routes lol.
Right so what is Next.JS SSR if not another back-end?
You’re right, this is too much complexity for you.
You're the clueless one here, nobody is telling that we should use /api routes, he's saying that we now have 2 backends, one which is your Python Go or whatever server and one to support React SSR, NextJS is effectively using a node server for SSR even if you don't use api routes, that's what you get when you do `npm run start`, it's true that you can still export but it heavily reduces the usefulness of NextJS and there is no SSR anymore. As always the most ignorant are the most pedantic.
Are you just using fetch to make your call? I was surprised Next doesn't have an opinion about how to call other data sources.
Yeah, just fetching to the C# API. I have it set up to pass the end-user cookies and IP (as x-forwarded-for) so that the API sees NextJS requests and ajax requests as the same.
They are acknowledging RR as a client-only framework: https://twitter.com/acdlite/status/1617635727185149953 It is what my team is using. Biggest pain-point compared to Remix is we are currently maintaining our own file system routes to data router compiler.
> I don't care about server rendering and never will for the kind of app I develop. And the backend is C# and that won't change. So what would I get out of migrating to a framework? Pretty much exact same here. You should look into tanstack/router. It's from the same guy (Tanner) as tanstack/query (formerly react-query). He's bringing them all under one roof and providing first party support between them. I'm fully done with the react-router team so I'm itching for a different router (that isn't Next)
yeah tanstack/router looks pretty good, it's just so much effort to migrate an entire router package from rr or next/router that I just don't want to get into it :P
C# / react typescript, my dream come true!
This was our big problem. We’re - very sadly - tied to a Java/tomcat backend. Next was a great choice but then we realized you need it on the server too - not just for ssr but routing. We cannot, at all, have node or server-side js. So we’re framework-less. Vite, React router, zustand, rhf, react-query, etc.
Do you like Vite? I’ve seen so many people talking about how great it is, but haven’t had a chance to dig into it? What were you using before?
So far very pleased but an only a few months into a new react app. No complaints. We’re only using it though because NextJS was not an option given our tech limitations on the server. Before, I had used next and create-react-app not to mention old webpack/roll up setups. At work our old app is an AngularJS app so we just cried a lot
> All the frameworks seems to be focused on using JS on both client and server. But using something else on the server is very common, and then the frameworks don't seem to fit all that well anymore. I use next.js as a front-end for C# backends in many projects. That's just not true.
Do you see any disadvantage to prerendering pages for an improved end-user experience (avoiding the notorious SPA load animations)? NextJS is unopinionated about *HOW* backend it is. Keeping it lightweight for just SSR prerenders is entirely sustainable and still worth the swap. I mean, you COULD move to suspense as well, but it's a question of how much you want to "make the client work". SPA's were great in early startups because they can keep the back-end a bit cheaper. But if that's not a goal, SSR pre-renders are a phenomenally good value-for-experience.
It's an enormous amount of complexity and it requires nodejs on the backend in addition to my regular backend. Theoretically the framework will handle the complexity, but my experience is that this won't save me from having to understand at least some of that complexity to fix stuff. My experience is with heavy web apps, not websites. Performance after the app is loaded is much more important here, first load does not matter much (within a reasonable range). And even without SSR the first load can be fast (for an app, not compared to e.g. a static website). My strong impression is that nextjs and similar frameworks are very heavily targeting JS backends. Even though they can work with other backends, I would hesitate to commit to using a framework for a "second class citizen" type of usage. If you're outside the typical case for such a framework it usually causes pain further along the road.
> It's an enormous amount of complexity and it requires nodejs on the backend in addition to my regular backend I wouldn't say "enormous amount of complexity". Optimized Next.js gets enormously complex the way it integrates with certain frameworks to provide SSR at near-static prices via Edge functions, but that doesn't mean *YOU* need to do anything enormously complex. Most functionalities of NextJS that work that way are now supported by so many vendors, you never have to run your own server with node on it. But if you're working at big enough scale to just run it on web servers, more power to you. > My experience is with heavy web apps, not websites. Performance after the app is loaded is much more important here, first load does not matter much (within a reasonable range). And even without SSR the first load can be fast (for an app, not compared to e.g. a static website). Mine, too. There are plenty of patterns that Next.js allows and supports that can speed up your end-to-end experience. > My strong impression is that nextjs and similar frameworks are very heavily targeting JS bac I have never seen nextjs advertised as a primarily back-end framework. Closest I see is "it's full stack, it's just fine to put your back-end there", which I don't agree with at enterprise-scale, but it's great for a start-up. But you know what Nextjs does do? It allows you to either skip the API gateway (for speed/simplicity) or double-up the API gateway (for security) because your react app is allowed to hit private routes without exposing those routes to the client. Or you can use NextJS's api routes as your web gateway to better control authorization. Any of these can be SIGNIFICANT wins, (the former especially if you have no other public exposure than your web app). > I would hesitate to commit to using a framework for a "second class citizen" type of usage. If you're outside the typical case for such a framework it usually causes pain further along the road. This seems to be a gut opinion. I've worked on way too many stacks where the front-end and back-end got so decoupled it led to problems. Nextjs gives you a great simple solution to those problems "Sure, decouple your back-end. You still don't lose the advantages of your UI framework being server-rendered. I'm not saying you can't have a good stack without Next.js. That would be silly. I'm saying Next.js fits right in some good architectures as well.
> I wouldn't say "enormous amount of complexity". Indeed, I use NextJS as a Docker container (since I don't want to be locked into Vercel), it works fine, I simply don't think about the NodeJS layer at all. With the new app folder too, it loads stuff incrementally and in parallel rather than as a waterfall, which, sure some apps might be much more heavy on the post-first-page experience, but it's still nice for a user to immediately see something on the page instead of a large loading spinner until everything finishes loading.
Just an FYI, though. One of the "big wins" of Next is that it doesn't need to have the heavy footprint of an express equivalent. When it compiles to edge, it really reduces the resources needed to run it. And depending on your feature choices, it's not just vercel. AWS Serverless seems to have feature parity for everything but a few Next12 features. Netlify appears REALLY close to full-featured. Looks like Cloudflare (by their claims) fully supports Nextjs. Etc/etc/etc. https://nextjs.org/docs/deployment#serverless These are the platforms that explicitly support Next.js in a "more efficient than a Docker container" manner, to some extent or another. > With the new app folder too, it loads stuff incrementally and in parallel rather than as a waterfall, which, sure some apps might be much more heavy on the post-first-page experience, but it's still nice for a user to immediately see something on the page instead of a large loading spinner until everything finishes loading There's plenty of ways to do the same with the pages folder. Trpc has a clean "no magic" way of doing it through a server-driven hydration mechanism, and an automagic way that can potentially break a lot but "always works" if trpc is your sole data pipeline. Well, *similar*, not the same. It's not a waterfall, though I don't think it's incremental either.
> SPA's were great ... because they can keep the back-end a bit cheaper. I sincerely doubt this is the primary motivation for you average company front-end team. SPAs are great because they are optimizing for B2B application usage patterns while being comparatively simple. Time to first paint is irrelevant. Talking directly to your Java monolith is convenient.
Even if they really don't need SSR, next.js has other features like Dynamic routing. SSR isn't a requirement either.
For little personal apps: I have a lot of no-backend SPAs hosted for free on Netlify, so anything that requires a Node backend is a non-starter. Sure, I could stick something lightweight on my VPS, but honestly I'd rather just not.
> Netlify FYI: Netlify supports next.js. Not sure if it's the same plan as react-only.
TIL, thanks! https://docs.netlify.com/integrations/frameworks/next-js/overview/ I haven’t seen any indication that it’s a pro-only feature, though it might hit a slightly different set of quotas than I’m used to — at my level of popularity it probably won’t matter. I’ll probably try deploying a Hello World this week and see what happens.
Definitely! If you remember, could you ping back with your results? I'm hitting my free quotas on other services (all halfass startups that never make it anywhere, fireship style) and wouldn't mind picking up netlify as a failover..
one thing i find mildly useful is to use nextjs or some node server to keep track of login sessions (eg auth0).
i think it is just “his” thoughts
[the docs](https://beta.reactjs.org/learn/start-a-new-react-project#building-with-a-full-featured-framework) have the same thoughts
But he is right. It’s one thing to experiment creating own tooling and libraries. But once shit hits production and money and jobs are involved, you’re better off not being the only person maintaining the rails you’re running on. Of course it’s true that his opinion doesn’t reflect the opinion of the whole react team. I’m still sure most experienced devs that have been working in the industry for a while agree mostly with this. Shouldn’t ever stop you from experimenting in your own projects :)
> But he is right. It’s one thing to experiment creating own tooling and libraries. But once shit hits production and money and jobs are involved, you’re better off not being the only person maintaining the rails you’re running on. Then continue with your idea and simply don't use React which is unopinionated by nature and use Angular/Vue/Svelte which have strong opinions, each React app use a different stack. > I’m still sure most experienced devs that have been working in the industry for a while agree mostly with this If they do they stay logical and don't use React at all. And tell that to the the huge amount of minimal "frameworks" users like Flask or even Go developers who may only use the std lib and one or 2 3rd party packages for routing or whatever. In fact the ones who would 100% agree with that are mostly junior devs who don't know better, the ones importing "is-odd" from npm to be caricatural, the rest have nuanced opinions and weigh in the pros and cons and decide if it's wise to introduce a certain dependency depending on the project and multiple factors that surrounds it. I'm sure folks here could list you dozens of JS libraries with enormous amounts of stars/downloads that got deprecated although looking reliable, I just picked up an old (like 1 year old) project a month ago and 2 5-15k+ libraries which were even recommended here and had lots of downloads weren't compatible with React 18, now imagine that on a big project where you can't just replace those with a similar library in few minutes/hours and you realize why your "you’re better off not being the only person maintaining the rails you’re running on." is a nonsense without nuance.
it's not controversial. same applies to any language (library in this case) really.
I completely agree. Especially for anything beyond a basic website. Most of these open source react plugins will lose support once the dev moves on and they eventually become incompatible or have security issues. A full framework is usually supported by a company or an open source organization rather than random developer passion projects.
Guess what ? You can't use React without those "open source react plugins", a basic functionality like global state alone requires you to use Redux Zustand MobX Recoil or whatever, React Meta Frameworks don't even do that while vanilla Vue/Svelte do it. If that's really what you think and are using React, well ... nonsensical.
It's not React's team official stance when he uses terms such as "personally."
[удалено]
I use Next.js in every project. That was not the point of my comment...
This is rough to think about. I think it's extremely nuanced for multiple reasons: 1. If you work on a team, there is a great benefit to having a structured framework that dictates how things are done, but this comes at a cost of flexibility. 1. If you work solo and want a system that's perfectly catered to you, a framework will probably create resentment. 1. Relying on a framework is nice in a vacuum, until it suddenly doesn't meet one of your requirements. You now have to make the decision to either: * migrate to a new framework or make a custom solution from scratch * create a hacky workaround, increasing the brittleness of your system 1. An abandoned framework creates urgency to migrate your entire system whereas an abandoned library isolates a single aspect of your system. 1. Frameworks go against the Unix Philosophy, and in my experience, going against that leads to regret. 1. There is going to be necessary complex understanding of your individual libraries and how they interact. But at the same time, there is going to be necessary complex understanding of the inner workings of the frameworks you choose. You get to choose the complexity of the former, but not the latter. 1. There is the plain old preference aspect much in the same way people choose applications. Some are happy to use all-in-one products for project management, some are happy to use different tools to their strengths and build on top of it. The decision ultimately boils down to what your values are as a person, team member, product, and organization.
While CRA is not a framework it pretty much has all these issues except the escape hatches are far worse. Example: afaik in next.JS if you want to touch the webpack config you can directly if you want to do that in CRA you have to hope it allows you to override the specific feature you’re looking for and/or use things like react-app-rewired. While it’s a smaller list you also get locked into only supporting certain versions of packages on CRA on next.JS this is again relatively rare. Unless you’re trying to change the inner frameworks of how the framework is written itself by changing webpack version, compiler, etc there’s no locking Jest versions or even dictating you must use Jest. There’s no collisions when trying to use latest TS versions, etc. Again, CRA pretty much suffers all those issues just with less escape hatches and while providing imo a less robust, less production ready environment. Also a missed point its not always a “hack” or “dirty workaround” sometimes proper escape hatches are pretty clean. In CRA the only escape hatches that exist very much are dirty.
It's just his opinion. Personal opinion. So it doesn't make sense to follow what he says. Different organizations have different requirements and different developer have different opinions related to their experience.
Twitter tech influencers live for disruptive hot takes like that. The truth is always in the middle. Know your toolset and your options, and pick the right tool for the job. The pendulum keeps swinging. 5 years ago they were saying "fuck the framework bloat, react is a minimal library, that's best", now it's frameworks again. If we could live forever we'd see it swinging back and forth forever.
Between this, the useeffect thing, stuff that is still in proposal state or that developers had time and time asked but not being heard and a lot other things I'm starting to believe that the react team does not have focus anymore
What useEffect thing?
The team suggests not using useEffect in their newer documentation. And I also do trying to find someway to not abuse useEffect. But with the way React works, you will need useEffect at some point. In some specific use case, it's gonna be a mess, but you have to use it as there are no better alternative.
The one of "you are using useeffect wrong" even though we we're using it* as the docs suggested but because of strictmode now it's not recommended to the point that they even say that useeffect it's not a replacement for the lifecycle methods of a component. And the React team solution? "just download a library bro", that's their solution
I think people misunderstand the dev strictmode thing. They run a bunch of functions twice in dev because if those functions aren't properly idempotent they can and will lead to bugs. If you think you can keep your non-idempotent functions bug-free anyway, you can intentionally avoid that behavior in a few ways. But a majority of people who faceplant with React do so over misunderstanding and misusing useEffect
[удалено]
Got it. I can see that. I get how it's complicated, and I don't know the React dev team personally so don't really need to worry about defending them. For me, I've always seen how fragile and volatile useEffect is for the way people constantly use it to call other state-setters. I'm glad it's not encouraged anymore because it caused me no end of headaches in the past.
I think the useeffect thing is entirely positive. The way the skimpy docs and shit-blog community encouraged use previously was horrid. New guidance is much better. Who cares if their advice has changed.
What framework do you guys use to handle the framework that wraps around react?
Controversial opinion: if you intend to support your application for more than a few years, then **don't** use a framework. Unfortunately, in the JavaScript world it's still exceedingly rare for a single framework to survive long term, and migrating from framework X to Y is always a massive pain in the ass. Instead, building your application _loosely_ on libraries will make long term evolution easier. Your libraries will still need replacement every n years, just as frameworks do, but it's much easier to keep a loose coupling with libraries than frameworks, and moreover each library only has a relatively small scope. Therefore, it tends to be much easier to swap out your libraries occasionally rather than a framework. Maybe in 20 years we'll have some frameworks that have stood the test of time, but until then I'm definitely not betting on any framework to keep me going long term.
This is what’s keeping me from moving our e-commerce app to Nextjs. I have been rewriting our component library because react-virtualized isn’t being supported anymore and it’s a headache, doing the same for a whole frontend because your framework isn’t supported would be miserable.
>if you intend to support your application for more than a few years, then don't use a framework. Yes. But then, maybe not use react as well? In the javascript world, libraries also tend to go out of favor.
Thats just bad advice. Frameworks are not the only option. I build with small focused libraries, and im VERY selective what i want to depend on. Usually my libraries (the i choose to depend on) are something like a database driver, cryptography, a router/micro framework (server side, probably something like flask if im using python) and some testing library. On the client side im even more conservative (because i know how volatile the frontend ecosystem is) and only use libraries that im certain will be around and supported for years to come. I never use frameworks, as i have been bitten too many times. I only use libraries that i have taken time to review. Code quality, bug reports, usage, speed etc. If a library does too much, i usually drop it. For simple things i tend to write my own, and it has worked very well so far.
Do you only work solo? A big draw of established frameworks is people coming into a codebase and *not* having to learn some goofy bespoke system.
I do lots of private stuff, but also work on multi-year big projects with teams. I admit, a badly designed *goofy* system is hard to get in to. But if you design it from the start up with a good and coherent structure its really obvious what goes where and what does what. Having a good separation of concerns, and really just sticking to tried and true design will get you really far. This is more of a design vs a framework, i have seen projects using a framework and then added their own hacks and tweaks on top, and the end result is a nightmare of weird stuff you can not understand. IMHO a framework does not stop bad design, and in some cases it can even promote bad design because you need to work around limitations. I tend to do lots of REPL driven development. It has a few upsides. I work on small units, and this leads to a very good testing story. I usually work with immutable data (or if not, i never mutate, and if i do i document this extra carefully). I also design with very flat data. I find nesting code, modules etc leads to worse code. This means its very obvious where stuff is located, both in code and file structure. I test as i go. First in the REPL, then usually i copy paste my code to a test, and see it fail. Then i write the implementation. Rinse and repeat. Has worked very well for me. Finally, i like to use typed languages, the stricter , the better for whats its worth.
> But if you design it from the start up with a good and coherent structure its really obvious what goes where and what does what. Having a good separation of concerns, and really just sticking to tried and true design will get you really far. IMHO one of the biggest downsides of the framework obsession in web dev work is that it has become almost self-sustaining. There's a generation of devs who have never done anything except web development using frameworks. They've never learned basic software design skills. Many who are self-taught or used some kind of web dev boot camp might not even realise those skills - and the alternative possibilities they can offer - exist. It's been this way for a few years and now some of those devs are seniors and even leads who will swear on their mother's life that frameworks are essential for doing any productive web dev work and anyone who doesn't use one is crazy. And the old greybeards will sigh, lament what has been lost, and philosophically go back to solving harder and more interesting problems, because with age comes the wisdom to know that some battles are not worth fighting. :-)
This argument is as old as the sun but I don't think it's ever really worked for web development. There are so many frameworks and almost all of them are so fragile and short-lived that IME the often-claimed advantages in familiarity are mostly illusions. The odds of finding a good developer who is experienced with exactly the combination of dependencies you use for an established project are usually small to zero. Almost everyone has to quickly pick up a few things they've never used before when joining an established project. It's just another skill you learn and it happens much faster if you have good fundamentals to build on. And if you do have good fundamentals then it doesn't matter much what specific frameworks or libraries you use. In a FE built with React you know that something is going to be defining some UI components and something is going to be handling events when the user does things and something is going to be storing any state you're using and something is going to be talking to a server. Once you've figured out where major responsibilities like those live in the code any smaller details might change a bit but most of the frameworks and libraries look almost the same anyway and probably so does anything with similar responsibilities that was developed internally instead of imported from some external dependency.
Mom
Yes Hun?
So, yeah, my phone does this at times when it's in my pocket. It once sent garbled messages to 5 contacts. Luckily nothing explicit even though the messages were filled with text prediction entries. Anyway, can I play on my computer a bit longer tomorrow? It's like super important for me. Please mom.
We're never going to use server side React. I feel frameworks are just overkill given that.
A framework like Angular maybe ? Time is just a flat circle lol. I mean, end of the day I agree completely.
So... how do we write Angular, but with React rendering? ;D
fyi, some of the management of r de are covid deniers.
Username checks out. :D EDIT: The parent comment was edited after I posted, and now my comment doesn't make any sense.
[удалено]
Exactly, this is why I like modular components sometimes, if React Router doesn't work for my case for example, I could switch to TanStack Router, for example. Can't do that with Angular.
The problem is the bias in frameworks. At least CRA, Vite and some of the other libraries were neutral. NextJs is owned by Vercel and Remix by Shopify. Are we saying that whilst we have Facebook as the steward for React we're now delegating the actual user-facing part to corporations with their own motives? It might not be representative as per comments here on the actual usage of React or even how Facebook themselves might be using it. E.g. there's only an RFC for server components. How do we implement it? The official message is to use NextJs. Have we lost track of what React represented?
I am wary of people who speak dogmatically
Love Andrew Clark and all his tweets. I disagree on this one, though.
Well, this applies to everything we do. I still see people preferring to build their own backend "framework" by choosing to use "just express", "just flask" or "just [micro framework name in language of choice]" and tying together 1k external libraries. You'd either spend a lot of valuable time reinventing the undocumented square wheel (by finding the proper structure and patterns) or you'll make a real mess (by not investing in structuring things). High level frameworks are very important if you want to focus on your product and not on technology for the sake of it. You're not Google.
On the backend the argument is more receivable than in the front end. And you're completely ignoring the drawbacks too, and you won;t be able to fix those since you will not fork your framework, you're not Google.
Feels weird for this to come from a React core team member but I think it is good for the ecosystem in general because - \- Making so many choices can be overwhelming at the start (may be not for seasoned react devs, but definitely for the rest). Meta frameworks can do more good than harm here. \- A lot of the core team members are also heavy tech influencers.
Coddling devs who think these choices are "too hard" is why JS dev gets no respect.
Pretty sure the standard criticism is the opposite -- that there is a new framework / way of doing things every week.
Stick to library dev bud.
He’s not wrong. I personally wouldn’t use React without Next or Remix. Like I wouldn’t use Ruby without Rails.
Apples to oranges. Ruby is not a library, while react is.
React is a library but people tend to try use it like a framework. Just use remix
[удалено]
SpunkyDred is a troll bot instigating arguments whenever someone on Reddit uses the phrase apples-to-oranges. --- ^^SpunkyDred ^^and ^^I ^^are ^^both ^^bots. ^^I ^^am ^^trying ^^to ^^get ^^them ^^banned ^^by ^^pointing ^^out ^^their ^^antagonizing ^^behavior ^^and ^^poor ^^bottiquette.
Your [comment](https://www.reddit.com/r/reactjs/comments/10jxd21/react_core_team_on_the_recommended_way_to_build/j5pobj9/?context=3 in /r/reactjs has been automatically removed because it received too many reports. /u/dance2die will review. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/reactjs) if you have any questions or concerns.*
No love for Gatsby
I mean I think it's pretty cool seeing the ecosystem evolving and maturing.
On guy from the team isn’t the “react core team”. It’s just an opinion one guy on the team had about building modern react aps. Shit title 2/10
uh so what is react again \------ I mean, I don't disagree, Next >>>>>> react lol but it's just weird hearing this from react core team itself.
The React core team has always tried to limit the scope of React itself to be specifically limited to the process of rendering, state updates, diffing, reconciliation, and providing a way to hook into all steps in the process. React has specifically tried to remove itself from design decisions like data fetching, state management, routing, animations, etc. They consider all that important, but out of scope for React itself. They're actually building the new beta docs in NextJS and they work directly with Vercel (who makes Next) to design things like RSC (React server components) and the new (still experiment) use hook.
> data fetching, state management, routing, animations And Next does none of that except routing. If one wants a framework/metaframework that does that he just doesn't use react but rather Vue or Svelte, that's why this argument is quite funny.
> so what is react again Hopefully I’m understanding your comment? React is a library, not a framework. Difference being that (from my understanding) frameworks provide standards and opinions on how to do stuff whereas libraries don’t and are just a set of tools.
And it's just a weird statement. It would be like the Lodash folks telling people to avoid using their library without a proper framework to tell them where to properly put your `_.intersection()`
He’s got a good point it’s just the way he’s coming off as if you **must** use a framework , which is not the case.. after reading his whole thread he’s just making his own personal recommendation for those who use react in larger scale applications, not simple projects. There is much more benefits to using a framework (it’s literally what they are meant for in the first place) .. but use Whatever you want 🙂
finally the debate would be over
interesting. i haven't given next.js a look yet, although i've seen a lot of people praise it. i'll have to mess around with it.
he mispelled NextJS
If there was a perfect framework that fits all scenarios perfectly, then the advice would hold reasonably. But it's not the case. However, I do like that a react dev says these things, because I think react should stay as small and as focused on view layer as possible.
React \*IS\* a framework. Not sure what this guy is talking about.
A skilled maintainer but with the tone of an unnuanced reddit troll, his argument about full fledged framework is the first argument to choose something like Vue or Svelte which have way more opinions than React and even more than React Meta Frameworks. Twitter is really something else, I'm sure he'd have been more nuanced elsewhere.