4 ms·

Storing Javascript in comment tags and later eval'ing it

28 points by derwiki 17y ago

chime 17y ago
Any idea why Chrome>String is such an outlier? I would have imagined quite the opposite from Chrome actually.
- gills 17y ago
  I thought Chrome kept [compiled] common js locally? I could be wrong. But it would seem explain some of the difference.
  - dutchflyboy 17y 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 17y 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-javascript-load-time-90-with-deferred http://blog.sproutcore.com/post/272853740/cut-your-javascrip...
DrJokepu 17y 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 17y 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.
  - DrJokepu 17y 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.
- aristus 17y 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.
  - dutchflyboy 17y 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.
    - aristus 17y ago
      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.

28 points by derwiki 17y ago

chime 17y ago

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

gills 17y ago
I thought Chrome kept [compiled] common js locally? I could be wrong. But it would seem explain some of the difference.
- dutchflyboy 17y 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 17y 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-javascript-load-time-90-with-deferred http://blog.sproutcore.com/post/272853740/cut-your-javascrip...

DrJokepu 17y 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 17y 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.
- DrJokepu 17y 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.
aristus 17y 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.
- dutchflyboy 17y 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.
  - aristus 17y ago
    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.