3 ms·

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 convenience

by 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-...

by tabeth 10y ago

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-...