When to use SSR with JavaScript Frameworks?
I've been working on a multi-platform application. I plan to use Electron for OSX, Windows and Linux, Cordova for iOS and Android, and SSR for Web, but I have problems with SSR. I would have to change a lot of things to run it on a NodeJS server.
I use Firebase Firestore to persist and sync data on the client side, but on the server side it would need another version of Firestore to use with Node, and using Firestore on the server side would mean I'd lose the sync feature (with offline support).
Offline synchronization is essential to this application, so SSR wouldn't work for me, that's my conclusion.
I would like to know if this is a "default" in architecture of JS projects: need to offline data is used client side, if it need SEO you should use SSR.
javascript node.js reactjs express ssr
edited Nov 26 '18 at 0:56
Mihai Chelaru
2,367101323
asked Nov 26 '18 at 0:09
Rodrigo MelloRodrigo Mello
1303
add a comment |
I've been working on a multi-platform application. I plan to use Electron for OSX, Windows and Linux, Cordova for iOS and Android, and SSR for Web, but I have problems with SSR. I would have to change a lot of things to run it on a NodeJS server.
I use Firebase Firestore to persist and sync data on the client side, but on the server side it would need another version of Firestore to use with Node, and using Firestore on the server side would mean I'd lose the sync feature (with offline support).
Offline synchronization is essential to this application, so SSR wouldn't work for me, that's my conclusion.
I would like to know if this is a "default" in architecture of JS projects: need to offline data is used client side, if it need SEO you should use SSR.
javascript node.js reactjs express ssr
edited Nov 26 '18 at 0:56
Mihai Chelaru
2,367101323
asked Nov 26 '18 at 0:09
Rodrigo MelloRodrigo Mello
1303
1
Then don't use SSR. Good engineering is all about choosing the right tool for the job. Naive engineering is using a tool/technology because it's "edgy", for lack of better word. For SEO you might be able to get away with pre-rendering.
– Nik Kyriakides
Nov 26 '18 at 0:14
SSR is always faster than entirely client page SPAs, and always results in a better user experience. Check out developers.google.com/web/progressive-web-apps . With SSR, you define the same data fetching API that works on client and server, so you only have to write component data fetching once.
– Andy Ray
Nov 26 '18 at 0:17
@AndyRay "faster" has diminishing returns and speed is never the primary/sole requirement of a system. The OP has other considerations in mind. I'm not arguing against SSR. I'm just saying that if one of the main requirements excludes it from use (either because it can't work or requires significant work), then taking it out of consideration can be a wise choice.
– Nik Kyriakides
Nov 26 '18 at 0:19
add a comment |
I've been working on a multi-platform application. I plan to use Electron for OSX, Windows and Linux, Cordova for iOS and Android, and SSR for Web, but I have problems with SSR. I would have to change a lot of things to run it on a NodeJS server.
I use Firebase Firestore to persist and sync data on the client side, but on the server side it would need another version of Firestore to use with Node, and using Firestore on the server side would mean I'd lose the sync feature (with offline support).
Offline synchronization is essential to this application, so SSR wouldn't work for me, that's my conclusion.
I would like to know if this is a "default" in architecture of JS projects: need to offline data is used client side, if it need SEO you should use SSR.
javascript node.js reactjs express ssr
edited Nov 26 '18 at 0:56
Mihai Chelaru
2,367101323
asked Nov 26 '18 at 0:09
Rodrigo MelloRodrigo Mello
1303
I've been working on a multi-platform application. I plan to use Electron for OSX, Windows and Linux, Cordova for iOS and Android, and SSR for Web, but I have problems with SSR. I would have to change a lot of things to run it on a NodeJS server.
I use Firebase Firestore to persist and sync data on the client side, but on the server side it would need another version of Firestore to use with Node, and using Firestore on the server side would mean I'd lose the sync feature (with offline support).
Offline synchronization is essential to this application, so SSR wouldn't work for me, that's my conclusion.
I would like to know if this is a "default" in architecture of JS projects: need to offline data is used client side, if it need SEO you should use SSR.
javascript node.js reactjs express ssr
javascript node.js reactjs express ssr
edited Nov 26 '18 at 0:56
Mihai Chelaru
2,367101323
asked Nov 26 '18 at 0:09
Rodrigo MelloRodrigo Mello
1303
edited Nov 26 '18 at 0:56
Mihai Chelaru
2,367101323
asked Nov 26 '18 at 0:09
Rodrigo MelloRodrigo Mello
1303
edited Nov 26 '18 at 0:56
Mihai Chelaru
2,367101323
edited Nov 26 '18 at 0:56
Mihai Chelaru
2,367101323
edited Nov 26 '18 at 0:56
Mihai Chelaru
2,367101323
2,367101323
asked Nov 26 '18 at 0:09
Rodrigo MelloRodrigo Mello
1303
asked Nov 26 '18 at 0:09
Rodrigo MelloRodrigo Mello
1303
asked Nov 26 '18 at 0:09
Rodrigo MelloRodrigo Mello
1303
1303
1
Then don't use SSR. Good engineering is all about choosing the right tool for the job. Naive engineering is using a tool/technology because it's "edgy", for lack of better word. For SEO you might be able to get away with pre-rendering.
– Nik Kyriakides
Nov 26 '18 at 0:14
SSR is always faster than entirely client page SPAs, and always results in a better user experience. Check out developers.google.com/web/progressive-web-apps . With SSR, you define the same data fetching API that works on client and server, so you only have to write component data fetching once.
– Andy Ray
Nov 26 '18 at 0:17
@AndyRay "faster" has diminishing returns and speed is never the primary/sole requirement of a system. The OP has other considerations in mind. I'm not arguing against SSR. I'm just saying that if one of the main requirements excludes it from use (either because it can't work or requires significant work), then taking it out of consideration can be a wise choice.
– Nik Kyriakides
Nov 26 '18 at 0:19
add a comment |
1
Then don't use SSR. Good engineering is all about choosing the right tool for the job. Naive engineering is using a tool/technology because it's "edgy", for lack of better word. For SEO you might be able to get away with pre-rendering.
– Nik Kyriakides
Nov 26 '18 at 0:14
SSR is always faster than entirely client page SPAs, and always results in a better user experience. Check out developers.google.com/web/progressive-web-apps . With SSR, you define the same data fetching API that works on client and server, so you only have to write component data fetching once.
– Andy Ray
Nov 26 '18 at 0:17
@AndyRay "faster" has diminishing returns and speed is never the primary/sole requirement of a system. The OP has other considerations in mind. I'm not arguing against SSR. I'm just saying that if one of the main requirements excludes it from use (either because it can't work or requires significant work), then taking it out of consideration can be a wise choice.
– Nik Kyriakides
Nov 26 '18 at 0:19
1
1
Then don't use SSR. Good engineering is all about choosing the right tool for the job. Naive engineering is using a tool/technology because it's "edgy", for lack of better word. For SEO you might be able to get away with pre-rendering.
– Nik Kyriakides
Nov 26 '18 at 0:14
Then don't use SSR. Good engineering is all about choosing the right tool for the job. Naive engineering is using a tool/technology because it's "edgy", for lack of better word. For SEO you might be able to get away with pre-rendering.
– Nik Kyriakides
Nov 26 '18 at 0:14
SSR is always faster than entirely client page SPAs, and always results in a better user experience. Check out developers.google.com/web/progressive-web-apps . With SSR, you define the same data fetching API that works on client and server, so you only have to write component data fetching once.
– Andy Ray
Nov 26 '18 at 0:17
SSR is always faster than entirely client page SPAs, and always results in a better user experience. Check out developers.google.com/web/progressive-web-apps . With SSR, you define the same data fetching API that works on client and server, so you only have to write component data fetching once.
– Andy Ray
Nov 26 '18 at 0:17
@AndyRay "faster" has diminishing returns and speed is never the primary/sole requirement of a system. The OP has other considerations in mind. I'm not arguing against SSR. I'm just saying that if one of the main requirements excludes it from use (either because it can't work or requires significant work), then taking it out of consideration can be a wise choice.
– Nik Kyriakides
Nov 26 '18 at 0:19
@AndyRay "faster" has diminishing returns and speed is never the primary/sole requirement of a system. The OP has other considerations in mind. I'm not arguing against SSR. I'm just saying that if one of the main requirements excludes it from use (either because it can't work or requires significant work), then taking it out of consideration can be a wise choice.
– Nik Kyriakides
Nov 26 '18 at 0:19
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53473283%2fwhen-to-use-ssr-with-javascript-frameworks%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53473283%2fwhen-to-use-ssr-with-javascript-frameworks%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Then don't use SSR. Good engineering is all about choosing the right tool for the job. Naive engineering is using a tool/technology because it's "edgy", for lack of better word. For SEO you might be able to get away with pre-rendering.
– Nik Kyriakides
Nov 26 '18 at 0:14
SSR is always faster than entirely client page SPAs, and always results in a better user experience. Check out developers.google.com/web/progressive-web-apps . With SSR, you define the same data fetching API that works on client and server, so you only have to write component data fetching once.
– Andy Ray
Nov 26 '18 at 0:17
@AndyRay "faster" has diminishing returns and speed is never the primary/sole requirement of a system. The OP has other considerations in mind. I'm not arguing against SSR. I'm just saying that if one of the main requirements excludes it from use (either because it can't work or requires significant work), then taking it out of consideration can be a wise choice.
– Nik Kyriakides
Nov 26 '18 at 0:19