Thursday, December 3rd, 2009
The End of Days for “View Source”?
“View Source is your friend”, we’ve learned countless times as web developers. It’s something special about web development that we can seamlessly lift the covers on anything we see and find out how the sausage is made. And it gets even better with great tools to interrogate the system in real-time. This capability has helped us evolve practices and patterns, and contributed to the production of many a fine browser extension and Greasemonkey script.
Our friend might sadly be going the way of the blink tag. View Source has always worked because the standard development model is to put up some static Javascript files on a server somewhere and serve them out. That model is changing though; performance is a very hot topic right now, and View Source is playing victim to that trend.
Google’s Let’s Make the Web Faster initiative is a case in point. Here is a multi-pronged attack on the performance issue, involving new protocols (SPDY), tools (PageSpeed), browser improvements (Chrome), on-demand loading (Closure), and – most pertinent – compression techniques (Closure again). And we ain’t seen nothing yet; there’s every reason to believe Google will soon be putting its money where its mouth is, by rewarding faster sites with higher rankings. (I guess I was alone in assuming they always did that.) While performance should always be a consideration for site owners, a dangling SEO carrot would no doubt convert the best of intentions into the most concrete of actions.
Site owners can’t (much) control factors such as browser choice and browser efficiency, but they can get their own performance-fu in order, and code compression is low-hanging fruit. Looking at the top 20-ranked sites, filtering only English-language sites, I found the very top guys (Google, Facebook, Yahoo, YouTube, Windows Live) predominately using Javascript compression, with the others not using it much, if at all. I expect most of them to be using it in the next 12-24 months.
In addition to compression, there is also obfuscation. With Javascript being used for more complex tasks and replacing desktop functionality, more companies will be wondering about all that intellectual property sitting in plain view. (And let’s not mention the security-by-obscurity fans, who will also go this route, however flawed their thinking.)
Is it all bad? No. There’s a much healthier respect for plain old semantic HTML these days, which means HTML documents should be View Sourcier now than ever before. (CSS, not so much, with compression also likely to grow.) If I had to choose between one or the other, I’d take clear HTML over clear Javascript. Also, we will probably find the majority of sites in the long tail won’t feel the need to do anything about their code (but the ones who do make efforts are probably the ones with the most interesting things to look at). Also, the aforementioned tools, which do things like XHR sniffing, will help us to understand from a “black box” perspective even if we can’t peer into the code. Hopefully, there will also be more attention paid towards Javascript beautifiers as well, to make sense of compressed code.
I can’t speculate on the waning of View Source without mentioning the tremendous counter-balancing act played out by Open Source. From the get-go, open source has played a vital role in Ajax, with individuals and companies releasing code for all sorts of reasons. Most of this is library and framework code, rather than production-ready applications, so we might lose something there, but we still have much to gain from the ever-growing corpus of code that’s out there, free to be studied and incorporated into our own applications.
I don’t see “View Source” going away any time soon, as static code/markup is still absolutely critical for content. That said, Firebug’s “Net” tab and resource panel in Safari etc. are of increasing usefulness given the growing number of requests made via JS for JS, and via XHR.
JS obfuscation is generally ineffective, typically reserved for viruses and exploits, and given DOM inspectors, code prettifiers and JS debugging tools, developers can still unravel what any script is ultimately doing as it runs.
I truly hope this is not the case—the web exists because of view source. And as Schill said, with Firebug and the Web Inspector we are getting everything decoded and prettified for us anyways.
I completely disagree with those companies who believe that obscuring their code is a good way to go. Yes, intellectual property is important but there is a certain level of openness about the web and we cannot abandon that.
I have to agree with Thomas. We all got here (including Google’s applications) by standing on the shoulders of giants and learning for the newest tips and tricks of the day. I think that a universal adoption of these tactics would result in a serious slow-down in innovative web development techniques from almost all sources outside of companies like Google. I’d find it difficult to explain the philosophical differences between Closure and Java Applets, for example.
Personally, I would have loved for openness and transparency to be another goal of projects like Closure. Speed is important but it’s not the only important factor. While those projects seem to be driven solely by performance, I find myself curious but still reluctant to adopt them. I’m still viewing source on many other sites looking for the next big thing…
Someone on the CommonJS Google Group the other day suggested using an X-ViewSource http header for a pointer to the source for server-side js apps. Perhaps a similar convention could be adopted for sites with compressed/obfuscated js.
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.
@smith – That is a GREAT idea.
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.
Interesting opinion. However I do not so well understand English, therefore I want to ask again – it is necessary to prefer JavaScript or HTML?
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.
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.
Just add a new attribute to the script tag: VIEW
[script src='minified.js' view='complete.js' /]
simple, easy, compliant
Problem solved: http://jsbeautifier.org/
@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.
@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.
@jx12345
Ok, you got me there.
How about separating urls with commas or pipes?
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?
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.
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.
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?
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.
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/
@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.
areinsufficient wow goldfunds in maplestory mesosthe great wow gold sellersvaults of aion goldopportunity
of thisnation. so we have shanghai massagecome buying wow goldto cash this check — a check that willgive us upon demand the riches of freedom
View Source is something that developers will have to explicitly support in the future.
I had to do this when I created World of Solitaire
I compress all my JavaScript files into a single file and compress it. Clearly this is useless for developers wanting to View Source and learn.
So I have as HTML comments in the source a note to developers that if they want the un-compressed, un-obfuscated version, they can visit a special URL that will give them that version (the same version I use when I need to debug in Firebug, etc).
This seems like a good compromise to me :)
‘View Source’ isn’t going anywhere.
Antunes sometimes Ed Hardy Hoodies Sale have Ed Hardy T Shirts Sale to fight Ed Hardy Swimwear Sale to get Ed Hardy hats Sale them That Ed Hardy caps Sale fight is Ed Hardy Kids Sale especially difficult Ed Hardy Sunglasses Sale when the Ed Hardy Bags Sale decision to Ed Hardy SPECIALS Sale perform a Ed Hardy Belts Sale Caesarean Tiffany and co Bangle is made Tiffany and co Pendant in the Tiffany and co Necklace delivery Tiffany and co Earring room when Tiffany and co Ring theres Tiffany and co Cuff Link often not Tiffany and co Key Ring much time Tiffany and co Set to talk Links of London Bracelets Sale and consider Links of London Necklaces Sale all the Links of London Earrings Sale options a Links of London Rings Sale tough situation Links of London Chain Sale says Dr Bruce Links of London Pendants Sale Flamm a spokesman links of london sweetie Sale for the links of london heart charms Sale American College
Not that long ago Ed Hardy in a galaxy not that far away Ed Hardy Clothing we released an update Links London jewellery to Pharos IV Assault Ed Hardy Clothing sale This updates unleashes computer Cheap Ed Hardy Clothing assisted torpedo targeting Ed Hardy Clothing Sale for greater accuracy Cheap Ed Hardy resumption from highest level attained Links London no more starting over from level Ed Hardy Sale and fixed the stutter Discount Ed Hardy Clothing issue that affected iPhone Cheap Tiffany users Update is Tiffany and co for both iPhone Cheap Tiffany Jewelry Bartow Florida Cheap Tiffany and co After more than Links of London jewellery three decades in prison Tiffany and co UK a Florida man was set free Tiffany and co Jewelry Thursday after a DNA test showed he did not kidnap and rape a Tiffany and co sale year-old boy in 1974 Cheap Links of London jewellery I m not angry James Bain Tiffany told reporters after a brief hearing in Bartow Florida Tiffany Co Bain was 19 when he was convicted Tiffany sale on charges of kidnapping Links of London burglary and strong-arm rape Links of London jewelry He received a life sentence cheap Links of London He s going home for the Tiffany Jewelry first time in 35 years Links of London sale I got God in my head Tiffanys said Bain Tiffany Jewellery surrounded by supporters and wearing a Links of London UK T shirt with Not Guilty Tiffany UK across the front Discount Links of London .
excellent
thanks
Buy KamagraEarn GoogleM65 JacketViagra CialisCheap KamagraCheap ViagraCheap CialisMake Money on GoogleM65 Field JacketAirline Dog CarrierAirline Dog CarriersViagra CialisEarn GoogleAirline Dog CarrierAirline Dog CarriersAirline Approved Dog CarriersED Hardy WholesaleCopy DVD SoftwareHow to Send Fax14k Yellow GoldRedneck Costume14k Gold HeartTandem Baby Stroller
Pass4sure, a professional training website in IT certification exam, is designed for IT candidates who want to pass any IT exams. With its high quality products and 24*7 considerable services, Pass4sure has strengthened its leading position in this field, and attracted many famous vendors like Cisco, Microsoft, IBM, Sun, compTIA, HP, etc.The Most Popular exams List :642-971640-822 646-046 156-215.65 PMI-001 642-845 642-524 PK0-002 642-661 642-591 646-656 350-030156-315.65 HP0-S21 642-892 PMI-001 646-204 650-621 1Z0-053 156-215.65 642-691 350-040 640-802 Click Pass For Sure to get more information!
If you’re interested in obtaining more product information, customer reviews, and where to find the lowest prices on this model of HDTV Plasma TVs, then just visit this : hdtv plasma tvs – hdtv tvs – lcd hdtv tvs – samsung tv plasma – toshiba plasma tv – panasonic tv plasma – lg tv plasma – sharp aquos hdtv – sony lcd hdtv – visio lcd – visio lcd hdtv
The level cap in the next Aion Kinah will be slightly lower than expected this time around 85.
This suggests Aion Gold wants more Aion account for expansions before hitting the Aion Accounts. With less Sell aion accounts to do (along with the revamped leveling listed below likely to increase the Aion gold and ease of Aion Kinah), leveling a new race remains appealing for new and existing players alike.
Leveling from 80-85 should be a much bigger Aion Gold, the idea is to make sure that gaining a level really means cheapest wow gold and doesn’t make you feel like you just have 4 more Aion Kinah to go.