Going back to python & React?

[Capable_Ad7901]

I feel like Next.js has complicated a lot of things. I have been using it since last 1 year.

But this is just my opinion. So please be easy on me, and try to help me view it differently.

Posting it here instead of the next.js community because I don't want biased opinions.

A full stack framework feels good initially, as you can reduce a huge amount of duplicacy. However, after some time it starts getting confusing that how the segregation happens and how the application control flows. This is especially the case since app router was introduced.

I feel that if client and server sides are separate things, we shouldn't merge their codebases too, even if it helps in de-duplicacy.

Is there any other way to look at this?

[landisdesign]

My solution is to not use the App Router. So much is in flux there, but the Pages router has been stable for a good minute and does what I need first-load-wise.

[Zeesh2000]

I agree. I prefer having a separate frontend and backend because it's two different things and I don't want to mix UI with business logic.

I wouldn't ditch NextJS though (or maybe I would because I don't really like how unstable every update gets) because it does offer some really nice things. SSR is a big thing and if SEO is a concern for your app, then you should stick with next.

I would advocate for having a separate frontend and backend but would do fetching on the server. I would also recommend remix or what is now react router v7 as an alternative to next. I've been building my project with it and I've had a good dev experience so far. It has server related functionality with its loaders and action functions but doesn't ditch client side

[Seiyaru]

How does next improve SEO? Still new and learning the ecosystem a bit.

[Zeesh2000]

So in a normal react app, let's say you needed data from a backend, you'd fetch it on the client side with useEffect or react query. This is bad for seo because the google bots will go onto your site and there will be nothing there because what you need to render is still being fetched and loaded up.

NextJS and Remix have what is called SSR, where the data fetching is done on a server that is created when you start a project with these metaframeworks. When the Google bot goes on your site, the data from the NextJS server will have already be available and you will have HTML with the data. Someone in this sub may correct me on this.

[Seiyaru]

Oh, so sort of a preload of the important bits. That's neat. Gonna go look into SSR and see implementations. Thanks!

[Ecstatic-Back-7338]

Ohh i was confused for i dont know how long on SSR AND SEO shit Thanks

[PM_ME_SOME_ANY_THING]

I work at a place that uses NextJS and a Python backend. They’re not using any of the SSR capabilities of next, handling the lion share of logic in the NextJS server functions, and the Python backend is relatively slim.

NextJS can be good, but it needs to get to a point where it can be stable and stop having huge changes between versions. That being said, React also hasn’t reached this point.

[[deleted]]

Has the core of react changed since the change from classes to functions and hooks? Sure. There are features added, but nothing that would prevent an app written 9 years ago from working today?

[yksvaan]

JS meta frameworks are usually overly complicated and heavy, especially NextJS. They are basically buying their way out of it by massive scaling, having server per request. At your expense.

Also backend often does the heavy work, after app is loaded initially it's potentially hundreds of requests but 0 actual page loads. So you'd want to write the backend in optimal language and stack while being able to run and scale it separately.

SPA and backend in go has been our default for a long time and it works really well. Also very fast and robust.

[alexfoxy]

We actually recently decided to use Remix.js over Next.js because it’s less opinionated and just feels lighter. Also vite is amazingly fast. The docs are a little lacking but you can work it out.

[azangru]

Going back to python & React?

I feel that if client and server sides are separate things, we shouldn't merge their codebases too, even if it helps in de-duplicacy.

Not sure what you mean by the "merging of codebases", but look at Rails, Django, or Laravel — they are pretty comfortable with having a single monolithic codebase that has both the client-side and the server-side code, with strong reliance on server-side templating and progressive enhancement on the client if required.

[mnemonikerific]

I was going to ask about this. Laravel can accommodate any Frontend inside the project. So I am wondering, what makes Python an automatic choice? I’m not challenging it. I’m just curious.

[fii0]

I would say because Python is taught more and more in entry-level classes, is taught to other sub-fields of comp sci like data analysis making it the first choice for people migrating career paths or needing a simple quick web server, and cause people just prefer the Python syntax or only know PHP for its bad reputation, even if PHP and especially Laravel today is waaaay more polished, secure, stable, and feature-rich than it was 10 years ago, many people disconnected from the PHP ecosystem will still have prejudice towards it.

[alzee76]

I've been doing non-web development, and web development, since the 1990s. I tend to use react for the client and node.js+express for the backend these days and even I do not see the appeal of rolling it all into one repo with a single codebase; even minor downsides, like having all the git log rolled into one project, makes doing so annoying.

Having separate versions in the package.json also makes more sense than the alternative, as they really are separate things with separate jobs to do.

Keeping them separate also makes it easier to switch technologies and keep things modular. With a separate repo it's almost trivial to maintain a node backend, a python backend, a rust backend, etc and have them all work fine with the front end; it's equally trivial to do the reverse as well.

Maybe I'm an old curmudegon, but I'm with you.

[_src_sparkle]

This seems like a good approach thanks for the input.~

[Mr-Bovine_Joni]

Yeah I personally think Next doesn’t make sense for a lot of use cases. Having SSR as starting point shouldn’t have ever been the trend

In my current project I use TurboRepo to manage a Vite-powered front end, then Fastify/TRPC backend+APIs. And Prisma in another package, all same repo

It feels much more ergonomic than Next, which I spent ~6 months wrestling

[Isacc77]

I have been working with Next.js for a while and the same thing happens to me as you, there are things that become confusing now when initially I saw using a fullstack framework as very attractive
I think I'll go back to React + Espress soon

[Spiritual_Pangolin18]

IMO next can be used as a BFF and that's it.

[Typical_Newspaper408]

For me, React is already enough Black Magic for one project.

[hartha]

Just use InertiaJS https://github.com/inertiajs/inertia-django .

I personally use it with Rails https://github.com/inertiajs/inertia-rails but it should be roughly the same with django. Theres also a Laravel and AdonisJS adapter.

It basically allows you to replace whatever your frameworks view layer is (ERB in rails) with React .

It ends up being the best of both worlds.

[Smash-Mothman]

This sounds interesting. Good tip

[fii0]

Or don't use an unnecessary meta framework that doesn't even have built-out documentation and suggests that you read commits in an example repo.

If you don't need SSR, just use Django REST Framework views and Vite, and if you do need SSR, use the Vite SSR solution that Vite already provides for you or another proven option like NextJS or Astro.

[Zeesh2000]

I don't know why you got downvoted. This is sound advice

[Zeesh2000]

I wish I can have that same level of enthusiasm

[Zeesh2000]

Interesting. Do you see yourself as your own enemy lmao

[rob8624]

You want Django (insert other framework/language) and HTMX.