4 ms·

Somewhat off-topic, though it may be relevant. Is it that much more difficult/complicated to have a server side rendered app with pure JavaScript sprinkled in

by tabeth 10y ago

Somewhat off-topic, though it may be relevant. Is it that much more difficult/complicated to have a server side rendered app with pure JavaScript sprinkled in versus SPA vs. no JavaScript? The situation I'm thinking about is the following: firstApp.domain.com secondApp.domain.com If you have an SPA then you literally can just have separate SPAs for each sub domain served statically. You could also have everything rendered server side using whatever back-end you're using. Finally, you can have server-side rendering and add JavaScript when necessary, but this seems to add complexity as your team would now need to know whatever templating language your server-side framework uses plus the front-end framework. Am I missing anything?

pyrophane 10y ago
> but this seems to add complexity as your team would now need to know whatever templating language your server-side framework uses plus the front-end framework. If you use server-rendered templates, the people responsible for your front-end will have to know a few things about the backend and vice-versa, because everything is a bit more integrated. Using an SPA allows your front-end guys to just say "we need an API that delivers this" and your backend guys can just publish a doc on that API. Neither team really has to know that much about how the other makes their part work, and both teams can create their own ideal environment without having it dirtied by the other team's needs or constraints. That being said, I wouldn't advocate for building an SPA purely for developer convenience.
- tabeth 10y ago
  Do you have any war stories to share? Given that ultimately producing value to the business is the only thing that matters, wouldn't doing it, if it conveniences them be the right thing to do? I'm not super knowledgeable about this (<2 years experience), but I see little downside. Of course, I don't know what I don't know.
  - pyrophane 10y ago
    I think the choice to adopt an SPA or not should be driven primarily by the project requirements. Are you mostly going to be serving up long-form documents or presenting users with tradition forms, or are you building something that needs to feel more like an "app" that is highly responsive to user interaction. I would choose an SPA only if the latter were true. You essentially have two problems: 1) how to make common code available for reuse across what is essentially two separate websites/apps and 2) how to make it so that front-end focused developers and backend focused developers can work effectively together. I don't think that either problem is best solved by adopting an SPA if you would not otherwise be driven to do so. Problem 1 can be solved in a lot of ways. You can build a set of common services into a library used by both apps, for example. This allows you to isolate and reuse common functionality without the overhead of an HTTP service layer if you don't really need it. Problem 2 I would say winds up being more about both teams getting things "the way they want to do it" rather than strictly about difficulty learning. I've yet to see a server template system that would present much of a problem to a front-end focused person. The real problem is how can their toolchain, which may include things like transpilation, sass compilation, and a separate test runner, be integrated into the backend build process and framework. A lot of backend frameworks are somewhat opinionated about how these things happen, but there are ways to integrate just about anything with anything else. Anyway, it really just boils down to understanding how your app would be best served based on how it needs to work, and doing it that way. There is a good bit on the trade-offs between the two linked below [1], although its author is biased towards "shared" front-end/back-end frameworks like meteor, and I don't agree with some of the conclusions. [1] https://www.quora.com/What-are-the-tradeoffs-of-client-side-rendering-vs-server-side-rendering https://www.quora.com/What-are-the-tradeoffs-of-client-side-...
simplify 10y ago
It sounds like you're describing Marko.js. Once v4 is released, I predict server-side rendering will become popular again. It's like a vue.js + server-side rendering + client-side rendering + a built-in automatic webpack, yet everything is easy to learn and use. Too good to pass up.

by tabeth 10y ago

pyrophane 10y ago

> but this seems to add complexity as your team would now need to know whatever templating language your server-side framework uses plus the front-end framework. If you use server-rendered templates, the people responsible for your front-end will have to know a few things about the backend and vice-versa, because everything is a bit more integrated. Using an SPA allows your front-end guys to just say "we need an API that delivers this" and your backend guys can just publish a doc on that API. Neither team really has to know that much about how the other makes their part work, and both teams can create their own ideal environment without having it dirtied by the other team's needs or constraints. That being said, I wouldn't advocate for building an SPA purely for developer convenience.

tabeth 10y ago
Do you have any war stories to share? Given that ultimately producing value to the business is the only thing that matters, wouldn't doing it, if it conveniences them be the right thing to do? I'm not super knowledgeable about this (<2 years experience), but I see little downside. Of course, I don't know what I don't know.
- pyrophane 10y ago
  I think the choice to adopt an SPA or not should be driven primarily by the project requirements. Are you mostly going to be serving up long-form documents or presenting users with tradition forms, or are you building something that needs to feel more like an "app" that is highly responsive to user interaction. I would choose an SPA only if the latter were true. You essentially have two problems: 1) how to make common code available for reuse across what is essentially two separate websites/apps and 2) how to make it so that front-end focused developers and backend focused developers can work effectively together. I don't think that either problem is best solved by adopting an SPA if you would not otherwise be driven to do so. Problem 1 can be solved in a lot of ways. You can build a set of common services into a library used by both apps, for example. This allows you to isolate and reuse common functionality without the overhead of an HTTP service layer if you don't really need it. Problem 2 I would say winds up being more about both teams getting things "the way they want to do it" rather than strictly about difficulty learning. I've yet to see a server template system that would present much of a problem to a front-end focused person. The real problem is how can their toolchain, which may include things like transpilation, sass compilation, and a separate test runner, be integrated into the backend build process and framework. A lot of backend frameworks are somewhat opinionated about how these things happen, but there are ways to integrate just about anything with anything else. Anyway, it really just boils down to understanding how your app would be best served based on how it needs to work, and doing it that way. There is a good bit on the trade-offs between the two linked below [1], although its author is biased towards "shared" front-end/back-end frameworks like meteor, and I don't agree with some of the conclusions. [1] https://www.quora.com/What-are-the-tradeoffs-of-client-side-rendering-vs-server-side-rendering https://www.quora.com/What-are-the-tradeoffs-of-client-side-...

simplify 10y ago

It sounds like you're describing Marko.js. Once v4 is released, I predict server-side rendering will become popular again. It's like a vue.js + server-side rendering + client-side rendering + a built-in automatic webpack, yet everything is easy to learn and use. Too good to pass up.