3 ms·

With all the buzz around SPA frameworks like Angular or Ember it's a worthwhile reminder that there's a still a lot of room in the world for more conventional s

With all the buzz around SPA frameworks like Angular or Ember it's a worthwhile reminder that there's a still a lot of room in the world for more conventional server-side rendering approaches. Not every web app needs to be an SPA and old-fashioned Rails apps can be a lot simpler to implement.

colin_jack 12y ago
Yup, also a good reminder that you need to constantly question the design decisions as you go (on an almost daily basis).
jbergens 12y ago
On the other hand I had to develop a small admin framework and decided to do it with server rendering since I thought it would be easier. I soon found all the small details I needed to think about and that there were a number of server side components/files that I had to create to do what I wanted to do. It would probably have been easier to just do it in the SPA framework I am used to (Angular).
- bigpeopleareold 12y ago
  Sometimes I wish I can do more server-side rendering etc. I have been working on single page applications for awhile now; I miss the ease that is afforded by just capturing state through server-side page transitions. Specifically, with SPAs (existing codebases now mostly), I run in bugs a lot that involve Backbone events: when are they firing, what part of the codebase is firing them, who is ignoring the global state and firing anyway. Sometimes, looking through a call stack is not even helpful. Every project that I worked on had these problems. The last big bug I dealt with involved, for me, an unfamiliar codebase and about a week-and-a-half of sitting with the debugger tracing every line. While for new projects, you can work very hard to ensure that firing events is hygienic, existing projects might not be so hygienic. With a server-centric approach, each page load limits the mental load with state. On page-transition, the page state is clean. While I think frameworks like Angular is very interesting, I tend to question my own ambition personally. Something like the approach that Turbolinks takes might actually be more appealing.

colin_jack 12y ago

Yup, also a good reminder that you need to constantly question the design decisions as you go (on an almost daily basis).

jbergens 12y ago

On the other hand I had to develop a small admin framework and decided to do it with server rendering since I thought it would be easier. I soon found all the small details I needed to think about and that there were a number of server side components/files that I had to create to do what I wanted to do. It would probably have been easier to just do it in the SPA framework I am used to (Angular).

bigpeopleareold 12y ago
Sometimes I wish I can do more server-side rendering etc. I have been working on single page applications for awhile now; I miss the ease that is afforded by just capturing state through server-side page transitions. Specifically, with SPAs (existing codebases now mostly), I run in bugs a lot that involve Backbone events: when are they firing, what part of the codebase is firing them, who is ignoring the global state and firing anyway. Sometimes, looking through a call stack is not even helpful. Every project that I worked on had these problems. The last big bug I dealt with involved, for me, an unfamiliar codebase and about a week-and-a-half of sitting with the debugger tracing every line. While for new projects, you can work very hard to ensure that firing events is hygienic, existing projects might not be so hygienic. With a server-centric approach, each page load limits the mental load with state. On page-transition, the page state is clean. While I think frameworks like Angular is very interesting, I tend to question my own ambition personally. Something like the approach that Turbolinks takes might actually be more appealing.