3 ms·

I get the best practice and why relying on the User Agent is helplessly flawed, but I've never come across a better way to get a sneak peek into the (first) Ini

I get the best practice and why relying on the User Agent is helplessly flawed, but I've never come across a better way to get a sneak peek into the (first) Initial Page Request of a customer to your web app. E.g. if you'd wanted to improve the page performance and weight of your app, you'll want to keep unused js/css to near zero. If you'd rely on feature detection, your critical path for "showing the initial screen of the app" is bound to "download feature detect, parse it, execute it, fetch correct variants of your js/css packages, parse them, execute them, show screen". That's not cool, imho.

judge2020 4y ago
Changing the UA only changes the behavior of the web server, so unless that's some block of untouchable code owned by some other team made to 'optimize' page loads for different clients, you're not doing yourself any favors by changing it in your browser; you should be loading up the client itself since you can't simulate the actual engine loading your web app differently. > If you'd rely on feature detection, your critical path for "showing the initial screen of the app" is bound to "download feature detect, parse it, execute it, fetch correct variants of your js/css packages, parse them, execute them, show screen". That's not cool, imho. Even for barebones web apps, your initial html response should have either empty data (but otherwise a visible UI) or a SSR'd version of the page shown while the JS downloads and executes.
- nforgerit 4y ago
  1) If clients spoof their UA, they just get what they asked for. Couldn't care less. 2) With SSR you're actually making a case for sniffing the UA for the client's device class. Web apps might need to ship vastly different but overlapping code across different device classes. I'm not even talking about things that can be lazily loaded subsequently, I'm talking about the initial screen for given URL. 3) I'm _not_ going to show the customer any loading spinner or just show a white page for 2s. We had that with Java Applets, remember? All in all, I'm not saying we should getting back into optimizing web apps for certain os/browsers/versions. What I'm saying is there might be good reasons where the mess of classifying the device on the (first) Initial Page Request is acceptable, given the alternatives.
  - judge2020 4y ago
    > 1) If clients spoof their UA, they just get what they asked for. Couldn't care less. I thought you were specifically talking about testing the behavior of your website on different client by changing your browser's UA. The only legitimate use would be if you have a mobile-only stylesheet like older wordpress themes (because you said "I've never come across a better way to get a sneak peek into the (first) Initial Page Request of a customer to your web app") > 2) With SSR you're actually making a case for sniffing the UA for the client's device class. Web apps might need to ship vastly different but overlapping code across different device classes. I'm not even talking about things that can be lazily loaded subsequently, I'm talking about the initial screen for given URL. I'm not sure why this would be the case. For Teams, they can just load a purple top bar with the words "Microsoft Teams: Loading", right? That's a single responsive stylesheet. > 3) I'm _not_ going to show the customer any loading spinner or just show a white page for 2s. We had that with Java Applets, remember? What else are you going to show while the page loads? A fake UI with fake data? As soon as the JS starts executing and loading data, that data can start to populate the screen.
  - 3np 4y ago
    How do you deal with guaranteeing this approach doesn't break users with non-default settings and preferences?
    - oblio 4y ago
      He probably doesn't, but do you have specific settings in mind?

judge2020 4y ago

Changing the UA only changes the behavior of the web server, so unless that's some block of untouchable code owned by some other team made to 'optimize' page loads for different clients, you're not doing yourself any favors by changing it in your browser; you should be loading up the client itself since you can't simulate the actual engine loading your web app differently. > If you'd rely on feature detection, your critical path for "showing the initial screen of the app" is bound to "download feature detect, parse it, execute it, fetch correct variants of your js/css packages, parse them, execute them, show screen". That's not cool, imho. Even for barebones web apps, your initial html response should have either empty data (but otherwise a visible UI) or a SSR'd version of the page shown while the JS downloads and executes.

nforgerit 4y ago
1) If clients spoof their UA, they just get what they asked for. Couldn't care less. 2) With SSR you're actually making a case for sniffing the UA for the client's device class. Web apps might need to ship vastly different but overlapping code across different device classes. I'm not even talking about things that can be lazily loaded subsequently, I'm talking about the initial screen for given URL. 3) I'm _not_ going to show the customer any loading spinner or just show a white page for 2s. We had that with Java Applets, remember? All in all, I'm not saying we should getting back into optimizing web apps for certain os/browsers/versions. What I'm saying is there might be good reasons where the mess of classifying the device on the (first) Initial Page Request is acceptable, given the alternatives.
- judge2020 4y ago
  > 1) If clients spoof their UA, they just get what they asked for. Couldn't care less. I thought you were specifically talking about testing the behavior of your website on different client by changing your browser's UA. The only legitimate use would be if you have a mobile-only stylesheet like older wordpress themes (because you said "I've never come across a better way to get a sneak peek into the (first) Initial Page Request of a customer to your web app") > 2) With SSR you're actually making a case for sniffing the UA for the client's device class. Web apps might need to ship vastly different but overlapping code across different device classes. I'm not even talking about things that can be lazily loaded subsequently, I'm talking about the initial screen for given URL. I'm not sure why this would be the case. For Teams, they can just load a purple top bar with the words "Microsoft Teams: Loading", right? That's a single responsive stylesheet. > 3) I'm _not_ going to show the customer any loading spinner or just show a white page for 2s. We had that with Java Applets, remember? What else are you going to show while the page loads? A fake UI with fake data? As soon as the JS starts executing and loading data, that data can start to populate the screen.
- 3np 4y ago
  How do you deal with guaranteeing this approach doesn't break users with non-default settings and preferences?
  - oblio 4y ago
    He probably doesn't, but do you have specific settings in mind?