In general, the thing that draws people to building a JS-driven site is because it allows faster responsiveness for users, and a more versatile interface that behaves more like a application and less like a document. I think by now this much should be obvious. If the standard HTTP request/response approach resulted in the responsiveness in feedback we see with AJAX, then we wouldn't have been having this discussion for the last 10 years.

So in short, if a JS-oriented banking website results in a user being able to do their banking more quickly, this is a real benefit and is "the point." You can argue it is not worth the tradeoff, but it's a bit odd to first admit you don't see the point and then go on to say it's not worth it. If you don't see the point, how can you make claims about if it's a valuable thing to be doing? If a bank has 50k daily active users and it shaves 1-2 minutes off of their individual session times, you're looking at saving approximately 50 days of time for people every day. And most banks probably have way more than 50k daily actives. Combine this with other potential benefits like users being able to get enough done in a single banking session to avoid a second visit later, or the user interface being less confusing since users can fall back on desktop metaphors, the amount of saved effort could become truly staggering, worth the additional risk and engineering time of developing a SPA-based solution.

>In general, the thing that draws people to building a JS-driven site is because it allows faster responsiveness for users

The reality, however, when you create sites like banking websites is that it is more often slower.

Google maps is the exception, not the norm.

>a more versatile interface that behaves more like a application and less like a document. I think by now this much should be obvious. If the standard HTTP request/response approach resulted in the responsiveness in feedback we see with AJAX, then we wouldn't have been having this discussion for the last 10 years.

We've had the NoSQL discussion for an equivalent duration. Ironically, the source of this discussion was the same in both cases - that because it worked well for Google's specific requirements, it should be used everywhere. That proved to be an unfounded assumption.

>So in short, if a JS-oriented banking website results in a user being able to do their banking more quickly, this is a real benefit

Unfortunately, it doesn't usually result in a faster website. The banking website I use that makes heavy use of javascript is actually slower than those that do not.

>You can argue it is not worth the tradeoff, but it's a bit odd to first admit you don't see the point and then go on to say it's not worth it.

The point was fairly clear: unless you can make a significant speed gain (and more than you think can not), then there is no trade off. It is universally a bad idea.

>If a bank has 50k daily active users and it shaves 1-2 minutes off of their individual session times, you're looking at saving approximately 50 days of time for people every day.

That's the second time on this thread that you've pulled a number right out of your ass.

>Combine this with other potential benefits like users being able to get enough done in a single banking session to avoid a second visit later, or the user interface being less confusing since users can fall back on desktop metaphors

Then there are those AJAX websites that break the back button. Users LOVE that.

Why do you keep focusing on the numbers in my hypothetical examples? If you've run a large enough website, with enough users small optimizations end up being magnified into real effects. That's the point, and you're missing it again by being pedantic.

Beyond that, specific claims like "when you create sites like banking websites is that it is more often slower" are things that require evidence, and are much more in the category of 'pulling something out of your ass' than me very clearly constructing reasonable hypotheticals, not making claims about what would happen on a specific site or situation.

fwiw: I have run lots of A/B tests and in many cases converting things to AJAX-y, less HTTP-y solutions increases metrics meaningfully (like being able to add things to a list in a single click, instead of a full HTTP POST), and in many cases it does not (like in cases of infinite-scrolling through results.) Go figure, context matters and making flat-out claims is dumb. It's perfectly reasonable to believe there is some significant chance that a highly interactive site like a bank could see real meaningful changes in user behavior if it avoided doing full HTTP postback for all its pages.

So if my bank didn't use JS, the already drawn out processes would take even longer. Transfers would require more clicks, more full page reloads. No benefit to the user. In fact, the opposite. The user just feels their banking system is even older and more outdated. So your use of "not necessary" is rather debatable and probably not the same as the PM's.

As far as security on the API, I'm not convinced. Don't use cookies for authentication -- is that a big problem?