Actually, both approach are needed, its what you are building that will dictate how much state you should retain on the client-side.
Wanting to avoid server-side state at all costs is just being lazy and not wanting to be an actual developer who creates solutions to your customers problems.
You want to make everything just with front-end tech, come on, that isn't happening, there's always a service layer and a database, always.
There will always be the client/server model as long as we still use the HTTP protocol.
This split is never going away, just deal with it and become a full-stack developer.
"They've been waiting for like a decade to say I told you so"
This goes even back, I'm doing software development for 14 years, it used be called 3-tier architecture, there's always was a frontend layer, the service layer and the database layer, since the well before the first web bubble.
The client/server division is as old as the TCP/IP itself.
Front-end developers not wanting to have the server side is a funny proposition.
Let me propose not having front-end at all by allocating all the code of the server-side and creating a splitting mechanism to replace the HTML so the applications can actually run really distributed, by automatically moving running binary code between CPUs (of even different architectures), and we can end this insanity once and for all.
It's a matter of moving the boundaries. No one wants to write the interopt part. The API when there is no additional need for it.
The thinking of frontend on the backend is that you write a single app that communicates directly with your service/database layers. It isn't unlike how things were like before when we were mostly server rendering stuff. The difference is the front of backend looks more like the frontend than the backend. It's a bit like mobile development.
This is all abstraction/framework level consideration. It doesn't change or oust core backend technologies. It's more suggesting that viewing an application as only a bunch of rendered HTML pages is an antiquated model and we want a unified one. Now traditional backend technologies could(and have) take this approach too, it is just that JavaScript frameworks have been working in this ultra lean zone for years and still have advantage running in the browser. So the question is if they can bridge the gap in a way that hasn't been really successfully realized thus far.
"So the question is if they can bridge the gap in a way that hasn't been really successfully realized thus far."
That's my point, there's lot of space for engineering better things.
The irony is that using remote access gets a seamless "cloud" experience of a native application.
JS started lean, but now are so bloated that native applications outperform it. And ironically, they are smaller in size. I see that big electron 90MB blob there, its like a white gorilla in the middle of the class
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Actually, both approach are needed, its what you are building that will dictate how much state you should retain on the client-side.
Wanting to avoid server-side state at all costs is just being lazy and not wanting to be an actual developer who creates solutions to your customers problems.
You want to make everything just with front-end tech, come on, that isn't happening, there's always a service layer and a database, always.
There will always be the client/server model as long as we still use the HTTP protocol.
This split is never going away, just deal with it and become a full-stack developer.
"They've been waiting for like a decade to say I told you so"
This goes even back, I'm doing software development for 14 years, it used be called 3-tier architecture, there's always was a frontend layer, the service layer and the database layer, since the well before the first web bubble.
The client/server division is as old as the TCP/IP itself.
Front-end developers not wanting to have the server side is a funny proposition.
Let me propose not having front-end at all by allocating all the code of the server-side and creating a splitting mechanism to replace the HTML so the applications can actually run really distributed, by automatically moving running binary code between CPUs (of even different architectures), and we can end this insanity once and for all.
It's a matter of moving the boundaries. No one wants to write the interopt part. The API when there is no additional need for it.
The thinking of frontend on the backend is that you write a single app that communicates directly with your service/database layers. It isn't unlike how things were like before when we were mostly server rendering stuff. The difference is the front of backend looks more like the frontend than the backend. It's a bit like mobile development.
This is all abstraction/framework level consideration. It doesn't change or oust core backend technologies. It's more suggesting that viewing an application as only a bunch of rendered HTML pages is an antiquated model and we want a unified one. Now traditional backend technologies could(and have) take this approach too, it is just that JavaScript frameworks have been working in this ultra lean zone for years and still have advantage running in the browser. So the question is if they can bridge the gap in a way that hasn't been really successfully realized thus far.
"So the question is if they can bridge the gap in a way that hasn't been really successfully realized thus far."
That's my point, there's lot of space for engineering better things.
The irony is that using remote access gets a seamless "cloud" experience of a native application.
JS started lean, but now are so bloated that native applications outperform it. And ironically, they are smaller in size. I see that big electron 90MB blob there, its like a white gorilla in the middle of the class