Ask HN: What are the common pitfalls/problems of Single Page App's?

I am working on a Single Page Application (SPA) using Angular 1.5 and while I have spent a lot of time building it, I keep reading about various "issues" regarding javascript frameworks in general. To be specific, I am building the server side API as well as the front end, so I have a lot of freedom to adjust both sides as much as needed (which can be good and bad).

I feel like a SPA style app works well with the use case of the site I have been building in that we are making it easier for our customers to find their information in the shortest amount of time possible (think Google for product support).

With that said, I have a bias towards this design choice because I built it. I know that I might be missing something and I want to consider more use cases than what I can come up with.

What I want to know is when does it make sense to use a more traditional server-client architecture? I had read about Twitter reverting back from a SPA to server rendering, but I feel like their use case was specific to their needs or to a specific metric and possibly user experience for their site (lower time to first tweet, smaller page load, and cleaner URL's).

I am aware of SEO drop with Angular, but I feel like problems like clean URL's, back button not working, and UI thrashing are fairly solveable by good planning (in the case of the URL's) and Web Workers (to address UI Thrashing).

I chose Angular because I was already very familiar with it and I found it to be fairly flexible for what I need it to do, it just needs some nudging at times (ng-if vs. ng-show/hide). Also, at the time, I couldn't get the JSX tooling for React to work properly and I think Babel couldn't do transpiling for the latest version of React at that time (I think it was around 1.4). I had used Mithril which was a huge joy and very powerful, but the way my site works (it's an Oracle product using PHP/CodeIgnitor), I couldn't get the client side routing to work properly.

Right now the render speed is good, but could be better.

One strategy that seems to work for this project has been to load in large, JSON objects using web workers while the first page is loading. This will allow the page to load and not disrupt the view rendering.

From there, I can use the large JSON objects to build the nested routes. I will use one view and link to it but add parameters to filter out the data. Ng-if has been making the rendering way way way faster going this route.

On a slow connection, two things that slows down the entire app is AJAX calls and rendering images. That is why I have tried to pull in the large JSON objects upfront so that the initial load might take an extra half second, but the rest of the app navigation is speedy.

SEO is my biggest concern, but for now, I am thinking I can use older links and do a 301 redirect to the needed resource. The only issue that I foresee is that I cannot do a server-side render; I was thinking of just routing bots to a non-ajax site so we can still get good SEO but it's while before I will get to this part.

- Angular doesn't enforce a convention. This gives you flexibility at the cost of zero convention. Developers tend to abuse this flexibility "because they can do it this way instead of that". Choose a convention among all the methods possible, then stick with it.

- Angular can be hard to debug when using some architectures. Two-way binding is pretty hard to track down. Scope inheritance is also a pain, especially with nested controllers, or when devs just stick everything to the root scope and expect it to be there when it doesn't at times. Even tools like Batarang and Inspector can be a pain to use.

- Long-running SPA's tend to accumulate unreleased memory if not managed properly. When stuff like this happens, worst case scenario is to have the user reload the page and lose state. Not taking this seriously, the browser may crash. You don't want this to happen in the middle of an operation, like say, a payment.

- State management is also a pain to work with. I often hear our devs talk about "invalid state". How can it be invalid? That's unless not all changes are accounted for. This is where the Flux architecture shines, as it isolates state in one location, away from the moving parts, and state only mutates via one mechanism - actions.

- It's huge size. One issue with Angular is that it uses too much boilerplate code, most of which is because of the structure and dependency injection mechanisms. Minifiers can only do so much to lessen the size, and not sure if Rollup can do much against these helper structures.

Speaking as a backend dev who generally avoids writing client-side code, the biggest problem that I've had is figuring out the "right" way to build the fucking thing. The JS fatigue is real.