5 ms·

I agree with you for content sites or primarily consumption driven apps but I haven't written one of those in 8 years. I'm currently working on an application t

I agree with you for content sites or primarily consumption driven apps but I haven't written one of those in 8 years. I'm currently working on an application that we are having to purposefully keep features out of, not because they are slowing the page down, or increasing TTI, but because we risk offending our business partners by building a one for one replacement of their multi-thousand dollar per seat desktop software. There's just no getting around the MB of JavaScript we need for this app. And for this type of application, we are much more concerned about the speed of individual actions on the page than page load. The site still loads faster than the desktop application opens.

davidgh 9y ago
This. Set aside the performance of the initial load for a moment. When I interact with the SPAs we’ve built in recent years, I am still shocked how snappy they are as I perform actions throughout the site. Every “pageview” requires the download of a tiny REST API response and comparably tiny HTML fragment. As a user - that experience is a pure delight compared to a full blown page re-load, re-download and re-render with every action. As a user it infuriates me when I fill out a long form, hit submit and find out I forgot to select the proper “Mr. Mrs. Ms” title and my password, credit card number and PIN have all be blown away. As a user I’m willing to pay a few more seconds upfront for snappy and seamless interactions as I use the app. I think the mistake that is more often committed (and where I myself as a user have less patience) is treating everything that can be accessed via URL as an “app”. If the user is coming to just download bytes, don’t build an app. An app is only justified when a user is coming to manipulate data.
- samsonradu 9y ago
  > As a user it infuriates me when I fill out a long form, hit submit and find out I forgot to select the proper “Mr. Mrs. Ms” title and my password, credit card number and PIN have all be blown away. I'm quite sure this is a sign of poor development, regardless of the form being validated on the server or the client. There is no reason for the server not to send back a fully pre-populated form.
  - Can_Not 9y ago
    Credit card info, passwords...
    - naasking 9y ago
      You're already submitting it to the server. It's no less secure sending it back if there's a problem.
      - zbentley 9y ago
        This comment displays a worrying misunderstanding of web security. Sending passwords (or credit card numbers or other scary stuff) in plaintext over the wire is bad. Hash them securely (well, as securely as you can on the client side). Sending them twice is worse. Storing them with the session data on the backend so that they can be sent back to the client to repopulate a form is way worse, since more than one webserver may be handling a session, that plaintext data will have to be stored in a centralized database (e.g. memcached), which is really really bad, even if that storage is temporary. Some web forms get around this by just sending back the lengths of the individual fields so they can be masked when the form is repopulated, but that's less common and is something that doesn't occur to lots of developers (store the length, but don't send the whole string). Instead, it's easier to follow the mantra of "never store the passwords in plaintext, never send them over the wire in plaintext". Which is why most web forms clear out the sensitive fields when repopulated via the server. TL;DR it is much, much less secure to do this.
        naasking 9y ago
        > This comment displays a worrying misunderstanding of web security. Sending passwords (or credit card numbers or other scary stuff) in plaintext over the wire is bad What are you talking about? Who said anything about plaintext? And no one said anything about sessions either. If you're submitting to the server in plaintext, then returning in plaintext is no less secure, but you're stupid for not submitting over https which is free. If you're submitting to the server over https then it's definitely no less secure to return the data.

davidgh 9y ago

This. Set aside the performance of the initial load for a moment. When I interact with the SPAs we’ve built in recent years, I am still shocked how snappy they are as I perform actions throughout the site. Every “pageview” requires the download of a tiny REST API response and comparably tiny HTML fragment. As a user - that experience is a pure delight compared to a full blown page re-load, re-download and re-render with every action. As a user it infuriates me when I fill out a long form, hit submit and find out I forgot to select the proper “Mr. Mrs. Ms” title and my password, credit card number and PIN have all be blown away. As a user I’m willing to pay a few more seconds upfront for snappy and seamless interactions as I use the app. I think the mistake that is more often committed (and where I myself as a user have less patience) is treating everything that can be accessed via URL as an “app”. If the user is coming to just download bytes, don’t build an app. An app is only justified when a user is coming to manipulate data.

samsonradu 9y ago
> As a user it infuriates me when I fill out a long form, hit submit and find out I forgot to select the proper “Mr. Mrs. Ms” title and my password, credit card number and PIN have all be blown away. I'm quite sure this is a sign of poor development, regardless of the form being validated on the server or the client. There is no reason for the server not to send back a fully pre-populated form.
- Can_Not 9y ago
  Credit card info, passwords...
  - naasking 9y ago
    You're already submitting it to the server. It's no less secure sending it back if there's a problem.
    - zbentley 9y ago
      This comment displays a worrying misunderstanding of web security. Sending passwords (or credit card numbers or other scary stuff) in plaintext over the wire is bad. Hash them securely (well, as securely as you can on the client side). Sending them twice is worse. Storing them with the session data on the backend so that they can be sent back to the client to repopulate a form is way worse, since more than one webserver may be handling a session, that plaintext data will have to be stored in a centralized database (e.g. memcached), which is really really bad, even if that storage is temporary. Some web forms get around this by just sending back the lengths of the individual fields so they can be masked when the form is repopulated, but that's less common and is something that doesn't occur to lots of developers (store the length, but don't send the whole string). Instead, it's easier to follow the mantra of "never store the passwords in plaintext, never send them over the wire in plaintext". Which is why most web forms clear out the sensitive fields when repopulated via the server. TL;DR it is much, much less secure to do this.
      - naasking 9y ago
        > This comment displays a worrying misunderstanding of web security. Sending passwords (or credit card numbers or other scary stuff) in plaintext over the wire is bad What are you talking about? Who said anything about plaintext? And no one said anything about sessions either. If you're submitting to the server in plaintext, then returning in plaintext is no less secure, but you're stupid for not submitting over https which is free. If you're submitting to the server over https then it's definitely no less secure to return the data.