[Uehreka]

Single Page Applications can enhance the user experience in many ways, even with more "boring" apps:

* Forums/Comment Threads - If I want to reply to a comment in a thread (like I'm doing right now) I don't want the page to refresh after I submit, causing me to lose my scroll position. Even worse is when discussion sites (cough HN) whisk you away to a whole 'nother page to submit your comment, then dump you back to the thread afterward.

* Documentation - Let's say you have a long list of topics in a sidebar on the left. If I find a bunch of topics that I want to read and they're in the middle of the scroll, I'll be annoyed if the whole page refreshes when I click on one.

* Forms - If I'm filling out a long form (like enrolling in school or applying for a job) and I enter something wrong, I want to know immediately. I don't want to hit submit, land back on the same page, then find where the error is. Even when sites do this well (by saving the whole state of the form and clearly indicating where the bad field is) it's still annoying. Client-side validation also saves server resources (even though you need to do server-side validation too): every time the client catches a validation error, that's one less postback the server needs to process.

Following the emerging set of best practices (use a CDN, bundle/minify your code with a tool like browserify/webpack, don't block the critical render path) is enough to get your code to a point where it should run totally fine on mobile. The horrible state of mobile web performance more often results from:

* Fonts - for some reason these seem to take a longer time to load than other assets (or maybe their absence is just more noticable). Using a tool like TypeKit can help to get around issues like "Flash Of Invisible Text".

* Images - People not properly compressing images, using too many images, using PNG where SVG could possibly work are all contributing to slow page loads. Images are usually the largest things on the page (sometimes by an order of magnitude). They are also often demanded by "the business" in the same way that carousels are usually a result of a business compromise and not a deliberate design decision. Tools like grunticon and other gulp/grunt tasks can help mitigate these issues by ensuring that huge hi-res images have a compressed version and don't get sent to phones with tiny screens.

* Ads - Many ad networks either don't run a tight ship or don't police the companies who they allow to run code on their client's sites. The further someone is from actually owning the page where the code runs, the less they often feel compelled to make good optimization decisions.

My point is that a lot of this new-fangled front-end tooling (browserify/webpack, TypeKit, SVG, grunt/gulp, the <picture> element, etc.) are geared towards producing a better experience for the user. Many of them either emerged to deal with mobile web issues or found new importance in light of the problems developers (and businesses) face on the mobile web.

[yuvipanda]

Can't all those three things be done with simple AJAX too, instead of having to make your entire application Javascript based?

[Uehreka]

Yes, but you often end up with half an angular app: a bit of templating, a bit of boilerplate around your AJAX calls, some AJAX here and there. But you quickly run into problems:

- Your designers need to change the markup of the invalid form alerts, and you have to point them to a string building function in your JS rather than an HTML template.

- Once they change the string builder, you need to run your unit tests to make sure it still works. If you don't have any way to do dependency injection, writing unit tests of client side code will be difficult.

- Now your presentation logic is split between front and back end. This makes engineering tasks like assessing test coverage and refactoring more difficult.

For some use cases AJAX only may work. When I'm doing a side project that involves a lot of visual stuff and little state management, I'll ditch the MVC framework and task runner and work with just jQuery or D3. But if I'm working on a large project where many other people are contributing, I want a framework that helps me write testable code and provides structure to help keep my concerns separated.

[carsongross]

Every one of these features is doable in a more traditional web application with something like intercooler.js (which I created). Good UX does not require a SPA and it certainly does not require massive amounts of client-side code.

[arohner]

> Following the emerging set of best practices (use a CDN, bundle/minify your code with a tool like browserify/webpack, don't block the critical render path) is enough to get your code to a point where it should run totally fine on mobile. The horrible state of mobile web performance more often results from:

Not really. While your points are all true, the two biggest factors that you can't really escape are 1) your SPA is still a 1 MB download 2) eval'ing 1 MB of JS before rendering is still slower than serving HTML.

SPAs are a better experience, but they're still slower than conventional pages, and I wouldn't recommend their use on high traffic areas of your site, like the landing page.

[Uehreka]

Sure, and to be fair there are people who needlessly use angular, scrolljacking, and other horrible magicks when building something that doesn't need it. But my experience of the debate has been that there are many many people who think that MVC frameworks are only suitable for "cool" projects like soundcloud, and that the other 90% of front-end developers don't have legitimate use cases for them. I don't think this is a fair or informed assessment of the field, but it can sound like one because it appears to offer a "simple" solution.

As for the 1MB download, angular is about 100KB minified (most of the space in angular is comments, which contain ALL of its documentation). Angular is also used in so many places that if you pull it from a CDN your users should never have to download it. In my experience, my SPAs themselves rarely outweigh 10-20KB. Worst case: I have to download 120KB of JavaScript and parse it. Still though, I find that AJAX requests to slow backends still take up most of the load time -- meaning that if my app was a conventional one, the page would take a while to appear at all, then load instantly. Of course, with Angular 2, I've heard server-side rendering comes into the picture, making the whole "where should I render my templates" discussion moot.

Sure there's a lot of back and forth and a lot of complexity. But in my experience, many clients and businesses want the kinds of modern touches that only a SPA can give them, and the tooling we have around our code exists to make the task easier, even if it may seem complex at first.

[hit8run]

The scenarios you describe can be done with JS enhanced HTML pages. No need to do this as a complete single page application requiring tons of boilerplate framework code.

[wtbob]

> If I want to reply to a comment in a thread (like I'm doing right now) I don't want the page to refresh after I submit, causing me to lose my scroll position.

That's what middle-click to create a new tab is for.

> Even worse is when discussion sites (cough HN) whisk you away to a whole 'nother page to submit your comment, then dump you back to the thread afterward.

If HN were a single-page app, I wouldn't use HN. Period.

> Let's say you have a long list of topics in a sidebar on the left. If I find a bunch of topics that I want to read and they're in the middle of the scroll, I'll be annoyed if the whole page refreshes when I click on one.

Again, that's what middle-click is for.

> If I'm filling out a long form (like enrolling in school or applying for a job) and I enter something wrong, I want to know immediately.

Sure, that's a nice use for JavaScript. I just don't want to have to expose my entire system, and all my data, and every system I can connect to, to malware in return.

[oldmanjay]

I have to admit, I'm not really interested in your restrictions on what people are allowed to use in browsers. You are definitely not the arbiter of the one true way, no matter how right you feel about your opinions.

[wtbob]

Are you interested in security and privacy? Are you interested in functionality?

I am, of course, the arbiter of what I permit my browser, running on my computer and accessing my data, to do.

[dalore]

Ok how to middle click on a tablet? Press and hold, but that sucks.

How to middle click with an apple mighty mouse with no middle click? Press and hold cmd whilst clicking left click.

Middle click doesn't work and it if you are about to submit a comment on a thread how do you middle click to load the same page at the same scroll position?

[zbyte64]

What percentage of internet users either have a middle-click or know how?

[rubicon33]

Opening a new tab works, but come on... It's a crude tool!

[simula67]

One very important point against SPAs is URLs. URLs are central to the design of the web. Lets say I want to talk about a particular commit on github. I can just pick the URL for that commit and email it to someone else. They can click on the link and land directly on the commit page. If it is a single page app, I will have to tell them 'Go to this URL, click here, and then click there' etc.

Same case with blog posts. Sites like HN would not even exist if everyone published all their posts in SPAs.

[yoonay]

Most SPAs I've used handle the routing with JavaScript, making your URL sharing use-case possible. It's not very hard to implement either, that stuff is covered quite early in most AngularJs resources out there. In fact, creating a large SPA without some sort of routing sounds like a nightmare.

[dragonwriter]

Or you can build a SPA that supports jumping to a particular resource with a URL, Like not breaking the back button in a SPA, this is technically possible, even if it is all-to-rarely done.