Storing Javascript in comment tags and later eval'ing it | Hacker News Reader

Storing Javascript in comment tags and later eval'ing it

stevesouders.com

28 pointsderwiki16 comments

This is pure evil. I don't like it. Even if it works and it's fast and conceived by the ultra-smart people at Google, it is evil. Definitely sets off my "WTF" alarm. Storing code in comments and then later retrieving it for execution, what could possibly go wrong?

For example, there are ISPs (T-Mobile UK, I'm looking at you) that strip off any comments from HTML, as a compression measure. Now I don't think that's a good idea but it is a very widespread practice at 3G/GPRS ISPs and definitely breaks this "code in comments" thing, especially since this whole thing was designed with mobile devices in the mind.

Do you have any links that validates these claims? This is the first I've heard of it, but I'd definitely avoid any ISPs that don't deliver me the page as the site intended it.

Well, other than it making my browsing experience a hell any time I'm forced to tether 3G off my phone, no, unfortunately not. The T-Mobile UK web proxy messes a lot with the HTML transferred, very often breaking the style sheets as well. The only 'defence' is using HTTPS whenever I can as they can't mess with encrypted data. It's a first-hand experience but if you're really interested I'd be glad to make a comparison of the HTML I get from any arbitrary site with and without T-Mobile.

I know O2 in the UK does something similar but as I'm not an O2 customer I can't check it.

If comments are a problem you can use a display:none textarea or a dozen other things. The important bit is that steve has found another way to decouple the HTTP loading from the Javascript engine parsing/loading. That's a fairly significant result.

If something goes wrong it's probably fixable / avoidable. This kind of extreme tuning may not for everyone but a 100msec saved is a happier user.

I was just wondering, why can't you start an async xmlhttprequest at the onload event? It won't start the parsing until you tell it to, it won't block the loading of the UI and it's not as obscure as using eval on comments.

In very high latency situations new connections are too expensive. Say you have 300msecs packet latency, which is common in mobile. That means in worst case, that XHR will take at least one second just to the DNS lookup and establish the TCP connection to start downloading the file.

It's not the volts, it's the amps that kill you. So to speak.

If this is something you're experiencing, it speaks to the fact that your mobile isp needs to stop filtering content. The ISP should not be doing anything that modifies the data that you're downloading. Your complaint hints that T-mobile's UK customers should petition them to stop doing what you describe.

Strictly speaking, though, comments aren't part of the HTML document -- the tagging pair < + ! indicates that you are stepping out of the HTML document to provide SGML content, in this case, a comment about the HTML document. Yes, that is splitting hairs, but the point of the SGML markup is to signal to the user agent how documents and document particles should be handled (the doctype is an example of this), and the SGML comment tag is a "do not process this particle" handling instruction. It really shouldn't be accessible to the user agent at all.

It should be noted that there's already a precedent for comments having real meaning: IE's conditional comments, which many sites use to apply different stylesheets to IE users.

When did "IE does it" become indicative of standard, expected behaviour? Just askin'.

I agree that their decisions are often a good indication of what not to do, but from a practical perspective it is a good example of why page rewriting needs to be done cautiously, if it must be done at all.

+1 evil.

After spending years telling us not to use eval() to execute raw JSON, now we are suppose to eval() comments? As noted with JSON, theoretically it can be used safely, but it is a wide open window of vulnerability for people "just trying to get it done", i.e. 97% of the web sites out there.

http://en.wikipedia.org/wiki/JSON#Security_issues

"The eval technique is subject to security vulnerabilities if the data and the entire JavaScript environment is not within the control of a single trusted source. If the data is itself not trusted, for example, it may be subject to malicious JavaScript code injection attacks; unless some additional means is used to validate the data first."

(My emphasis on entire JavaScript environment.)

Any idea why Chrome>String is such an outlier? I would have imagined quite the opposite from Chrome actually.

I thought Chrome kept [compiled] common js locally? I could be wrong. But it would seem explain some of the difference.

Yes, probably. That's why this sort of performance tests should only be done with an empty cache. Otherwise it isn't a fair comparison.

That said, Chrome is ridiculously fast at loading scripts. In absolute time, Chrome took an average of 12 milliseconds to load jQuery in the baseline test. The next closest was WebKit with 36 milliseconds. In the “string” test, Chrome takes about 50 msec compared to WebKit’s 45 msec.

http://blog.sproutcore.com/post/272853740/cut-your-javascrip...

Reply on news.ycombinator.com