DEV Community

Cover image for Quo vadis, web development?
highasthedn
highasthedn

Posted on

Quo vadis, web development?

Hey fellow developers,

I have a question to discuss that has been bothering me for some time now, at the latest since the new official React documentation (which is great by the way). In the official docs they are mentioning that the best way to start a new React project is to use a framework like NextJS, so NextJS seems to be a little bit the state of the art now.
Although I think it's an awesome framework, I think that I observe a trend that feels like going some steps backwards to me.
They seem to take big effort in their server-side stuff, which could be useful for pages with a big spot on SEO. Also Remix seems to get big attention these days, where I also can see similar ways of thinking.

But for me it feels like going back to those Symfony days, where I have a monolithic app structure. The decoupling between backend and frontend felt like a game changer to me. I can deploy my frontend to static site hosting for example and can concentrate to have a robust backend which is scaling. After some time I need an app? No problem! More resources for the backend and a separate app, no monolithic structure. Or I want to provide my backend api for partner apps? No problem, just a little more scaling or a microservice.

Do you get my point? It feels great to have a fast and clean React frontend with Vite and a backend with NestJS which is scaling as a combination. But is it still up to date? Are we really going back to more monolithic patterns, or are they monolithic at all? Is it really going back or even going forward?

What do you guys think? I don't want to become that old man who is telling everyone that SPAs are the hottest stuff while everybody is doing modern stuff.

Latest comments (6)

Collapse
 
kristiyan_velkov profile image
Kristiyan Velkov

Thank you for great opinion ☺️🙏

What I think is the same like each year something tried to kill JS like pyjs, blazor and etc.

Front end and back end will be separated and no have reason to go to different direction, simply because for now server side rendering is not so popular. Ofc who knows will be the trend next years, but I will stick to what is working good, not to what is new.

Collapse
 
highasthedn profile image
highasthedn

Yes, exactly. The "stick to what is working good" in combination with looking what's going on left and right of you is a solid approach. And yeah, hard to say where the trends are going

Collapse
 
giovannimazzuoccolo profile image
Giovanni Mazzuoccolo

Do you get my point? It feels great to have a fast and clean React frontend with Vite and a backend with NestJS which is scaling as a combination. But is it still up to date? Are we really going back to more monolithic patterns, or are they monolithic at all? Is it really going back or even going forward?

Yes, it is still up to date, depending on the scope of the project. For example, if your app is a time tracker and requires a highly interactive UI, data display after authentication, offline support, and notifications, a Single Page Application (SPA) remains a valid solution, and React provides the necessary libraries to achieve those functionalities from the beginning.

What the early versions lacked was a focus on server-side rendering, which has now become a prominent trend. Consider a flight tracker app as an example. Such an app doesn't require extensive user interaction, but it needs to be SEO-friendly and quick with live updates. This kind of app can greatly benefit from being built with Server-Side Rendering (SSR).

Collapse
 
highasthedn profile image
highasthedn

Yes, you are right. When I saw that correctly, with NextJS you are able to decide which stuff you want to have client-side and which you want to happen at the server. Maybe for the next bigger project I will give NextJS a try. In a former project I already could have a look at it, it definitely looks powerful

Collapse
 
darkmavis1980 profile image
Alessio Michelini

I agree, I've seen paradigm constanting switching over the years, like:

  • Constant back and forth from functional programming to OOP
  • SSR to SPA and back
  • CSS is bad, use pre/post-processors like SASS, and now CSS is cool again

I guess the years of experience makes you understand that they are all different tools/languages, that solves some problems betters than others, and it's up to you to decide which one is the best for the issue you need to solve.

Personally I prefer the separation between BE and FE, and I tend to keep doing that, especially if you want your API to be more useful and reusable, but in some other cases you don't need that and it's equally good to go back to a more monolitich approach, if it serves the right purpose.

Collapse
 
highasthedn profile image
highasthedn

Yes that's a good point. I had a project with NextJS where we had a big focus on SEO, so all these server-side stuff came in right handy. I also tend to keep doing mostly SPA - Backend separation. Although I am excited what will be in about five to ten years