3 ms·

> How much JavaScript is needed to accept my text input and provide auto complete options? If you're talking about Google's homepage, the answer is "a lot". Yo

> How much JavaScript is needed to accept my text input and provide auto complete options? If you're talking about Google's homepage, the answer is "a lot". You can check for yourself - go to google.com, select "view source" and compare the amount of Closure-compiled JavaScript against HTML markup.

junon 3y ago
I think you've missed the point. Google's primary web search feature could, in theory, be implemented without a line of JavaScript. That's how it was years and years ago anyway.
- sangnoir 3y ago
  I did not miss the point, I gave an answer based on the ground-truth rather than theory. > Google's primary web search feature could, in theory, be implemented without a line of JavaScript ...and yet, in practice, Google defaults to a JavaScript-heavy implementation. Search is Google's raison d'être and primary revenue driver, I posit it therefore is optimized up the wazoo. I wouldn't hastily assume incompence given those priors.
- zugi 3y ago
  I use Firefox with the NoScript addon and google.com still works just fine.
stephenr 3y ago
The important word in the question you quoted is needed. Google homepage is 2MB. Two fucking megabytes. Without JS, it's 200K. I can't be the only person who remembers when Google was known for even omitting technically optional html tags on their homepage, to make it load fast - they even documented this as a formal suggestion: https://google.github.io/styleguide/htmlcssguide.html#Optional_Tags https://google.github.io/styleguide/htmlcssguide.html#Option...
- Kharacternyk 3y ago
  Thank you for the link. I had no idea about most of the optional tags. It looks ugly when taken to extremes, though.
- sangnoir 3y ago
  > I can't be the only person who remembers when Google was known for even omitting technically optional html tags on their homepage, to make it load fast This was back when a large fraction of search users were on 56k modems. Advances in broadband connectivity, caching, browser rendering, resource loading scheduling, and front-end engineering practices may result in the non-intuitive scenario where the 2MB Google homepage in 2024 has the same (or better!) 99-percentile First-Meaningful-Paint time as a stripped-down 2kb homepage in 2006. The homepage size is no longer that important because how much time do you save by shrinking a page from 2MB to 300kb on a 50mbps connection with a warm cache?Browser cache sizes are much larger than they were 10 years ago (thanks to growth in client storage). After all, page weight is mostly used as a proxy for loading time.
  - stephenr 3y ago
    I'm sorry you're going to have to pick an argument and stick to it before I can possibly hope to respond. Either performance is so critical that a few kb to do feature detection is too much, or line performance has improved so much that 2MB of JavaScript for a text box and two buttons is "acceptable". You can't have it both ways.
    - sangnoir 3y ago
      > You can't have it both ways. Your argument goes against empirical evidence in this instance. You can have it "both ways" when client-side feature detection is the slower choice on high bandwidth connections and you want to consistently render the UI within 200ms. Performance goes beyond raw bandwidth, and as with all things engineering, involves tradeoffs: client-side feature detection has higher latency (server-client-server round trip and network connection overheads) and is therefore unsuitable for logic that executes before the first render of above-the-fold content. All of this is pragmatic, well-known and not controversial among people who work on optimizing FE performance. Your no-serverside-detection absolutism is disproved by the many instances of UA-string parsing in our present reality.

junon 3y ago

I think you've missed the point. Google's primary web search feature could, in theory, be implemented without a line of JavaScript. That's how it was years and years ago anyway.

sangnoir 3y ago
I did not miss the point, I gave an answer based on the ground-truth rather than theory. > Google's primary web search feature could, in theory, be implemented without a line of JavaScript ...and yet, in practice, Google defaults to a JavaScript-heavy implementation. Search is Google's raison d'être and primary revenue driver, I posit it therefore is optimized up the wazoo. I wouldn't hastily assume incompence given those priors.
zugi 3y ago
I use Firefox with the NoScript addon and google.com still works just fine.

stephenr 3y ago

The important word in the question you quoted is needed. Google homepage is 2MB. Two fucking megabytes. Without JS, it's 200K. I can't be the only person who remembers when Google was known for even omitting technically optional html tags on their homepage, to make it load fast - they even documented this as a formal suggestion: https://google.github.io/styleguide/htmlcssguide.html#Optional_Tags https://google.github.io/styleguide/htmlcssguide.html#Option...

Kharacternyk 3y ago
Thank you for the link. I had no idea about most of the optional tags. It looks ugly when taken to extremes, though.
sangnoir 3y ago
> I can't be the only person who remembers when Google was known for even omitting technically optional html tags on their homepage, to make it load fast This was back when a large fraction of search users were on 56k modems. Advances in broadband connectivity, caching, browser rendering, resource loading scheduling, and front-end engineering practices may result in the non-intuitive scenario where the 2MB Google homepage in 2024 has the same (or better!) 99-percentile First-Meaningful-Paint time as a stripped-down 2kb homepage in 2006. The homepage size is no longer that important because how much time do you save by shrinking a page from 2MB to 300kb on a 50mbps connection with a warm cache?Browser cache sizes are much larger than they were 10 years ago (thanks to growth in client storage). After all, page weight is mostly used as a proxy for loading time.
- stephenr 3y ago
  I'm sorry you're going to have to pick an argument and stick to it before I can possibly hope to respond. Either performance is so critical that a few kb to do feature detection is too much, or line performance has improved so much that 2MB of JavaScript for a text box and two buttons is "acceptable". You can't have it both ways.
  - sangnoir 3y ago
    > You can't have it both ways. Your argument goes against empirical evidence in this instance. You can have it "both ways" when client-side feature detection is the slower choice on high bandwidth connections and you want to consistently render the UI within 200ms. Performance goes beyond raw bandwidth, and as with all things engineering, involves tradeoffs: client-side feature detection has higher latency (server-client-server round trip and network connection overheads) and is therefore unsuitable for logic that executes before the first render of above-the-fold content. All of this is pragmatic, well-known and not controversial among people who work on optimizing FE performance. Your no-serverside-detection absolutism is disproved by the many instances of UA-string parsing in our present reality.