Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

www.google.com – The page is blank when accessed

github.com

Post reply on HN
Print view View original

291–300 of 320 posts

Re: www.google.com – The page is blank when accessed

#291

Post by eviks »

hedora wrote: post #288
eviks wrote: post #278

Earlier quoted context omitted.

To make an actual "better" argument you have to address the aforementioned limitations

> Then there are also the downsides mentioned above (less convenient, no preview, not portable across search engines), so no, it's not a strict win, but an inferior alternative which is superior only in those cases where you can't setup something better - less convenient: Addressed by my comment. - no preview: I do not want preview, so this is a bonus. It's also orthogonal, since if the search bar was configured to p…

> - less convenient: Addressed by my comment.

Not addressed, Shift+1+w is less convenient than w, try to address that by your comment!

> I do not want preview, so this is a bonus.

Not a bonus since you can achieve the same natively, so again not better

> It's also orthogonal, since if the search bar was configured to preview, it could also display bang results.

No it couldn't? What's your preview link to DDG to show the results of a Wikipedia page for a given search term in the browser?

> - not portable across search engines: It already works on all non-terrible search engines because they standardized the bangs.

Since these don't exist (DDG is very similar to Google in search quality), it doesn't work. But this is personal, so if your needs are narrow enough to be covered just by DDG+Kagi, than you obviously don't need portability.

Re: www.google.com – The page is blank when accessed

#292

Post by Kharacternyk »

stephenr wrote: post #281
sangnoir wrote: post #270

Earlier quoted context omitted.

> 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.

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#Option...

Thank you for the link. I had no idea about most of the optional tags. It looks ugly when taken to extremes, though.

Re: www.google.com – The page is blank when accessed

#293

Post by stuaxo »

kramerger wrote: post #35

Key part ( from https://github.com/webcompat/web-bugs/issues/131916#issuecom... ) "This is entirely server-side UA sniffing going wrong. You get an empty HTML doc, only a doctype, with a Firefox Android UA. You can reproduce this with curl, $ curl -H "User-Agent: Mozilla/5.0 (Android 10; Mobile; rv:123.0) Gecko/123.0 Firefox/123.0" https://www.google.com % and it seems that this affects all UA strings with versions >…

I was seeing this on Gmail on Linux Firefox about a couple of weeks ago for a week.

Re: www.google.com – The page is blank when accessed

#294

Post by shadowgovt »

Thorrez wrote: post #282
shadowgovt wrote: post #232

Earlier quoted context omitted.

If it were Chrome, it'd never have gotten out the door because the developers writing the feature use Chrome. > if you break something in production, roll back first, ask questions about how it happened later, even if you think it's a simple fix I don't know that they have enough information on the breakage to know when to rollback to.

>the developers writing the feature use Chrome. To write the code? It was only mobile Firefox that was broken. I don't think most developers write code using mobile Chrome.

The UA for Desktop Chrome looks like

`Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36`

The UA for mobile Chrome looks like

`Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.6099.210 Mobile Safari/537.36`

There is very little here different that could twig an error in the google.com UA handler.

In contrast, the Firefox Mobile one is

`Mozilla/5.0 (Android 4.4; Mobile; rv:41.0) Gecko/41.0 Firefox/41.0`

They're the only one (I can find) with "Mobile" inside the parens; bet you money the issue is a badly-formatted regex tripping over the paren / symbol combination and thinking that UA describes some deny-listed crawler somewhere (or falls off the end of recognizable UAs and trips a fallback to "Vend nothing").

Since they're always testing on Chrome Desktop, and Chrome Mobile emits an almost-identical UA string, my previous statement holds: issues with Chrome mobile are generally more likely to come up in testing on Chrome Desktop than issues in Firefox Mobile are likely to come up in testing on Chrome Desktop.

Re: www.google.com – The page is blank when accessed

#295

Post by nolok »

kedean wrote: post #290
cuddlyogre wrote: post #283

Earlier quoted context omitted.

We're also back to table layouts with grid, albeit a lot more usable this time around.

I don't recall that there was ever anything inherently wrong with using tables for layout, except that it was a misuse of tables so we were told it wasn't "semantic". Thus you had years of people asking on forums how to emulate tables using a mess of floating divs until flexbox/grid came around. In retrospect, tables are also clearly incompatible with phone screens, but that wasn't really a problem at the time.

One, it made the code unreadable and impossible to maintain properly, especially since most of those table where generated straight out of photoshop or whatever.

Two, it was an accessibility nightmare.

At least modern grid design fix those

Re: www.google.com – The page is blank when accessed

#296

Post by sangnoir »

junon wrote: post #271
sangnoir wrote: post #270

Earlier quoted context omitted.

> 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.

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.

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.

Re: www.google.com – The page is blank when accessed

#297

Post by sangnoir »

stephenr wrote: post #281
sangnoir wrote: post #270

Earlier quoted context omitted.

> 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.

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#Option...

> 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.

Re: www.google.com – The page is blank when accessed

#298

Post by sangnoir »

stephenr wrote: post #277
sangnoir wrote: post #241

Earlier quoted context omitted.

On the server-side, parsing the UA string is the best & fastest way to figure out which browser is on the other end or the connection. This can need to happen before you load any JS - this is commonly used to decide which JS bundles to load. When put under the microscope, browser have inconsistent behaviors and occasional regressions from version to version (e.g. performance with sparse arrays)

It's wild to think that everything we've collectively learned as an industry is being forgotten, just 20 years later. - We're on the verge of another browser monopoly, cheered on by developers embracing the single controlling vendor; - We already have sites declaring that they "work best in Chrome" when what they really mean is "we only bothered to test in Chrome". - People are not only using UA sniffing with inevita…

> People are not only using UA sniffing with inevitable disastrous results, they're proclaiming loudly that it's both necessary and "the best" solution.

Since you're replying to my comment and paraphrasing a sentence of mine, I'm guessing I'm "people".

I'm curious to hear from you on what - if any - is a better alternative that can be used to determine the browser identity or characteristics (implied by name and version) on the server side? "Do not detect the browser on the server side" is not a valid answer; and suggests to me the person proffering it as an answer isn't familiar with large-scale development of performant web-apps or websites for heterogenous browsers. A lot of browser inconsistencies have to be papered over (e.g. with polyfills or alternative algorithms implementations), without shipping unnecessary code to browsers that don't need the additional code. If you have a technique faster and/or better that UA sniffing on the server side, I'll be happy to learn from you.

"Do feature JavaScript feature detection on the client" is terrible for performance if you're using it to dynamically load scripts on the critical path.

Re: www.google.com – The page is blank when accessed

#299

Post by pests »

oblio wrote: post #280
pests wrote: post #265

Earlier quoted context omitted.

Their own maps apparently?

Yeah, but based on what info?

Some fanboy probably heard Elon misspeak 3 years ago and the rumor mill has been going. Who the hell knows, nothing from what I can tell.

Re: www.google.com – The page is blank when accessed

#300

Post by stephenr »

sangnoir wrote: post #297
stephenr wrote: post #281

Earlier quoted context omitted.

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#Option...

> 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 hom…

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.

Post reply on HN