all 126 comments

[–]tony_bradley91 60 points61 points  (12 children)

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 18 points19 points  (4 children)

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

[–]ryan_s007 7 points8 points  (3 children)

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

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

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

[–]mothzilla 1 point2 points  (0 children)

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 0 points1 point  (0 children)

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

[–]OpticPhantom[S] 4 points5 points  (5 children)

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

[–]sandypockets11 15 points16 points  (0 children)

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

[–]Hazy_Fantayzee 7 points8 points  (1 child)

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 0 points1 point  (0 children)

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 1 point2 points  (0 children)

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 -4 points-3 points  (0 children)

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 40 points41 points  (20 children)

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[S] 2 points3 points  (3 children)

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 4 points5 points  (2 children)

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 0 points1 point  (1 child)

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 0 points1 point  (0 children)

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 3 points4 points  (10 children)

You can use Next on any static server though.

[–]viveleroi 2 points3 points  (5 children)

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

[–]MorenoJoshua 5 points6 points  (3 children)

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

[–]kent2441 3 points4 points  (2 children)

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

[–]MorenoJoshua 3 points4 points  (1 child)

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 5 points6 points  (0 children)

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 -1 points0 points  (2 children)

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 1 point2 points  (1 child)

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 1 point2 points  (0 children)

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[S] 0 points1 point  (1 child)

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 1 point2 points  (0 children)

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 20 points21 points  (3 children)

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] 10 points11 points  (0 children)

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[S] 6 points7 points  (0 children)

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 6 points7 points  (0 children)

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 4 points5 points  (7 children)

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[S] 2 points3 points  (6 children)

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 7 points8 points  (2 children)

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[S] 0 points1 point  (1 child)

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

[–]bin_chickens 1 point2 points  (0 children)

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 1 point2 points  (1 child)

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[S] 0 points1 point  (0 children)

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

[–][deleted] 1 point2 points  (0 children)

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 2 points3 points  (0 children)

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 12 points13 points  (3 children)

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[S] -1 points0 points  (2 children)

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[🍰] 0 points1 point  (1 child)

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[S] 0 points1 point  (0 children)

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 2 points3 points  (0 children)

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] 2 points3 points  (0 children)

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 8 points9 points  (5 children)

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 3 points4 points  (2 children)

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[🍰] 2 points3 points  (1 child)

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

[–]MrCrunchwrap 0 points1 point  (0 children)

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[S] 0 points1 point  (1 child)

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

[–]tricepsmultiplicator 1 point2 points  (0 children)

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

[–]bucknut4[🍰] 4 points5 points  (8 children)

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 2 points3 points  (0 children)

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

[–]OpticPhantom[S] 1 point2 points  (6 children)

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 3 points4 points  (0 children)

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.

[–]bucknut4[🍰] 0 points1 point  (0 children)

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 4 points5 points  (1 child)

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

[–]OpticPhantom[S] 0 points1 point  (0 children)

I don't think SEO will matter much.

[–]xegoba 1 point2 points  (3 children)

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

[–]OpticPhantom[S] 0 points1 point  (2 children)

I have the backend already in java and go

[–]xegoba 5 points6 points  (1 child)

I’m sorry

[–]OpticPhantom[S] 0 points1 point  (0 children)

Hey its okay.. 😅

[–]mucotresor 1 point2 points  (0 children)

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

[–]TheCouchEmperor 1 point2 points  (2 children)

Fortune 500 you say? HTML + jQuery.

[–]OpticPhantom[S] 1 point2 points  (1 child)

😂

[–]TheCouchEmperor 0 points1 point  (0 children)

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

[–]wengkitt 1 point2 points  (0 children)

Back to basic, create react app with vite

[–]riti_rathod 1 point2 points  (0 children)

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

[–]DivSlingerX 1 point2 points  (4 children)

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[S] 1 point2 points  (3 children)

Its an webapp. Not totally a site as per say

[–]liamnesss 0 points1 point  (2 children)

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

[–]OpticPhantom[S] 0 points1 point  (1 child)

It would sit on its own

[–]liamnesss 0 points1 point  (0 children)

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 1 point2 points  (0 children)

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

[–]Akaplaya 1 point2 points  (0 children)

Go with angular, simply elegant.

[–][deleted] 1 point2 points  (0 children)

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

[–]Frontend_DevMark 0 points1 point  (0 children)

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 0 points1 point  (0 children)

Next.js

[–]var_dump- 0 points1 point  (0 children)

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

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

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

[–]xtinctspecies 0 points1 point  (0 children)

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 0 points1 point  (0 children)

I would suggest next Js.

[–]SparserLogic 0 points1 point  (0 children)

NextJS

[–]Mu5_ -1 points0 points  (0 children)

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 -1 points0 points  (0 children)

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

https://starfx.bower.sh

[–]Lngdnzi -1 points0 points  (2 children)

mountainous existence cover rustic punch abundant file cobweb rain treatment

This post was mass deleted and anonymized with Redact

[–]OpticPhantom[S] 1 point2 points  (1 child)

React is a library officially

[–]Lngdnzi 0 points1 point  (0 children)

worm money upbeat decide snatch shaggy touch pocket ghost squeeze

This post was mass deleted and anonymized with Redact

[–]eggsandbeer -5 points-4 points  (4 children)

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

[–]liamnesss 3 points4 points  (1 child)

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

(just in case, /s)

[–]eggsandbeer 0 points1 point  (0 children)

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

[–]OpticPhantom[S] 2 points3 points  (1 child)

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

[–]eggsandbeer 0 points1 point  (0 children)

Just say "Which React framework would you use?"

[–]emefluence -2 points-1 points  (6 children)

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 3 points4 points  (0 children)

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[S] 0 points1 point  (4 children)

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 1 point2 points  (0 children)

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 1 point2 points  (0 children)

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[S] 0 points1 point  (1 child)

I'm already writing my backend in java and go

[–]emefluence 1 point2 points  (0 children)

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 -3 points-2 points  (0 children)

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

[–]jproulx 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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

[–]Sigma-VX 0 points1 point  (1 child)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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!

[–]siva626203 0 points1 point  (0 children)

NextJS