3 ms·

So removing it will simplify web pages? Sounds like a win/win to me.

by ysavir 4y ago

shadowgovt 4y ago
Not for users of Sheets, Docs, AutoCAD Web, myriad tools companies have built for their intranets, and hundreds of other apps, no. It will make them more complicated.
- ysavir 4y ago
  I can't see any argument for how removing javascript navigation will make apps more complicated. The desired functionality is literally built into the browser.
  - shadowgovt 4y ago
    Not more complicated in the sense of "more code;" more complicated in the sense of "harder to use." You had said "win/win" and I disagree that making apps bigger, clunkier, and slower by requiring more server-side negotiation would make them better for end-users. The hard-coded behavior of the browser doesn't always match the user's concept of what has happened when performance optimizations are added in. For example: for performance reasons, many web apps are logically divided into sections. Navigating between sections doesn't unload the current page, it retains it and context-switches to another page. This is done for several reasons (the main ones being performance and flicker-stoppage, so users aren't hit with a screen-blank navigating from one section to another). This trick is often accompliahed by being very creative with the routing so the user's experience is as if they are navigating around to different pages on a site (while in reality, a page navigation never occurs). console.cloud.google.com is an example of a site that works this way. AWS console does too; look closely while navigating around AWS and one will observe that the URL looks like https://us-east-2.console.aws.amazon.com/cloudformation/home?region=us-east-2#/exports https://us-east-2.console.aws.amazon.com/cloudformation/home..., i.e. the sub-panel is encoded locally in the fragment instead of up in the resource name, and going from subpanel to subpanel changes the fragment and pushes entries into history. ... but to get that seamless behavior, it has to inject history entries so that the back button takes the user to a previous logical page, not a previous URL the browser requested. Writing the app will be more complicated if the back button navigates the user entirely off of console.cloud.google.com instead of taking them to the previous pane they had open.
    - ysavir 4y ago
      > Not more complicated in the sense of "more code;" more complicated in the sense of "harder to use." You had said "win/win" and I disagree that making apps bigger, clunkier, and slower by requiring more server-side negotiation would make them better for end-users. People always say that, yet every time I encounter an app that doesn't use JS navigation, it always feels faster and smoother... And as for them being bigger and clunkier, in almost all cases I've experienced, the frontend code is by far the clunkier and bigger of the two. But maybe it's because I use Ruby and other backend languages are less generous in their accommodations. > The hard-coded behavior of the browser doesn't always match the user's concept of what has happened when performance optimizations are added in. Eliminating JS navigation doesn't mean eliminating JS. You'd still be asynchronously modifying backend state and browser state on a single page, you're just not using it to change pages. > For example: for performance reasons, many web apps are logically divided into sections. Navigating between sections doesn't unload the current page, it retains it and context-switches to another page. This is done for several reasons (the main ones being performance and flicker-stoppage, so users aren't hit with a screen-blank navigating from one section to another). This trick is often accompliahed by being very creative with the routing so the user's experience is as if they are navigating around to different pages on a site (while in reality, a page navigation never occurs). console.cloud.google.com is an example of a site that works this way. AWS console does too; look closely while navigating around AWS and one will observe that the URL looks like https://us-east-2.console.aws.amazon.com/cloudformation/home https://us-east-2.console.aws.amazon.com/cloudformation/home..., i.e. the sub-panel is encoded locally in the fragment instead of up in the resource name, and going from subpanel to subpanel changes the fragment and pushes entries into history. Do you have a study that demonstrates the impact of this website organization with JS navigation and without JS navigation? There's a lot of talk about this being more performant and eliminating flicker, but are those real problems? Does HN flicker for you when you move across pages? I've heard these reasons a hundred times, but rarely see evidence that they hold up under scrutiny. Usually it's an after-the-fact justification rather than an upfront necessity. > Writing the app will be more complicated if the back button navigates the user entirely off of console.cloud.google.com instead of taking them to the previous pane they had open. I feel like this answer is almost intentionally forgetting that URI paths exist without JS. Am I missing something in your answer that explains why they are insufficient?

So removing it will simplify web pages? Sounds like a win/win to me.

by ysavir 4y ago

So removing it will simplify web pages? Sounds like a win/win to me.

Not for users of Sheets, Docs, AutoCAD Web, myriad tools companies have built for their intranets, and hundreds of other apps, no. It will make them more complicated.

ysavir 4y ago
I can't see any argument for how removing javascript navigation will make apps more complicated. The desired functionality is literally built into the browser.
- shadowgovt 4y ago
  Not more complicated in the sense of "more code;" more complicated in the sense of "harder to use." You had said "win/win" and I disagree that making apps bigger, clunkier, and slower by requiring more server-side negotiation would make them better for end-users. The hard-coded behavior of the browser doesn't always match the user's concept of what has happened when performance optimizations are added in. For example: for performance reasons, many web apps are logically divided into sections. Navigating between sections doesn't unload the current page, it retains it and context-switches to another page. This is done for several reasons (the main ones being performance and flicker-stoppage, so users aren't hit with a screen-blank navigating from one section to another). This trick is often accompliahed by being very creative with the routing so the user's experience is as if they are navigating around to different pages on a site (while in reality, a page navigation never occurs). console.cloud.google.com is an example of a site that works this way. AWS console does too; look closely while navigating around AWS and one will observe that the URL looks like https://us-east-2.console.aws.amazon.com/cloudformation/home?region=us-east-2#/exports https://us-east-2.console.aws.amazon.com/cloudformation/home..., i.e. the sub-panel is encoded locally in the fragment instead of up in the resource name, and going from subpanel to subpanel changes the fragment and pushes entries into history. ... but to get that seamless behavior, it has to inject history entries so that the back button takes the user to a previous logical page, not a previous URL the browser requested. Writing the app will be more complicated if the back button navigates the user entirely off of console.cloud.google.com instead of taking them to the previous pane they had open.
  - ysavir 4y ago
    > Not more complicated in the sense of "more code;" more complicated in the sense of "harder to use." You had said "win/win" and I disagree that making apps bigger, clunkier, and slower by requiring more server-side negotiation would make them better for end-users. People always say that, yet every time I encounter an app that doesn't use JS navigation, it always feels faster and smoother... And as for them being bigger and clunkier, in almost all cases I've experienced, the frontend code is by far the clunkier and bigger of the two. But maybe it's because I use Ruby and other backend languages are less generous in their accommodations. > The hard-coded behavior of the browser doesn't always match the user's concept of what has happened when performance optimizations are added in. Eliminating JS navigation doesn't mean eliminating JS. You'd still be asynchronously modifying backend state and browser state on a single page, you're just not using it to change pages. > For example: for performance reasons, many web apps are logically divided into sections. Navigating between sections doesn't unload the current page, it retains it and context-switches to another page. This is done for several reasons (the main ones being performance and flicker-stoppage, so users aren't hit with a screen-blank navigating from one section to another). This trick is often accompliahed by being very creative with the routing so the user's experience is as if they are navigating around to different pages on a site (while in reality, a page navigation never occurs). console.cloud.google.com is an example of a site that works this way. AWS console does too; look closely while navigating around AWS and one will observe that the URL looks like https://us-east-2.console.aws.amazon.com/cloudformation/home https://us-east-2.console.aws.amazon.com/cloudformation/home..., i.e. the sub-panel is encoded locally in the fragment instead of up in the resource name, and going from subpanel to subpanel changes the fragment and pushes entries into history. Do you have a study that demonstrates the impact of this website organization with JS navigation and without JS navigation? There's a lot of talk about this being more performant and eliminating flicker, but are those real problems? Does HN flicker for you when you move across pages? I've heard these reasons a hundred times, but rarely see evidence that they hold up under scrutiny. Usually it's an after-the-fact justification rather than an upfront necessity. > Writing the app will be more complicated if the back button navigates the user entirely off of console.cloud.google.com instead of taking them to the previous pane they had open. I feel like this answer is almost intentionally forgetting that URI paths exist without JS. Am I missing something in your answer that explains why they are insufficient?