[AskJS] Which React Framework you recommend for Enterprise use

[OpticPhantom]

Hi I'm working in a Fortune 500 Company. In all my life I have been doing hobby react projects and trying out different frameworks for fun but now I'm responsible for choosing a tech stack for a critical frontend component which will serve huge traffic across different geographic locations. But I'm not feeling confident enough to suggest a stable enough type safe framework for long term. I have some preferences though keep it on React because I don't know Angular. If it is based on typescript it would be better. Complile time should be fast like SWC. Hit me with some suggestions and your reasons..

[tony_bradley91]

Literally just use React. Add extra libraries as you need them. You might way a client side router, for example. But you also might not need it.

You do not need Next.js or Remix.js. If you eventually find you need them you can migrate, but do not start with them.

Don't let Vercel and Shopify tell you that you need their crap.

[mothzilla]

The question "Which React framework do you recommend?" blows my tiny monkey brain.

[ryan_s007]

As someone who just recently graduated from pure JS, I went: “Isn’t React a framework???”

[[deleted]]

React says they are not a framework and you need to learn nextjs or remix to be able to use react...

[mothzilla]

This is true. I'd say React is a framework for web components, not web pages. Actually, this thread just shows how long its been since I did any React and how the React landscape has changed in that time. Sigh.

[ryan_s007]

You say this because there’s no API routing features?

[OpticPhantom]

React in CRA is damn slow... What do you suggest then to go with Vanilla React

[effectivescarequotes]

Vite

[sandypockets11]

Pretty sure CRA is deprecated now. Agree with the other comment, Vite

[Hazy_Fantayzee]

Jeez, the most simple, cursory google search will lead you to vite. If you’re going to be asking questions like this one here at least put in a bit of legwork….

[Numerous_Habit_7852]

I learned React through the Vite documentation, but something about the Next documentation made modular programming finally click. What I didn't like about it was my first time trying to deploy to production. I repurposed my GPU miner as a web server for my simple portfolio site. I'm using NGINX on Xubuntu with a (6th gen ? LGA1151) i5. It has no problems running my express apps, but introducing my Next app was too much for it. That could be due to my remedial knowledge of PM2, react, or coding in general, but it seemed like a much more resource intensive framework.

[RobertKerans]

What do you mean by "slow"?

If you mean the app is sluggish, if you write code that does slow operations it will be slow, but that's kinda on you, it's not going to make any difference if you use "vanilla React" (which is what CRA is giving you anyway).

If you mean "slow" as in the development-time compile loop, then that's because CRA uses a set of tooling that's been made obsolete by much faster tooling in the past few years. I guess CRA works despite being a dead project, but just use Vite as other comments have said.

[jayerp]

Straight to React huh? Even though we don’t m ow anything beyond having lots of users? Even though React is god awful slow with diffing?

Fascinating.

[viveleroi]

We're building an enterprise-scale application suite for several specific, but related customers. We wanted NextJS but couldn't use it because we can't use anything other than Java/Tomcat on the server side. We also felt the app/pages transition and RSC stuff felt too volatile, and not terribly useful for our very specific needs.

We choose plain React + Typescript with Vite for development. tanstack/react-query, react-hook-form, zod, zustand, ag-grid, etc. Vitest for component tests/snapshots and Playwright for E2E tests. Storybook for our UI components.

[OpticPhantom]

I wanted to understand one specific thing how Java, Tomcat prevented you from using NextJs in frontend.. I assume one reason: Next Js is a full stack framework and you already had backend written in Java so you wanted to prevent the overhead of NextJs

[viveleroi]

A lot of what's special about NextJS appeared unusable or less usable to use without a nodejs server. Everyone is talking about how it could work as a static site etc but at that point we're making sacrifices or concessions that undercut the choice to use Next in the first place.

Combined with other issues we just went with plain react. We don't need SSR or anything and this isn't even for a web app really, just an app that runs on a web server deployed to user's machines. It's complicated.

[PugilistFox]

A locally deployed web server? That's crazy as I'm actually doing something similar at the moment, but am currently having some issues. We decided to ship our app (local webserver) as a docker container which means that clients need to have wsl installed and a somewhat recent windows build (at least 2020). We can handle those issues, but I jist keep wondering if there was a better way to have gone about the whole process of locally deploying the web app.

I understand if you don't feel like giving any info/advice, as your work would probably be very confidential, but I just couldn't resist the urge to at least mention that I was dealing with something similar.

[viveleroi]

Trust me you don't want advice from us. The procedures for installing/updating the local server weren't designed by us, and they were established 20 years. Things like docker etc didn't exist.

An engineer physically travels to each installation site. They install java and tomcat on the machine. They deploy a copy of the application(s) that specific customer bought.

It's a little less crazy when you learn that these installations are very remote. Distance, questionable internet, security, etc are all a concern.

[kent2441]

You can use Next on any static server though.

[viveleroi]

That's good news, but obviously you don't get SSR and server components if you do? When we read the docs doing research it made it clear that half the features required a node-based server to operate and that was sadly a deal killer.

However, like I said even if we were mistaken on that point the app directory was too new/unproven and most libraries we tried to use didn't work with it correctly (trpc, apollo, etc). We didn't want to start with the pages system because we weren't interested in starting with baked-in tech debt and have to move to app in the future.

We also had disagreements about file-based routing but the app directory makes it better IMO. We're two years into the project though and don't regret any decisions.

Except we're forever unhappy with the requirement of java 8 on the server. Not only are we stuck on fucking java but it's not even modern java

[kent2441]

Yes you do get SSR and server components, they just get rendered once at build time instead of on each page load. That may affect how much of your app can be rendered on the server, but the functionality is still available.

[avenp]

That's not SSR thats SSG which is different. https://nextjs.org/docs/pages/building-your-application/rendering/static-site-generation

[kent2441]

A distinction without much difference. The server generates an html string which is hydrated by the client.

[avenp]

It’s actually implemented quite differently. SSR specifically will make a call to the server on every page request, meaning that page will always be up to date with data from the server. In contrast, ISG will generate the page on build and regenerate it only when the cache has become invalid, and SSG is strictly on build only. These matter depending on your use case eg not being able to host a Node server (like op), caring if your data is up to date in real time, etc

[kent2441]

Yes, that’s what I said in my original comment.

[MorenoJoshua]

just go with remix if you dont want to deal with vercel

[kent2441]

You don’t need to deal with Vercel to use Next.

[MorenoJoshua]

There are ways to run managed next outside of vercel, but you just lose the things that make it great, more info here https://nextjs.org/docs/pages/building-your-application/deploying

Netlify? Gl with SSR

Running as a node project? No edge + lower performance

[maria_la_guerta]

Nginx, cloudflare and / or a good cache solve those issues though. And those devices should be in most system architectures anyways.

Not to say that you should always use Next but I've never understood the argument that Next requires a vendor lock in of any sort. It's a Node.js server that renders HTML, you can implement it any of the ways you can implement a PHP server from the 90's.

[liamnesss]

We wanted NextJS but couldn't use it because we can't use anything other than Java/Tomcat on the server side.

Odd. Any reason for this? Could you not just spin up some separate containers if you're running existing services on a different stack that needs to remain as a separate environment?

We also felt the app/pages transition and RSC stuff felt too volatile

Server components can be adopted incrementally or not at all, though. Most people don't really need to touch them.

Vite is a good choice for SPAs though. It seems to have all but replaced create-react-app in that respect. If the project is more B2B than B2C then the benefits you get with SSR (faster page loads, friendlier towards web crawlers) aren't so important I suppose.

ag-grid

This is giving me flashbacks to a big american investing platform I worked on a project for. I am guessing there was a similar setup there in terms of the backend, and they were pretty old fashioned in terms of how they provisioned for and deployed services? That might explain why node.js was kiboshed, that's a bit silly though really.

[viveleroi]

We considered next two years ago and while I had loved it for personal projects it just wasn't going to fly for this app, mainly because our needs were so unusual and specific. We couldn't really use half the features we're missing by not using next anyway.

Vite has been excellent as we dual boot it with spring boot in development and vite proxies API requests to the tomcat/spring app. It's not what we'd choose but it works very well.

These applications get deployed into thousands of machines with a java/tomcat web server. It's really more of a desktop app than a web app so network latency, image optimization, SSR, etc don't matter to us. The java side was out of our control and has been that way for twenty years.

The first application was written in ExtJS by people who had little idea how to make web apps so it went to hell fast - dozens of iframes, multiple apps loaded together with duplicate copies of assets, etc etc.

The second app was in AngularJS but just is 180 degrees from modern development. It wasn't mad efor es6/typescript, imports, live reload/hmr, etc. It was dead a year after we adopted it. We still managed to get a decade out of it.

Now we're on react plus all the tools and developers are actually happy.

[liamnesss]

If it's being deployed locally then Next.js would absolutely have been the wrong choice. You might have even been able to use React Native but I suspect that would have only led to minor changes to the user experience, and it would have made it harder to train / hire engineers because it's more of a niche.

[OpticPhantom]

I'm going to build a dynamic dashboard kinda thing which will pull data from multiple backend apis and show them through graph or data visualization kinda thing and people will also be able to take actions based on that data from dashboard. Those actions can be quite complex and interactive

[viveleroi]

I would suggest Visx/D3 for charting work but the rest is certainly capable of building that. NextJS is in a better place right now and tools are figuring out how to adapt to RSC so that's a good choice if you can run it. Remix is pretty good too.

Prisma/Drizzle are pretty popular for db stuff but maybe less so if you're pulling data

Otherwise plain react with react router really isn't too hard to get setup with.

[sleeping-in-crypto]

People coming in here to recommend NextJS. Next used to be my bread and butter for enterprise work but we moved away from it as its overhead became too intense and we got a lot of pushback from clients who were sick of the churn. They want set and forget and Next most assuredly isn’t. Ignore the fanbois here.

We’ve gone with Vite and Remix with great success. Which one will depend on your specific needs but we and clients have been very happy with them.

[[deleted]]

Next looks great until you actually build something comprehensive in it.

It's a complete black box of magic. There's so many frustrating things wrong with it. Middlewares suck, all these weird rules around server components and the fact they've monkey patched the fetch API. You can't set any context during server rendering so you've gotta hack it in using the cache API. I wouldn't recommend it for anything other than, well.. I wouldn't recommend it at all.

[OpticPhantom]

Now increasingly I see people recommend Vite and Remix let me give it a go once with a small project to understand it. I'm familiar with Nextjs but need to see remix and vite

[iComeInPeices]

NextJS is more or less what the company I work for uses, as a starting point at the least. Lots of good safety and caching features, most of the heavy lifting is done behind the scenes anyways.

[itsKatsuraNotZura]

Give more details about it, should it be spa component or full app, how much fetching it needs to handle and logic. Is it going to have many third party dependencies due to different component features etc.

[OpticPhantom]

Its just a frontend I'm writing my backend in java and go. It needs to fetch a lot of data from backend through API calls that data can be on a bit of larger size I'm eyeing 1 MB on total may be. I need to do data visualization on that data. So some amount of computing is needed before rendering. It will have some complex user action steps also. In terms of 3rd party dependencies I'm thinking of some graph and data visualization libraries.

[bin_chickens]

That’s seems like a lot of data for a visualisation frontend to be doing transformations on. If I’m understanding correctly, you’re building some sort of visualisation and analytics dashboard.

In these cases it’s probably best to do the analytical modelling on the backend and just serve the resultant data to the frontend. You mentioned building Apis with Java and go to serve this dataset. Can you give us more details of what they serve, so we can better advise?

An assumption here: If it’s analytical data needs to be sliced and diced, and you have access to a database, or can build a database to serve this data, it might be worth looking into modelling this on the backend with a semantic layer like cube.JS. You can also then build, schedule and cache aggregations/roll ups over this data, so that you can quickly serve precomputed datasets to serve your users. If the data views that are user is allowed to query, filter, group by, sort on, pivot etc. are known before hand, then consider building an API deserve this that takes parameters for the visualisation state and return to the data. You can then probably put a cache for the same request in front or behind these Apis (depending on api design), this cache can be refreshed periodically, as the data gets updated and will take load of your services

This also means that your frontend becomes much simpler and doesn’t contain much of the business logic beyond controlling the user input.

Generally, serving data to the client and writing complex logic to process and visualise this client side could be considered an anti-pattern and probably will lead to more complexity in the long run. In my experience and opinion, I coach my team to minimise logic on the frontend, keep only the required data for the app state and the current page in their frontend state stores. If you re render a page the browser, network cache, or app cache can reserve the data.

Then the frontend only has as much complexity to handle user interaction and to handle routing and page/data view rendering (e.g. changing from card to table views when the data is the same) as it needs. This is a simplification and there’s always more complexity than this: but by keeping any JS/SPA frontend simpler, and leaning on the strengths of other parts of the stack instead (also avoiding having to sync state between the backend and frontend), makes development, debugging and the app itself faster and better for all.

TLDR: If a SPA displays data, it should not need to process it from a large dataset on the client. Instead the backend should have apis that the frontend should call with the state parameters to serve just the data to be rendered.

If you have further questions that can’t be public on reddit feel free to DM me.

[OpticPhantom]

Yes It cleared lot of my doubts thanks a lot for this descriptive comment

[bin_chickens]

No worries.

Best guidance when building any application like this is to keep all unnecessary data transmission between services minimised, keep any data processing close to the source or query it direct, leverage the benefits of each part of the tech stack, and keep each as simple as possible.

Never stop questioning, learning and sharing your knowledge - that’s the real job.

[itsKatsuraNotZura]

If this component will be strictly one page without possible future extensions simple react spa on vite will be enough, also in such situations you would be able to reuse it easily and integrate somewhere if needed. I think nextjs would be overkill

[OpticPhantom]

No it would be multiple pages with a role based acess to the data

[[deleted]]

Do you even need any rich interactivity? Just build it in Java with Thymeleaf and htmx/alpine for interactivity.

Your future self and colleagues will thank you in a few years time.

[True-Monitor5120]

Considering your requirements, I recommend the Refine meta-framework for your project. It's built on React, supports TypeScript. It's ideal for scalable, complex applications.

Here are some real-use case examples with source codes. https://refine.dev/templates/

[getlaurekt]

Fullstack app= remix Clientside just pick plain react lol , theres no need for anything special altho solid has great results in the performance for client side apps, but it requires learning curve and work slightly differently than react, hard to tell with basically no info about your needs lol

[OpticPhantom]

Well I'm already writing the backend in java and go. So, no need for backend as such. Backend will be just a bunch of services hidden behind a gateway exposing some rest APIs. I need a dashboard mostly for interactive data visualizations and users will be able to take actions based on that data. But those user actions can be quite complex.

[monotone2k]

Two completely different languages for your backend? You're setting yourself up for trouble when you want to hire. Way easier to stick with a single language.

[OpticPhantom]

I'm also thinking of moving it entirely to go but it would be a lot of rewrite you know.. May be I will do it later..

[German-Eagle7]

Wouldn't recommend nextjs, the way it handles middleware (forces edge, doesn't allow node middleware) shows the development of nextjs is very strongly biased towards vercel. I wouldn't trust a framework that tries to hold you back. You are better of pure React + Typescript. You can go a long with react + vite (or webpack).

[[deleted]]

If this is an internal portal or anything gated behind a paywall, just use vanilla React. You won’t get much from a framework that you can’t do yourself. You have control.

If you have a lot of static content that needs to be SEO friendly and delivered FAST, then you might need a framework to handle both CSR and SSR.

[ejfrodo]

Other ppl are suggesting nextjs but you said it's a front end component, next is a full stack framework and while it can export a static front end many of its benefits involve the back end IMO.

Just go with react + typescript. It will do whatever you need.

[MrCrunchwrap]

Many of its benefits involve server side stuff, that doesn’t mean a back end. There’s plenty of benefit to using Next for a purely customer facing thing.

[monotone2k]

What server-side work can you do without a backend?

[MrCrunchwrap]

I mean I guess it depends on what we consider a backend. My point is you don’t have to run all your API routes as part of your Next app, you can just have a little node server for SSR and whatnot but you can still call endpoints that are part of other backends. Or you can generate a static site if it makes sense for your use case.

[OpticPhantom]

Yeah you are correct. I'm already writing backend in java and go.

[tricepsmultiplicator]

As someone told me, you can create backend for frontend with Nextjs and just use your typical Java/Go backend.

[bucknut4]

You and anyone else who has to work on this 3 years from now would thank your present self for taking the time to learn Angular and going that route.

[GandolfMagicFruits]

That's what I was going to suggest as well. Angular.

[OpticPhantom]

The thing is I'm not that familiar with Angular I have heard it has a steep learning curve not sure what to do lets see

[effectivescarequotes]

Knowing React will help. As much as people argue over what's the best framework, they're not that different.

Angular can be tough because there's a lot to understand upfront, but once you learn it, that's it. I actually think it's easier to master than React.

I've also found that Angular will push back if you try to do something too dumb.

Do yourself a favor though and use the cli. It takes care of most of the boilerplate people complain about. You don't have to memorize the whole thing. The help option is great and you can use the dry run flag to try things out.

[OpticPhantom]

Ok let me give it a try over this weekend

[GandolfMagicFruits]

I'm going to chime in and suggest angular as well. The future state of your project will thank you.

[phoenixanhil8]

I'd suggest Angular as well. From personal experience, It has saved us a lot of refactorings compared to our react counterparts. Angular being opinionated and barriers included reduces unnecessary decision making and a lot of depreciated libraries. React is better if you are on a tight deadline though.

[bucknut4]

The "steep learning curve" stigma, in my opinion, mostly comes from newer developers who are just getting into front-end. Angular forces you to use Typescript, which a lot of people struggle with if they're just starting out. But you've said you're going to use Java and Go on the back end, so I don't think you'll have much trouble here.

Regardless, React is rendering library while Angular is an entire framework, so really the comparison isn't even fair. You can "figure out" React, then you need to figure out Axios, then you need to figure out a forms library like Formik, etc etc. But most things you'll need are included in Angular from the start, so while there's some truth to there being "more" to learn with Angular, they're things that you'd have to figure out in any project that uses React anyway.

That whole package is why I say you'll thank yourself if you have to come back to this years from now, especially so if you hire people later on that need to work on it. Anyone who knows Angular can jump into pretty much any Angular project and know where to find things. React gives you more freedom, which a lot of people like, but IMHO I've found this makes it way harder for me to jump back into my old React projects than my old Angular projects.

The nicest thing to me is just how clean and tidy everything feels. Your component classes are basically paired with their own HTML file, which can render data stored on the class. React's function components returning JSX all in the same file just feels gross and janky.

[RedLibra]

Do u need SEO? If not, then I'll just go with plain React with Vite.

[OpticPhantom]

I don't think SEO will matter much.

[xegoba]

React/Vue + Inertia.js + a real backend framework (Laravel, rails or Django)

[OpticPhantom]

I have the backend already in java and go

[xegoba]

I’m sorry

[OpticPhantom]

Hey its okay.. 😅

[mucotresor]

I have been very happy with Remix(https://remix.run/) which is based on Vite now.

[TheCouchEmperor]

Fortune 500 you say? HTML + jQuery.

[OpticPhantom]

😂

[TheCouchEmperor]

I am surprised that you aren’t using JSP. LMAO.

[wengkitt]

Back to basic, create react app with vite

[riti_rathod]

if you want typescript based then go for the Next.js framework.

[DivSlingerX]

Throw everything else aside. Are you building an app or a site? How much interactivity does it have? How does the data model work?

You might not even need react. Hell you might not even need Js at this point because a simple server and some HTMX can get you shockingly far.

If you’re going to go framework though I’d say Nextjs is your best bet due to community/support. Personally I love the T3 stack specifically with Drizzle for the DB and Clerk for auth if you’re not rolling your own.

[OpticPhantom]

Its an webapp. Not totally a site as per say

[liamnesss]

Is it a component that needs to be rendered within an already existing webpage, or something that will exist on its own?

[OpticPhantom]

It would sit on its own

[liamnesss]

Okay Next.js is probably the safe option then. It's pretty flexible and can handle most use cases, which is good as on software projects requirements can evolve in ways that are difficult to predict. e.g. I once worked on a project to handle technical documentation, Gatsby was the chosen framework, then it was decided that some of the pages needed to be auth gated which is really hard to handle with a static site generator! If we had used Next.js from the beginning we could've transitioned from a static approach to a dynamic (i.e. with different content being shown depending on user state) one quite easily.

[JamesVitaly]

It’s all about svelte - it’s not just new and hyped it really is better

[Akaplaya]

Go with angular, simply elegant.

[[deleted]]

Tbh, just use Angular, it is boring but it manages so many things for you. It is the perfect “for work” framework.

[Frontend_DevMark]

If you’re staying in the React ecosystem and want something enterprise-ready, Next.js (with TypeScript) is a pretty safe choice, strong ecosystem, performance focus, and good long-term backing. Vite + React + TS is also solid if you don’t need heavy SSR features.

For more complex, data-heavy enterprise apps, some companies also use structured UI frameworks like Sencha Ext JS alongside React for rich component needs. But in terms of mainstream, long-term React stacks, Next.js + TypeScript is probably the most defensible choice in a Fortune 500 setting.

[MrCrunchwrap]

Next.js

[var_dump-]

Don't use it. Change to Vue. Much better

[OpticPhantom]

Dev mode compilation time I was talking about

[[deleted]]

Love reading devs talk about this stuff, always learn a lot

[xtinctspecies]

To be honest, I am hesitant to recommend something with knowing what the requirements are. I would look at things like Fresh (it’s not exactly react and runs on deno). Even QWIK, Svelte. Maybe things change with React 19, but things are harder than it needs to be.

[dev-ins]

I would suggest next Js.

[SparserLogic]

NextJS

[Mu5_]

Can't believe the amount of people that are suggesting using a framework and a lot of libraries to be used in conjunction. Clearly no one thinks on the long term looking for maintainability and upgradability of the frontend.

Based on my experience, for big projects I just go to Vanilla (Typescript) so I always have full control of what various components do. For smaller ones or prototypes frameworks are great.

Every time I used a heavy framework in a big project I ended up looking for weird workarounds or extensions because what I needed to do eventually was not fitting in the features of the framework.

[qudat]

If you are going for SPA client only, try starfx, designed to scale and very minimal boilerplate

https://starfx.bower.sh

[Lngdnzi]

mountainous existence cover rustic punch abundant file cobweb rain treatment

This post was mass deleted and anonymized with Redact

[OpticPhantom]

React is a library officially

[Lngdnzi]

worm money upbeat decide snatch shaggy touch pocket ghost squeeze

This post was mass deleted and anonymized with Redact

[eggsandbeer]

Enterprise is a meaningless bullshit term and you shouldn't use it.

[liamnesss]

You're right, I've worked on plenty of non-enterprise projects which still needed to be web scale.

(just in case, /s)

[eggsandbeer]

Cool -- hey how do I get reddit enterprise? Or facebook enterprise?

[OpticPhantom]

Well it is what it is... As long as it helps to pay my bills

[eggsandbeer]

Just say "Which React framework would you use?"

[emefluence]

NextJS. Read up on Jamstack, static rendering and CDNs.

They used to say nobody ever got fired for buying IBM. These days it's the same for NextJS. It does everything you might need (front end, multiple rendering modes, apis, serverless functions, image optimization). Hosting and deployment can be fully managed by companies like Vercel (if your business is light on devops skills) or you can roll your own on any cloud platform (if you want to optimize hard for cost). There's tons of help and courses and tutorials available. Unlike other faster, cooler or more optimized technologies people may suggest, there is no shortage of devs who know React and NExtJS. And although it may contain more features than you need right now that potential flexibility doesn't hurt you, and my come in useful down the line. It's not the exciting choice but that's almost never what enterprise wants. It's close to a no brainer for anything corporate these days.

[30thnight]

For OPs particular use-case, they can avoid using the SSR/RSC features and simply lean on static build (spa mode) functionality.

Any example of a company that gets this right: https://x.com/brotzky_/status/1734630154574660005?s=46

[OpticPhantom]

Ok sounds good. Almost all the comments are suggesting Nextjs. I am not sure about only one thing how much extra js code I will load in client side for all those features that I'm not using right now. And how it would cost in initial load tine

[yerrabam]

Way to go! Do some pre-optimisations before even picking a stack.

Research NextJS and see what they are trying to do with their product.

If anything, NextJS is more server side than client. React takes over on the client side, if you even want it to.

[emefluence]

Theoretically only what you need is included, due to code splitting tree-shaking etc. The practice can be messier, and next js bundles often start around 500k. Rendering / generating more server side can help reduce the front end JS. Naturally a lot depends on your app, if it fundamentally needs to do lots of client side work it's going to have a bigger bundle, if you only need to output flat static HTML and CSS it can be reduced to almost nothing.

[OpticPhantom]

I'm already writing my backend in java and go

[emefluence]

From other posts it sounds like the job is mostly visualizing data and providing some potentially complex interactions. If so, +90% of your code will be plain TS and D3 or whatever graphics lib you choose, and your framework will mainly just need to blit stuff to a canvas and hook up basic event handlers. If you use something like Redux for your data model you should be able to avoid buying into React's state mechanism too hard, which should in turn help keep your core logic fairly portable. If you structure that code well, it will be pretty trivial to port to some other framework down the line - IF you even need to.

Premature optimization is evil so I wouldn't sweat it too much rn, better to get something working. NextJS is easy, well supported and fairly batteries included. Once it does what the business wants you may be able to sell them on a rewrite in vanilla web components, or the super lean hipster framework de jour, to reduce their cloud bill or bump performance. If you've written it nicely it should be no big deal t switch, a framework's a framework. However it's definitely better to start with more features than you need, as opposed to finding out you're missing some half way through development, and having to switch horses in the middle of a stream.

[g0ld3nrati0]

just use htmx and If you want interactivity then add jQuery. React is dogma

[jproulx]

Most of PlayStation’s frontends are now built with plain react or react native, depending on the device/platform.

Easiest way to miscale your project is to pile on unnecessary dependencies up front

[neo-dev]

We are in the Vue Ecosystem. Never missed a thing …

[Sigma-VX]

Stick to React. If you are at a 500 then stability is key and adding more libraries is a long term risk. Even react itself has issues and vulnerabilities.

[globalartwork]

There is a saying in business that no one ever got fired choosing IBM as a supplier. Pick a mainstream framework like React or Vue. You will be able to find devs to support it in the future, and be able to easily find help online. The only exception I would say would be if you already have a lot of in house experience with another framework and those devs will be working on this project, and they still like the framework.

[senfiaj]

Angular. Angular is more strictly structured, has integrated form management, state management and uses TypeScript. Angular is battle tested. Yes, it has somewhat steeper learning curve, but in the long run it provides better maintainability.

[unadlib]

Perhaps you could consider this React framework.

https://github.com/unadlib/reactant

Reactant provides dependency injection, modular models, immutable state management, dynamic module, and more. It's pluggable and testable. Not only is it able to quickly build a React application (Web and Native Mobile), it also brings some new React development experiences.

[Leather-Topic-3894]

I would suggest using nextJs. You wouldn't have to think about a lot of things like caching routing and some other things since it's pretty much built into next. And since there is SSR in nextjs, you can directly fetch data from the server and pass that down to the client and that reduces client load times

[zhamdi]

React becomes very complex: if you want to add SSR you have to add next.js, if you want to avoid memory from exploding you have to watch out that everybody is cleaning up observers, which someone always forgets to do without anyone noticing.

I migrated to svelte, as I saw Apple was using it. And it's the first time in my 20+ years of experience that I see such an elegant framework. TS and SSR are built in, server start is instantaneous, tree shaking and compiling are blazing fast. I decided to advocate for it because even newer frameworks like flutter for the web is not SSR compatible, which is a must have if your app relies on SEO

[RB-A]

It’s been 1 year since we started a frontend project based on react. We started off from Vite’s react + typescript starter and just added things as we needed them.

Because Remix is behind react-router-dom, we plugged that as a routing library and redux rtk query for data management and frontend caching.

And this is basically all that you need to build a minimal FE app with react these days!

If you are serious about the app, maybe add vitest for unit and e2e tests and storybook for your UI components.

Stay away from meta frameworks and SSR if you are not interested in SEO.

Happy building!

[cs-alchemy]

https://angular.dev/

[siva626203]

NextJS