3 ms·
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 s
by 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 agoSometimes 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.