4 ms·

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

by Uehreka 11y ago

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.

arohner 11y ago
> 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 11y ago
  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.
yuvipanda 11y ago
Can't all those three things be done with simple AJAX too, instead of having to make your entire application Javascript based?

by Uehreka 11y ago

arohner 11y ago

> 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 11y ago
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.

yuvipanda 11y ago

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