Hacker News Reader

Comment by andy_ppp | Hacker News Reader

I wish browser vendors would make stand at this point and say in 1 year all major browser engines will stop supporting document.write - it's horrible for developers to use and no-one I know advocates it - but I'm fairly sure ad networks still use it for no reason whatsoever.

The implementation of browsers is already difficult enough! It's great to see the lengths Servo is going to to be compatible, but on this one I say warn developers and deprecate this feature that no-one in 2017 should ever use.

View on HN

Unfortunately the reality is that a double digit percentage of all sites rely on document.write [1]. Whilst it's true that a lot of usage is advertising, it's also used for functionality in sites like Google Docs. Perhaps with a lot of work you could get the usage down to single-digit percentage figures, but disabling it entirely is going to break an awful lot of sites that are unmaintained. For something like NPAPI, where there is a real ongoing cost of support, breaking old content — with a multi year timeline for migration — might be worthwhile, but I think it's hard to make the case that document.write is in the same category. Yes, it's an old and terrible API that causes layering violations, makes writing scripted parsers much harder, and ideally authors would avoid it. But making it go away would be a huge project with relatively low payoff compared to other possible uses of the same effort.

[1] https://discuss.httparchive.org/t/how-and-where-is-document-...

In case anyone else was curious about precisely what those numbers measured, I just confirmed that Lighthouse only reports the no-document-write violation when the page actually calls it so those numbers aren't high due to the sites which still have fallbacks left from the paleolithic-era Web (I'd seen that with Adobe Analytics/Omniture where the tracking code injection had a fallback path for Netscape 2/IE3 until very recently).

Okay sure, but I’m pretty certain about 50% of those site have ads on them. Getting rid of Flash was a much bigger issue but Apple forced it through with iOS and it immeasurably improved the experience (at least for those platformsand largely for everyone). Removing document.write improves page performance as well as browser engines. Everything document.write involves can and should be done in other ways, putting document.write behind a Site X wants to allow legacy Javascript do you wish to continue? Clicking no and the ads don’t load would not be a terrible situation.

Maybe there are other APIs that should be deprecated first but I cannot think of any.

Finally I am pretty certain you could write a document.write polyfill, I’ll have a crack at some point I think.

> it's horrible for developers to use and no-one I know advocates it

I've seen developers advocate for document.write to inject locally-hosted JavaScript as a fallback for when CDNs are down: https://www.hanselman.com/blog/CDNsFailButYourScriptsDontHav...

I definitely don't agree with this method, but there you go. Apparently ASP.NET 4.5 will even insert this pattern automatically.

You could still insert <script> elements, you just wouldn't do it with document.write().

I may be wrong, but I think that document.write() will load the script synchronously while inserting a `script` element will not.

You can set async=false on a dynamic script element to avoid the default asynchronous behaviour.

I just looked at the support matrix: IE10+. So it is reasonably supported nowadays, nice :-)

Working on the web is refreshing like that these days — so many things which used to be painful are now just standards + “Microsoft doesn't support that old version of IE and neither do we”.

If only someone introduced document format which disables document.write like https://www.w3.org/MarkUp/2004/xhtml-faq#docwrite ... one can only dream how wonderful life would be fifteen years later

> The implementation of browsers is already difficult enough!

Clearly. I would go further and say that we should move all parsing and rendering into the browser's "user space". That way, browser vendors can concentrate on a simple set of primitives, and improve security, robustness, and compatibility, while users get more freedom and flexibility.

A rendering engine written in Javascript? Actually more possible with WebAssembly I suppose, but I’d worry about user space browser leaking information.

https://www.smashingmagazine.com/2016/03/houdini-maybe-the-m...

though I don't know what has became of that project

It's happening, slowly. CSS Typed OM should be shipping soonish (it essentially provides a new object-model around CSS which doesn't just treat everything as opaque strings like CSSOM does), the other parts are still fairly early-stage work.

Reply on news.ycombinator.com