4 ms·
Script injection via document.write is bad practice of course, but I'm not sure what Google's rationale is for making this backwards-incompatible move. "Your s
by kijin 10y ago
Script injection via document.write is bad practice of course, but I'm not sure what Google's rationale is for making this backwards-incompatible move.
"Your site is slow, so we'll break your functionality. There you go, isn't it faster?"
It's not the browser's fault that a badly written page loads slowly. Has the speed competition become so important that browser vendors would rather load a non-functional page than a slow page?
- dumbmatter 10y agoI would guess that they tested how many sites it would break and found that mostly it just broke ads. And even better, probably mostly non-Google ads. That's certainly the only document.write code I've deployed in recent years.
- kinlan 10y agoThere is also some more information here: https://iabtechlab.com/blog/how-to-document-write-better-user-experience/ https://iabtechlab.com/blog/how-to-document-write-better-use...
- numbsafari 10y agoWell, it seems that publishers would prefer working page over a slow page. If all the education efforts about doing the "right thing" aren't working, then take away the bad thing. I bet a lot of publishers will fix their pages, and as consumers we'all benefit, even if there's some short term pain. It's not like the fix is particularly difficult.
- megous 10y agoYou assume this technique is always bad. It is not. It is a simple way to load scripts from JS with browser forcing serialization of the script exectution. It should be developer's decision to choose whether he prefers speed or simplicity in a given context.
- pjc50 10y agoPages with adblockers might be considered "nonfunctional" by the author but perfectly fine according to the user. I've long since null-routed google analytics, which speeds up almost all page loads. Graceful degradation works well enough that you can usually get what you want from a web page even if some of the JS is broken.
- zeveb 10y ago> "Your site is slow, so we'll break your functionality. There you go, isn't it faster?" If your site is unfunctional without JavaScript, it is already broken. If you use JavaScript for progressive enhancement, then not loading scripts on a slow connexion is a great idea.
- kijin 10y agoI think that's for the author and/or user to decide, not the browser.
- zeveb 10y agoThe browser is the user agent: literally, it's the user's agent. If he doesn't wish it to do something, he can configure it to do something else, or he can fire it and get a different agent. And no, it's not for a web site author to decide to require JavaScript when his functionality doesn't require it: if he does that, he's simply wrong.
- Spivak 10y ago> it's the user's agent I completely agree, but if I configure my agent to break some assumption you made in your code then I have no one but myself to blame. One can break just about any piece of software by messing with the environment in which it runs. It's a shame that we rarely check or document these kinds of dependencies.
- pdkl95 10y agoYou are, of course, free to make assumptions about the user agent and make your page break on some user agents, but that's very unprofessional and gives a bad first impression. Progressive enhancement isn't hard if you design the page right, so most people will get the fancier site while at least having a working minimal page in other cases. This is really just checking for capabilities before using them and checking return values for errors, which everybody should be doing anyway. Assuming JS (or any browser feature) is available is similar to skipping the check for NULL after calling fopen(3). Skipping error handling is an indicator of shoddy programming.