Comments on: The End of Days for “View Source”?

By: Aphrodisiac

Aphrodisiac — Fri, 15 Jan 2010 11:50:01 +0000

excellent
thanks

By: Gavin

Gavin — Mon, 07 Dec 2009 22:30:11 +0000

‘View Source’ isn’t going anywhere.

By: jgw

jgw — Sun, 06 Dec 2009 23:06:12 +0000

@guix69: that article is full of pointless vitriol and many of its optimizations have been refuted elsewhere (check the comments). At the least, it has nothing useful to say on the topic at hand.

By: guix69

guix69 — Fri, 04 Dec 2009 16:48:49 +0000

Talking about Closure. For those who haven’t read that :
http://www.sitepoint.com/blogs/2009/11/12/google-closure-how-not-to-write-javascript/

By: abickford

abickford — Fri, 04 Dec 2009 15:35:32 +0000

I use GWT and by default the compiler obfuscates and minimises the output for performance reasons. As jx12345 pointed out, there isn’t a ‘pretty’ version to link. In my case, you’d get the precompiled Java source code anyway, which probably isn’t all that useful.
.
Sure, i could GWT compile a ‘pretty’ version, but why go through that extra work and maintenance? I deliver apps to add value to my company and that are as performant as possible for my end users, not to educate other web developers. There is certainly a time and place for that, but production apps aren’t it.

By: GBUK

GBUK — Fri, 04 Dec 2009 15:20:19 +0000

Am I the only one to find it disturbing that Google might favour big sites in their result just because they are more performant? Those are already the ones who have the money and time to spend on SEO in the first place, who have a need for performance because Google probably brings them loads of visitors already and also have the time and money to really squeeze performance out of their pages… what about the little guys? I think it is more than time that someone builds a search engine that considers content value over accessory indicators like performance or number of inward links! Semantic web anyone?

By: genericallyloud

genericallyloud — Fri, 04 Dec 2009 05:10:42 +0000

I don’t think view source is as big a deal as it used to be. Open source has come a long way since the old days. No longer is it really necessary to crack a website open to see how it works just to learn html. There are so many resources out there to share knowledge, help newbies, and build great apps quickly and easily, that I fail to see that many cases when it is really that important. Sure, there are times when I want to see why somebody else’s site doesn’t work in my browser, or to see how somebody else pulled off something cool. However, I can also see how applications that do not wish to share their source has every right to obfuscate their code in any way they please.

Let’s stop focusing on view source. That may have been an important foundation for how the open web came to be, but it is not at all the most important factor now. I say open source and open standards are far far more important than view source. I would also say that as a platform, having source based distribution over binary distribution is also key – even if the source is obfuscated in some way. Staying at the source code level is important for allowing the widest range of implementations, and the furthest reach.

By: franzsee

franzsee — Fri, 04 Dec 2009 03:52:47 +0000

First of all, obfuscation in the web is mostly for performance reasons.

Second of all, I think the major argument why ‘View Source’ will die in this article is because of all these performance tweaking which makes the source basically unreadable.

However, if you only read/heard about these performance tweaking, then that might cause for alarm for you. But if you’ve actually implemented them, you will know that there’s no way you’re going to sacrifice maintainability just to shave of a few seconds/milliseconds (who wants to code in compressed, obfuscated, & joined form?).

Most likely, you’ll figure out a way so that in your development environment, everything is ‘viewable’, but in production, things are tweaked to high performance.

By: Breton

Breton — Fri, 04 Dec 2009 03:39:33 +0000

It’s not clear to me that minification/packing gains you much over just Gzipping the source. I can understand gluing files together to reduce http overhead, but I just don’t get what your compression/obfuscation stuff is useful for. Where are the stats? If this article is to be believed, we should see the reasoning behind the big guys switching over to code compression/obfuscation, or a refutation of that reasoning if the evidence is against it. Otherwise it’s just scaremongering, and what is the point of that?

By: Ajaxerex

Ajaxerex — Fri, 04 Dec 2009 01:36:55 +0000

@jx12345

Ok, you got me there.

How about separating urls with commas or pipes?

By: jx12345

jx12345 — Fri, 04 Dec 2009 00:05:03 +0000

@Ajaxerex
But not usable. If a build mechanism that automatically glues together files and compresses them is used, then there may never be a single readable file to link to as the uncompressed version. Many uncompressed -> single compressed. You can put links to these files in your projects now if you like – no need for extra attributes. The web already has what you need.

@Schill
I agree – deliberate code obfuscation is evil. And evil sites use it. I don’t think it is the point Michael Mahemoff was trying to make in this article. He talks about legitimate code compression.

The only possible legitimate reason for obfuscation (at first glance) could be to protect some proprietary technology. If I were to protect million dollar algorithms I would not put them on the web in any shape or form. Just prepare the data on the server, make an xht request and everyone’s happy. Javascript in the browser should not be used for such code – keep that locked away.

By: Schill

Schill — Thu, 03 Dec 2009 21:30:41 +0000

@jx12345: Compression/minification via YUI compressor et al, removing whitespace and shortening local variables etc., is a different beast than obfuscation where scrambling and hiding the meaning of the code, methods and so on is the end goal.

Compression/minification (+gzip when served) is excellent, but also still leaves readable code – something I consider a good thing – when run through tools like jsbeautifier as WillPeavey mentioned, vs. obfuscation as in my prior linked virus/exploit example where it’s still very unclear as to what the code actually does.

By: WillPeavy

WillPeavy — Thu, 03 Dec 2009 20:34:58 +0000

Problem solved: http://jsbeautifier.org/

By: Ajaxerex

Ajaxerex — Thu, 03 Dec 2009 19:35:11 +0000

Just add a new attribute to the script tag: VIEW

[script src='minified.js' view='complete.js' /]

simple, easy, compliant

By: jgw

jgw — Thu, 03 Dec 2009 19:01:05 +0000

This is a natural and necessary trend, especially with things like Javascript and CSS, which, if left in their source form, can become intractably large (you can argue that they should be small, but that’s essentially an argument against dynamic applications in general). No reasonable developer uses obfuscation to “protect their code”; it’s an optimization (over the wire and at parse time) plain and simple.

Insisting on clear unobfuscated scripts is an argument that all users should pay (in time) for your desire to view the source of an application. I believe that’s a completely unreasonable insistence, and it’s never really been guaranteed anyway. What matters is sharing code and ideas (through open discussion and open source), not the “view source” mechanism for doing so.

By: jx12345

jx12345 — Thu, 03 Dec 2009 18:30:31 +0000

Schill
“JS obfuscation is generally ineffective, typically reserved for viruses and exploits” – it’s just not true. Many compression techniques modify the code in order to make it shorter. Most obvious – shorten the names of internal variables and methods, but there is a lot more – you can remove some parantheses and semicolons in certain contexts, replace repeating strings with variables etc. In my experience – js minification shaves ~30%, compression – another ~20%. The drawback is unreadable code but the gain – ~50% smaller file size.

Let’s not forget that the code is and will remain viewable – hardcore developer will be able to sift through it to find that nifty feature no matter what. Simple copy-paste – yeah, that might go. But I don’t really believe that it is widely used even now.

By: Zmicer

Zmicer — Thu, 03 Dec 2009 17:51:59 +0000

Interesting opinion. However I do not so well understand English, therefore I want to ask again – it is necessary to prefer JavaScript or HTML?

By: blepore

blepore — Thu, 03 Dec 2009 17:37:08 +0000

Since this article talked about both compression and intellectual property, where does the compromise happen for JavaScript files that are supposed to have some license code contained therein that then gets stripped out during the compression process? Right now I don’t think most people case, but you know at some point it is going to come up.

By: Malic

Malic — Thu, 03 Dec 2009 17:29:07 +0000

@smith – That is a GREAT idea.

By: nataxia

nataxia — Thu, 03 Dec 2009 17:26:51 +0000

It’s probably not a good idea to allow current leaders, possessing the inevitable monopolization mindset, to define how the interweb works. It’s a simple point: whenever you start deciding what is open or what, what is allowed and what is not, what is visible and what is not, based on the needs (read: desires) of a profit-focused corporation you have intentionally accepted the crusty end of a “bread and circuses” arrangement. Companies that obscure their code gain profit and lose connection to the community. That is their right. The community is not *wrong* for preferring, and defending, open code sharing. And to even suggest that capitulation should result in you being given a high paying job in a comfy building at this or that monopoly where your greed can be sated and your voice can be silenced.