Graduated in Digital Media M.Sc. now developing the next generation of educational software. Since a while I develop full stack in Javascript using Meteor. Love fitness and Muay Thai after work.
I can understand this trend from a Blog or E-Commerce POV. But for rich web applications this makes things much more complicated imo.
I was so happy when things moved away from the server to the client, where trivial functionality would not have desasterous security implications. However, it seems people definitely want to get back to these days.
Another thing I dislike about this trend is that due to increasing load on the Server it will be harder to entry the market with scalable low-cost solutions.
Why don't the frameworks make more use of dynamic import for load performance?
Dynamic Imports + Components is sort of where this is coming from. Components lead to co-location of fetching and once we started lazy loading the client-side waterfalls started to become a problem. There are other ways to solve this of course. But the naive approach is causing larger performance issues than pretty much any optimization the React team could counter.
React Server Components are basically a different sort of Lazy Loading. They wrapped the parallelizing dynamic import problem and progressive rendering problems together. This can increase performance considerably, and was most likely motivated by usage at Facebook in their new redesign. Marko's progressive rendering and partial hydration grew from eBay's need when moving to Node almost a decade back.
This whole motion is coinciding with the move to serverless which offers relatively inexpensive metered compute. Both Remix Run and SvelteKit highlight serverless deploy as a starting configuration option. I think this is how they aim to handle scalable low-cost solutions.
But for rich web applications this makes things much more complicated imo.
Why? If you render everything on the server, and let the browser do its magic, plus maybe use some HTMX, you end up only having to care about state on the back end, instead of having both frontend and backend state without any benefits whatsoever.
Graduated in Digital Media M.Sc. now developing the next generation of educational software. Since a while I develop full stack in Javascript using Meteor. Love fitness and Muay Thai after work.
Graduated in Digital Media M.Sc. now developing the next generation of educational software. Since a while I develop full stack in Javascript using Meteor. Love fitness and Muay Thai after work.
Precisely, the models here are the opposite way. The desire here stems from the want to manage state on the frontend so using a client model lets us keep the server mostly stateless while having a single developer experience. It's basically the complete opposite approach but has the same benefits in the opposite way. The difference is arguably for many apps, the state is in the right place (closer to the customer).
I won't say this is the right solution for everything, but what is cool about this is if you wanted to scale state to the server it isn't that much of a jump, whereas given the complexity of frontend I'd say the opposite direction is not as true.
This is the fundamental difference about this time around. And why things are not just going back to how they were 10 years ago.
Graduated in Digital Media M.Sc. now developing the next generation of educational software. Since a while I develop full stack in Javascript using Meteor. Love fitness and Muay Thai after work.
For sure, I think there is a lot of noise here. Especially from the primarily server rendered crowd. They've been waiting for like a decade to say I told you so. And the client approach hasn't been giving them that. There have been some missteps and some learnings but no one things things are suddenly going to go back to how things were.
The thing to discern I think revolve around architectural nuances. I always say follow the client state. This has been the bane of web dev. A musical chairs (hot potato) to see who is left holding the bag. Eventually client side was like, it is fine we like state, it is worth the complexity. If where you manage state has change you can't view even similar looking solutions the same.
My hope is with enough perspective of different projects working in this area we can see the emergent trends and better evaluate what is actually going on.
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.
I can understand this trend from a Blog or E-Commerce POV. But for rich web applications this makes things much more complicated imo.
I was so happy when things moved away from the server to the client, where trivial functionality would not have desasterous security implications. However, it seems people definitely want to get back to these days.
Another thing I dislike about this trend is that due to increasing load on the Server it will be harder to entry the market with scalable low-cost solutions.
Why don't the frameworks make more use of dynamic import for load performance?
Dynamic Imports + Components is sort of where this is coming from. Components lead to co-location of fetching and once we started lazy loading the client-side waterfalls started to become a problem. There are other ways to solve this of course. But the naive approach is causing larger performance issues than pretty much any optimization the React team could counter.
React Server Components are basically a different sort of Lazy Loading. They wrapped the parallelizing dynamic import problem and progressive rendering problems together. This can increase performance considerably, and was most likely motivated by usage at Facebook in their new redesign. Marko's progressive rendering and partial hydration grew from eBay's need when moving to Node almost a decade back.
This whole motion is coinciding with the move to serverless which offers relatively inexpensive metered compute. Both Remix Run and SvelteKit highlight serverless deploy as a starting configuration option. I think this is how they aim to handle scalable low-cost solutions.
Why? If you render everything on the server, and let the browser do its magic, plus maybe use some HTMX, you end up only having to care about state on the back end, instead of having both frontend and backend state without any benefits whatsoever.
Why do I want to manage state in the backend? This is something at least I want to avoid at any cost.
You have to manage state in the backend anyway. This way, you simply avoid having to deal with it on the frontend, too.
Can you show me an example of state that I definitely have to manage in the backend? In my current understanding there is none.
Precisely, the models here are the opposite way. The desire here stems from the want to manage state on the frontend so using a client model lets us keep the server mostly stateless while having a single developer experience. It's basically the complete opposite approach but has the same benefits in the opposite way. The difference is arguably for many apps, the state is in the right place (closer to the customer).
I won't say this is the right solution for everything, but what is cool about this is if you wanted to scale state to the server it isn't that much of a jump, whereas given the complexity of frontend I'd say the opposite direction is not as true.
This is the fundamental difference about this time around. And why things are not just going back to how they were 10 years ago.
Thank you for this explanation. I am doing these critical confrontations mainly to find out which trends are hype and which are solid.
For sure, I think there is a lot of noise here. Especially from the primarily server rendered crowd. They've been waiting for like a decade to say I told you so. And the client approach hasn't been giving them that. There have been some missteps and some learnings but no one things things are suddenly going to go back to how things were.
The thing to discern I think revolve around architectural nuances. I always say follow the client state. This has been the bane of web dev. A musical chairs (hot potato) to see who is left holding the bag. Eventually client side was like, it is fine we like state, it is worth the complexity. If where you manage state has change you can't view even similar looking solutions the same.
My hope is with enough perspective of different projects working in this area we can see the emergent trends and better evaluate what is actually going on.
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