I'm not a front end dev,so some questions might be a bit naive.
1.So for example isn't SSR keeping the state of the page on the server ,that being a disadvantage to scaling?
2.Isn't SSR a way to not use Javascript on the front end but write the client code in your backend language of choice?See Vaadin which you write the client components in Java.
"Vaadin in its beginnings used GWT under the hood to compile the Java code to JavaScript. Not anymore.Since version 10 it compiles to Web Components and through its Client side JavaScript engine communicates the events taking place browser side to the server side which decides how to proceed, in for example modifying the DOM;that is Vaadin renders the application server side and this server side endeavor goes by the name of Vaadin Flow"
Not necessarily. Most SSR in modern frameworks is only an initial state and then browser maintains state after. This article is talking about moving to a more server driven model but it doesn't necessarily means the backend needs to be stateful. I mean obviously it needs to go somewhere, the URL can only hold so much. But what is being looked at now in JS land is the ability to do classic server style navigation/rendering but preserve the state in the browser.
I mean that is one take on SSR. JS frameworks have been doing SSR for the past several years using Node backends to run the same code client and server. The benefit is similar to this promise from Vaadin where you write a single app and it works in both places. The one thing though that I've observed is that many times using Server technology to generate JavaScript doesn't end up with as optimal JS. I've used those solutions in the past. I'm sure a backend dev can point out where node is inefficient, but browser is a much more resource constrained environment.
Hmm.. not sure what the Vaadin pitch is.. Web Components are JavaScript. But following along it sounds like it's doing HTML partials. Which isn't unlike HTML frames I'm talking about above. It's an interesting approach. The challenge with these approaches is while they do allow for less JS and a single app mentality, they rely a lot on the network for things that may not need to go the server. Generally client side updates are faster once you are there. It's a cool model, but ideally I think the direction is more hybrid. Something to get the advantages of both sides. Some work is better done in the browser without server back and forth, but if going to the server anyway better to offload that work, and reduce JS size.
Some comments have been hidden by the post's author - find out more
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'm not a front end dev,so some questions might be a bit naive.
1.So for example isn't SSR keeping the state of the page on the server ,that being a disadvantage to scaling?
2.Isn't SSR a way to not use Javascript on the front end but write the client code in your backend language of choice?See Vaadin which you write the client components in Java.
"Vaadin in its beginnings used GWT under the hood to compile the Java code to JavaScript. Not anymore.Since version 10 it compiles to Web Components and through its Client side JavaScript engine communicates the events taking place browser side to the server side which decides how to proceed, in for example modifying the DOM;that is Vaadin renders the application server side and this server side endeavor goes by the name of Vaadin Flow"
Not necessarily. Most SSR in modern frameworks is only an initial state and then browser maintains state after. This article is talking about moving to a more server driven model but it doesn't necessarily means the backend needs to be stateful. I mean obviously it needs to go somewhere, the URL can only hold so much. But what is being looked at now in JS land is the ability to do classic server style navigation/rendering but preserve the state in the browser.
I mean that is one take on SSR. JS frameworks have been doing SSR for the past several years using Node backends to run the same code client and server. The benefit is similar to this promise from Vaadin where you write a single app and it works in both places. The one thing though that I've observed is that many times using Server technology to generate JavaScript doesn't end up with as optimal JS. I've used those solutions in the past. I'm sure a backend dev can point out where node is inefficient, but browser is a much more resource constrained environment.
Hmm.. not sure what the Vaadin pitch is.. Web Components are JavaScript. But following along it sounds like it's doing HTML partials. Which isn't unlike HTML frames I'm talking about above. It's an interesting approach. The challenge with these approaches is while they do allow for less JS and a single app mentality, they rely a lot on the network for things that may not need to go the server. Generally client side updates are faster once you are there. It's a cool model, but ideally I think the direction is more hybrid. Something to get the advantages of both sides. Some work is better done in the browser without server back and forth, but if going to the server anyway better to offload that work, and reduce JS size.