6 ms·

Split the form into pages, and use session variables to maintain state. Regarding form fields appearing and all your fancy front end logic: none of this would f

Split the form into pages, and use session variables to maintain state. Regarding form fields appearing and all your fancy front end logic: none of this would fly in user testing. I find it mind-boggling there’s a generation of developers after me that doesn’t know the basics of server side state. No offence intended to yourself, and good on you for putting yourself out there to ask :)

hn_throwaway_99 7y ago
As a web developer for the past 20 years, I do know how server-side state works. What baffles me is that, while there is certainly much to complain about the state of front-end JS dev today, the attitude of some that moving the web back 15 years is a good thing. There is a reason single-page apps became a thing, so I'm not clear why you think a page refresh for every user interaction is somehow a good thing. The dismissive attitude that "Regarding form fields appearing and all your fancy front end logic: none of this would fly in user testing" flies in the face of how 90% of heavy consumer front ends out there work today.
- malvosenior 7y ago
  Single-page apps became a thing because of lack of development resources to build native apps or properly engineer server side solutions (as well as a business desire to centralize and lock down the product so people have to experience ads, pay subscriptions...). It has nothing to do with creating a user friendly experience. 100% of the time a user would benefit from a native app or properly engineered server-side rendered web page over a SPA.
  - JumpCrisscross 7y ago
    > 100% of the time a user would benefit from a native app I strongly prefer single-page web apps over native apps. Web apps are constrained by my browser. Native apps get a lot more trust.
    - AnIdiotOnTheNet 7y ago
      That's a problem we should have fixed on the platform side long ago, but didn't. Now we're stuck with the garbage fire of the modern web. That doesn't make it better.
  - syntheticcdo 7y ago
    > 100% of the time Nothing in software engineering is absolute. And even if something were to be 100% the correct solution one day, the next it could change.
  - ScottFree 7y ago
    I agree, but there is one problem: most people would rather use an SPA than have to download an app and have to keep it up to date themselves. I wonder if there's a market for an alternative "browser" that loads "native" code (or as close as practically possible) and runs it in a sandbox.
    - eitland 7y ago
      > I wonder if there's a market for an alternative "browser" that loads "native" code (or as close as practically possible) and runs it in a sandbox. Electron comes close, but many don’t like it at all. (I have somewhat mixed experiences, I love VS Code but I’m not too fond of Slack.)
      - ScottFree 7y ago
        Electron isn't native in any sense of the word. I meant something more like OS-specific binary executables that get loaded and executed in a sandbox. Mike Acton once said something about having created a browser plugin his team used that loaded and ran binary exe tools on demand, but that it was also wildly insecure. At least I think he said something like that. My memory could be wrong about that.
      - icedchai 7y ago
        We had this 20 years ago with Java (not native obviously) and ActiveX (Windows x86 only.)
    - favorited 7y ago
      > most people would rather use an SPA than have to download an app and have to keep it up to date themselves Citation?
      - ScottFree 7y ago
        > Citation? No.
    - mftrhu 7y ago
      > I wonder if there's a market for an alternative "browser" that loads "native" code (or as close as practically possible) and runs it in a sandbox. This is probably not what you had in mind, and I'm not sure how good it would be at sandboxing, but REBOL Reblets imho come close to this <http://www.rebol.com/reblets.html> http://www.rebol.com/reblets.html>
  - hombre_fatal 7y ago
    I have uBlock Origin on my browser. I can even change the font-size on a web page if I need to. A native app can be doing anything it wants without my knowledge, and I can't even change the font-size. Native apps have a performance benefit at the expense of everything we take for granted on the web, like being able to open up a developer console and inspect it. For example, I noticed that the top language translation app on the Mac App Store incurs a Google Analytics request for every keystroke. And since there's no easy network tab I can open on any app, I only found it out because I was curious how it worked and mitm'd it with a proxy. And I couldn't just toss uBlock Origin at it to de-trackify it like I can any web app. Doesn't seem like a 100% epic win for users to me. In fact, the only upside I can even think of is that it probably uses less RAM than a Chrome tab opened to Google Translate. Let's slow down and acknowledge the trade-offs before we go all-in on HN memes like native app superiority.
  - RussianCow 7y ago
    > It has nothing to do with creating a user friendly experience. This is absolutely not true. Think about any kind of dynamic dashboard or data management platform. Having full page reloads for any minor change to filters, etc, is simply an unacceptable UX. But it has to be web-based because you need to be able to access it from any device, anywhere, without installing an app. Plus, on a personal level, there are many services for which I will never install a native app—because I don't use it often, or because the native app provides no added benefit, or for one of a hundred other reasons. Those services don't get my business if they don't have a web app.
    - dredmorbius 7y ago
      That is a significant, but limited-use, case. Theere's no reason a static contnt page must require JS Simply to render text, with a blank page as fallback. Better ways of addressing the dashboaard example might be worth considering. Too: bullshit dashboards with JS-based fakery; https://www.theverge.com/2016/11/8/13571216/new-york-times-election-forecast-jitter-needle https://www.theverge.com/2016/11/8/13571216/new-york-times-e...
      - RussianCow 7y ago
        Limited? That describes about half the applications I've built in my career! In all seriousness, there is a big difference between static content pages and full-blown applications; the cost to make the latter work properly without JS enabled is almost never worth it. But the same is true even for some static pages; for instance, I would never expect that NY times election forecast page to work without JavaScript, and don't see any reason that it should. (The "JS-based fakery" is pretty irrelevant to the discussion, IMO.)
        dredmorbius 7y ago
        What fraction of all HTML pageloads? And: Sampling bias. A simple static page shouldn't require development. Hence, anyone doing web dev will have experience skewed strongly to more complex designs. How would you describe the basic underlying structure and mechanics of a typical app you've built?
- saagarjha 7y ago
  > What baffles me is that, while there is certainly much to complain about the state of front-end JS dev today, the attitude of some that moving the web back 15 years is a good thing. The problem is that many people, for various reason (accessibility, poor network connection, low-end hardware, etc.) are stuck "in the past" with regards to the web. This doesn't mean you have to make this the experience for everyone using your website: just make sure it degrades gracefully for those who can't use the new shiny stuff.
  - RussianCow 7y ago
    This is often much easier said than done. Graceful degradation isn't free, and for many types of applications, simply isn't worth the effort to support.
    - saagarjha 7y ago
      > Graceful degradation isn't free, and for many types of applications, simply isn't worth the effort to support. I hate to say it, but you're essentially saying "we can't afford to support people who are disabled, cannot afford the newest hardware, or are simply driving through a place with poor reception".
      - RussianCow 7y ago
        Yes, unfortunately that's exactly what I'm saying. In a perfect world, every app would be fully accessible, colorblind-friendly, work offline, etc etc. But in reality, all of those things cost money, and sometimes the cost outweighs the benefits. To give an extreme example, if my app has 1 million users, but only one is blind, do you expect me to spend (potentially significant) development resources on that single user? You have to do that cost-benefit analysis based on how important those things are to your business—for instance, screen reader support is an absolute necessity for the public sector and certain information-heavy apps, but probably not as important for visual tools.
      - mankeysee 7y ago
        It's absolutely ridiculous how some content based websites require several MB of js to function. And the devs say this is because it is 'easier' to write such apps. And if the thought of optimization even comes to their minds, its just adding another layer on top of this madness to manage the layers below, or saying its too hard. Of course it is hard if you start with an overcomplex solution in the first place and try to trim away stuff from it. How hard exactly is it to write some plain html and css, with js doing some optional improvements? Most problems of web development are self inflicted. I was talking to someone once about how ridiculously bloated Imgur is and that I had to use Imgoat because of the slow internet I was experiencing then. Of course they were trying to make all kinds of excuses like imgur not having servers nearby etc. But of course the really simple fact couldn't get to their heads that Imgur downloads like what 2-3 MB maybe even more of crap minus the actual image whereas Imgoat is something like 500 KB. No amount of network optimizations and caches etc are going to get over this fact. And also, such optimizations are over and above the page download size improvements anyways. If Imgoat used such techniques it'd be even faster. Most importantly: both sites have the exact same and simple core function, yet one site is so many times more bloated than the other. I will let you derive your own conclusions as to what this means. And imgur also has the typical horrendous js misuses such as scrollbar hijacking that makes absolutely no sense etc.
- eitland 7y ago
  > the attitude of some that moving the web back 15 years is a good thing. Straw man. We don’t want to go 15 years back, only 10 :-) Seriously, the web was at a local maximum around 2009. Google worked, GMail was OK, Ajax was expected for r new stuff but was still written with graceful degradation in mind.
- Dunedan 7y ago
  > There is a reason single-page apps became a thing, so I'm not clear why you think a page refresh for every user interaction is somehow a good thing. So the reason I always hear is performance: Less HTTP-requests, less latency, therefore better user experience. While that might be the case for flaky mobile connections (although executing lots of Javascript on resource constraint devices might not be the best idea either), with fast wired connections I experience the opposite: The single page apps of today feel a lot slower to me, than the websites with the same functionality did 10 years ago, thanks to all the computation which has to be done on client side. Just take Youtube for example: What a bad experience nowadays, especially with Firefox. That was way better back in a time when they didn't try to avoid page refreshes. And it's not just Youtube, it's all over the web. A welcome change to all of that is HN, because it still feels as fast as websites did, before frontend development was even a thing.
  - away_throw 7y ago
    You can disable the new polymer layout for YouTube on Firefox using a console command. It brings back the old layout which is much faster and more functional.
  - anderspitman 7y ago
    Performance of JS is much more controllable than round-trip latency.
- mankeysee 7y ago
  Theres a huge spectrum between SPAs and pure js-less apps.
ebiester 7y ago
Until someone presses the back button. :) I find it mind-boggling that people forget the hell of flash scope and the back button and broken history and POST-redirect-GET. Session state was miserable and the best thing about SPAs is avoiding that.
- icedchai 7y ago
  The truth is SPAs have to re-invent all of that on the client side. More SPAs have broken back button and history than server side apps ever did.
hombre_fatal 7y ago
Since they specifically point out back-end state and full page reloads as an option, they're clearly asking from a place of incredulity. As in, "Wait, HNers actually think this is good UX?" And no, moving client-side logic to the back-end isn't self-evidently superior. Not for your implementation nor for user UX. So you'd have to use more than condescension to make your point. Full page reloads for an "Add Row" button died for more reasons than just "web developers are idiots and don't realize how everyone actually loved that."

hn_throwaway_99 7y ago

As a web developer for the past 20 years, I do know how server-side state works. What baffles me is that, while there is certainly much to complain about the state of front-end JS dev today, the attitude of some that moving the web back 15 years is a good thing. There is a reason single-page apps became a thing, so I'm not clear why you think a page refresh for every user interaction is somehow a good thing. The dismissive attitude that "Regarding form fields appearing and all your fancy front end logic: none of this would fly in user testing" flies in the face of how 90% of heavy consumer front ends out there work today.

malvosenior 7y ago
Single-page apps became a thing because of lack of development resources to build native apps or properly engineer server side solutions (as well as a business desire to centralize and lock down the product so people have to experience ads, pay subscriptions...). It has nothing to do with creating a user friendly experience. 100% of the time a user would benefit from a native app or properly engineered server-side rendered web page over a SPA.
- JumpCrisscross 7y ago
  > 100% of the time a user would benefit from a native app I strongly prefer single-page web apps over native apps. Web apps are constrained by my browser. Native apps get a lot more trust.
  - AnIdiotOnTheNet 7y ago
    That's a problem we should have fixed on the platform side long ago, but didn't. Now we're stuck with the garbage fire of the modern web. That doesn't make it better.
- syntheticcdo 7y ago
  > 100% of the time Nothing in software engineering is absolute. And even if something were to be 100% the correct solution one day, the next it could change.
- ScottFree 7y ago
  I agree, but there is one problem: most people would rather use an SPA than have to download an app and have to keep it up to date themselves. I wonder if there's a market for an alternative "browser" that loads "native" code (or as close as practically possible) and runs it in a sandbox.
  - eitland 7y ago
    > I wonder if there's a market for an alternative "browser" that loads "native" code (or as close as practically possible) and runs it in a sandbox. Electron comes close, but many don’t like it at all. (I have somewhat mixed experiences, I love VS Code but I’m not too fond of Slack.)
    - ScottFree 7y ago
      Electron isn't native in any sense of the word. I meant something more like OS-specific binary executables that get loaded and executed in a sandbox. Mike Acton once said something about having created a browser plugin his team used that loaded and ran binary exe tools on demand, but that it was also wildly insecure. At least I think he said something like that. My memory could be wrong about that.
    - icedchai 7y ago
      We had this 20 years ago with Java (not native obviously) and ActiveX (Windows x86 only.)
  - favorited 7y ago
    > most people would rather use an SPA than have to download an app and have to keep it up to date themselves Citation?
    - ScottFree 7y ago
      > Citation? No.
  - mftrhu 7y ago
    > I wonder if there's a market for an alternative "browser" that loads "native" code (or as close as practically possible) and runs it in a sandbox. This is probably not what you had in mind, and I'm not sure how good it would be at sandboxing, but REBOL Reblets imho come close to this <http://www.rebol.com/reblets.html> http://www.rebol.com/reblets.html>
- hombre_fatal 7y ago
  I have uBlock Origin on my browser. I can even change the font-size on a web page if I need to. A native app can be doing anything it wants without my knowledge, and I can't even change the font-size. Native apps have a performance benefit at the expense of everything we take for granted on the web, like being able to open up a developer console and inspect it. For example, I noticed that the top language translation app on the Mac App Store incurs a Google Analytics request for every keystroke. And since there's no easy network tab I can open on any app, I only found it out because I was curious how it worked and mitm'd it with a proxy. And I couldn't just toss uBlock Origin at it to de-trackify it like I can any web app. Doesn't seem like a 100% epic win for users to me. In fact, the only upside I can even think of is that it probably uses less RAM than a Chrome tab opened to Google Translate. Let's slow down and acknowledge the trade-offs before we go all-in on HN memes like native app superiority.
- RussianCow 7y ago
  > It has nothing to do with creating a user friendly experience. This is absolutely not true. Think about any kind of dynamic dashboard or data management platform. Having full page reloads for any minor change to filters, etc, is simply an unacceptable UX. But it has to be web-based because you need to be able to access it from any device, anywhere, without installing an app. Plus, on a personal level, there are many services for which I will never install a native app—because I don't use it often, or because the native app provides no added benefit, or for one of a hundred other reasons. Those services don't get my business if they don't have a web app.
  - dredmorbius 7y ago
    That is a significant, but limited-use, case. Theere's no reason a static contnt page must require JS Simply to render text, with a blank page as fallback. Better ways of addressing the dashboaard example might be worth considering. Too: bullshit dashboards with JS-based fakery; https://www.theverge.com/2016/11/8/13571216/new-york-times-election-forecast-jitter-needle https://www.theverge.com/2016/11/8/13571216/new-york-times-e...
    - RussianCow 7y ago
      Limited? That describes about half the applications I've built in my career! In all seriousness, there is a big difference between static content pages and full-blown applications; the cost to make the latter work properly without JS enabled is almost never worth it. But the same is true even for some static pages; for instance, I would never expect that NY times election forecast page to work without JavaScript, and don't see any reason that it should. (The "JS-based fakery" is pretty irrelevant to the discussion, IMO.)
      - dredmorbius 7y ago
        What fraction of all HTML pageloads? And: Sampling bias. A simple static page shouldn't require development. Hence, anyone doing web dev will have experience skewed strongly to more complex designs. How would you describe the basic underlying structure and mechanics of a typical app you've built?
saagarjha 7y ago
> What baffles me is that, while there is certainly much to complain about the state of front-end JS dev today, the attitude of some that moving the web back 15 years is a good thing. The problem is that many people, for various reason (accessibility, poor network connection, low-end hardware, etc.) are stuck "in the past" with regards to the web. This doesn't mean you have to make this the experience for everyone using your website: just make sure it degrades gracefully for those who can't use the new shiny stuff.
- RussianCow 7y ago
  This is often much easier said than done. Graceful degradation isn't free, and for many types of applications, simply isn't worth the effort to support.
  - saagarjha 7y ago
    > Graceful degradation isn't free, and for many types of applications, simply isn't worth the effort to support. I hate to say it, but you're essentially saying "we can't afford to support people who are disabled, cannot afford the newest hardware, or are simply driving through a place with poor reception".
    - RussianCow 7y ago
      Yes, unfortunately that's exactly what I'm saying. In a perfect world, every app would be fully accessible, colorblind-friendly, work offline, etc etc. But in reality, all of those things cost money, and sometimes the cost outweighs the benefits. To give an extreme example, if my app has 1 million users, but only one is blind, do you expect me to spend (potentially significant) development resources on that single user? You have to do that cost-benefit analysis based on how important those things are to your business—for instance, screen reader support is an absolute necessity for the public sector and certain information-heavy apps, but probably not as important for visual tools.
    - mankeysee 7y ago
      It's absolutely ridiculous how some content based websites require several MB of js to function. And the devs say this is because it is 'easier' to write such apps. And if the thought of optimization even comes to their minds, its just adding another layer on top of this madness to manage the layers below, or saying its too hard. Of course it is hard if you start with an overcomplex solution in the first place and try to trim away stuff from it. How hard exactly is it to write some plain html and css, with js doing some optional improvements? Most problems of web development are self inflicted. I was talking to someone once about how ridiculously bloated Imgur is and that I had to use Imgoat because of the slow internet I was experiencing then. Of course they were trying to make all kinds of excuses like imgur not having servers nearby etc. But of course the really simple fact couldn't get to their heads that Imgur downloads like what 2-3 MB maybe even more of crap minus the actual image whereas Imgoat is something like 500 KB. No amount of network optimizations and caches etc are going to get over this fact. And also, such optimizations are over and above the page download size improvements anyways. If Imgoat used such techniques it'd be even faster. Most importantly: both sites have the exact same and simple core function, yet one site is so many times more bloated than the other. I will let you derive your own conclusions as to what this means. And imgur also has the typical horrendous js misuses such as scrollbar hijacking that makes absolutely no sense etc.
eitland 7y ago
> the attitude of some that moving the web back 15 years is a good thing. Straw man. We don’t want to go 15 years back, only 10 :-) Seriously, the web was at a local maximum around 2009. Google worked, GMail was OK, Ajax was expected for r new stuff but was still written with graceful degradation in mind.
Dunedan 7y ago
> There is a reason single-page apps became a thing, so I'm not clear why you think a page refresh for every user interaction is somehow a good thing. So the reason I always hear is performance: Less HTTP-requests, less latency, therefore better user experience. While that might be the case for flaky mobile connections (although executing lots of Javascript on resource constraint devices might not be the best idea either), with fast wired connections I experience the opposite: The single page apps of today feel a lot slower to me, than the websites with the same functionality did 10 years ago, thanks to all the computation which has to be done on client side. Just take Youtube for example: What a bad experience nowadays, especially with Firefox. That was way better back in a time when they didn't try to avoid page refreshes. And it's not just Youtube, it's all over the web. A welcome change to all of that is HN, because it still feels as fast as websites did, before frontend development was even a thing.
- away_throw 7y ago
  You can disable the new polymer layout for YouTube on Firefox using a console command. It brings back the old layout which is much faster and more functional.
- anderspitman 7y ago
  Performance of JS is much more controllable than round-trip latency.
mankeysee 7y ago
Theres a huge spectrum between SPAs and pure js-less apps.

ebiester 7y ago

Until someone presses the back button. :) I find it mind-boggling that people forget the hell of flash scope and the back button and broken history and POST-redirect-GET. Session state was miserable and the best thing about SPAs is avoiding that.

icedchai 7y ago
The truth is SPAs have to re-invent all of that on the client side. More SPAs have broken back button and history than server side apps ever did.

hombre_fatal 7y ago

Since they specifically point out back-end state and full page reloads as an option, they're clearly asking from a place of incredulity. As in, "Wait, HNers actually think this is good UX?" And no, moving client-side logic to the back-end isn't self-evidently superior. Not for your implementation nor for user UX. So you'd have to use more than condescension to make your point. Full page reloads for an "Add Row" button died for more reasons than just "web developers are idiots and don't realize how everyone actually loved that."