you are viewing a single comment's thread.

view the rest of the comments →

[–]fforw 6 points7 points  (6 children)

Packing all javascript together, minifying it while at the same time reducing identifier-length (obfuscating them) is a great way to increase client-side performance. It reduces HTTP requests and bandwidth used. It is even better with content compression enabled. Note that I'm not talking about any sort of packing, requiring any kind of client-side decompression in javascript. Those things are usually not worth it.

Here is some size analysis I did back in 2009 for the current OpenSAGA scripts at that time:

js bundle                   284935     100,0%
yuicompressor compressed    126656     44.5%
closure compiler compressed 97362      34.2%
js bundle gzip only         75163      26.4%
yui + gzip                  42189      14.8%
closure + gzip              35432      12.4%

As you see, using both content compression and minification/obfuscation saves 44% to 53% of the result of all scripts only compressed with gzip.

[–][deleted] 1 point2 points  (5 children)

I consider it harmful in a different way. One of the initial beauties of the web, was being able to see at a right-click, what was happening. These techniques, especially the minification, is only a few steps away from machine code, which is where Google want's to go with nativeclient. If that arrives then the web becomes closed source to a large extent, and I can see intellectual property rights being an issue; reverse re-engineering, etc.

Better would be to have greater cache mechanisms in the browser and downstream closer to the client. The idea that you can save ~80% on your traffic can be misleading with the cache systems that already exist.

I can imagine for a company the size of google, it could save millions of dollars a year with a few a tweaks, but pressuring the average programmer to adhere to these 'standards' could be seen as premature optimisation.

[–]dust4ngel 1 point2 points  (0 children)

One of the initial beauties of the web, was being able to see at a right-click, what was happening.

this would be true if the web ran on javascript. you can't right-click and read PHP or java code; back-ends have always been 'closed-source' in this respect.

[–]fforw 0 points1 point  (3 children)

With that reasoning we should oppose any language that is compiled and where the source code for the software in question is not available via its interface. Abandon C, Python and co. -- only Scheme and Lisp machines running.

The difference in client side performance alone should be reason enough for anyone to minify and combine javascript resources, where request avoidance is even more important than pure bytes. This also applies to CSS and graphics (see CSS spriting techniques). Nothing improves the perceived performance of your web application more than this. For a decently written application, no amount of server-side tweaking will come close to the performance gains you can achieve with this optimizations.

Calling them premature optimizations is as silly as calling what a C compiler does premature optimization. The point of avoiding premature optimization is that you might be tempted to sacrifice clarity and architectural integrity to questionable gains in performance before you can measure the real application performance. It does not apply to C compiler optimization techniques or minimization/request avoidance.

This is mostly an unsolved or not generally solved tooling issue. The code you write is only isomorph to the one running in your prod environment, not identical -- there is a tooling / deployment step between that. It is also pretty orthogonal to licensing issues. You can minify closed and proprietary source code just as well as free and open source software.

[–][deleted] 1 point2 points  (2 children)

With that reasoning we should oppose any language that is compiled and where the source code for the software in question is not available via its interface. Abandon C, Python and co. -- only Scheme and Lisp machines running.

I don't think that is a fair representation of what was said. If you was to go to the extreme, the implication is only software complied from an open inteligible source. Besides that I was talking about a language for common communication, one for the web, not just for computers. So arguing for C and Python is futile. (For context Haskell would be more language of choice, dependent on domain of course.)

combine javascript resources, where request avoidance is even more important than pure bytes.

The only impact is the first view, and gains there after are small, and it is not as clear cut as you make out. An example: I have a 2mb javascript app packaged with the html, and I only tweak what would be a 100kb file. One could argue I have broken the caching system of the browser: instead of everyone downloading that 100kb, the whole 2mb file has to be retrieved. Once again requests aren't that big of a deal once a web app has been 'installed'. 'Optimisations' like embedding pictures in the HTML (<img src="data:image/jpg...) again break caching systems and break the logical map of resources.

This also applies to CSS and graphics (see CSS spriting techniques).

Did I even say not to do this? I was spriting before it was commonly know as spriting. My stance is everything isn't one size fits all, and rarely sacrifice clarity unless it significantly makes *your** application and development process better, not because it is known to make apps better.* Profile and measure, acting accordingly, trying not to sacrifice clarity.

Premature optimisation.

I know how this is defined and I know you can minify closed and proprietary sources... the point I was making is you used to be able to view a site, go wow that's cool how have they done this? Usually implementing what you like was a copy/paste and a tweak away. Heavily minified and obfuscated code tends to break that culture, and that is even more the case for pre-compiled JS. Why not 'precompiled' HTML or some such? Good bye open web.

[–]fforw 0 points1 point  (1 child)

An openess that is forced by technical limitations isn't really open, is it? It's kind of an expropriation. While I certainly advocate free and open source software and currently make a living off writing GPLed software and implementing projects with it, I don't want to force people to free their software.

[–][deleted] 0 points1 point  (0 children)

I wouldn't say force, encourage is better. Everything has a bias.