Storing Javascript in comment tags and later eval'ing it

http://www.stevesouders.com/blog/2009/12/07/downloading-javascript-as-strings/

by derwiki • 17 years ago

28 16 17 years ago

stevesouders.com

chime• 17 years ago

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

gills• 17 years ago

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

dutchflyboy2• 17 years ago

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.

judofyr• 17 years ago

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

DrJokepu2• 17 years ago

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.

derwiki• 17 years ago

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.

DrJokepu2• 17 years ago

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.

aristus2• 17 years ago

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.

dutchflyboy2• 17 years ago

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.

geuis• 17 years ago

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.

stan_rogers2• 17 years ago

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.

gvb• 17 years ago

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

Storing Javascript in comment tags and later eval'ing it

Related Stories