<i>JavaScript is an assembly language.</i><p>Uh, no. Not at all. Not even close. This is a ridiculous premise, and can't possibly be taken as a supporting argument for ANYTHING.<p>Also - Has the author not heard of compression? Especially since Google uses that as a site metric for rankings?<p>There is no need to "tighten up"* a page if the output is going to be compressed before transmission to the client.<p>* This assumes sane markup
Yet another thing that Hanselman and I disagree on.<p>The problem is not HTML/JS minification. Everyone agrees that's a good thing, even though it effectively breaks "view source".<p>No, the problem I have is that he uses this to defend WebForms and the ViewState. Google has its own "WebForms" in the form of GWT, but that doesn't make WebForms any more OK. The problem with WebForms was that it was too far of an abstraction from the underlying HTML and Javascript underneath that developers spent more time working <i>around</i> WebForms than with it. That hurts the developer. The garbage that WebForms produces is not the same thing as minified HTML and Javascript, especially since the ViewState can bog down each request with extra data if you're not careful. Post backs aren't free in ASP.NET using WebForms and the ViewState. Regular HTML is not hard to develop for or debug, but WebForms makes it difficult enough to require a debugger. With regular HTML, you can develop with plain text and publish minified text so "view source" isn't broken during development.
I've never used GWT but there are three things that I spend a lot of time dealing with in my day job:<p>1. WebForms controls mess with the markup that is output, this used to be a real nightmare in v1 with tables being inserted everywhere. It's better now but you still don't _know_ what IDs you're going to get and there are still issues like the GridView doesn't output thead rows in the table unless you set certain properties explicitly. All this makes using ASP.NET with third party CSS and JavaScript tools hard because They often rely on markup being defined a particular way<p>2. ViewState is on by default and posted back to the server every time the page posts back. Most people have slower updoad speeds ti download speeds, so this causes real issues. The whole design of WebForms assumes that every control will be setup once on initial page load and then rebuilt from ViewState each time after that, whereas usually each postback only requires some of the page state to be posted back and a few controls to be rebuilt. Some sort of ViewState group would be useful to tell the page "if the user clicks that button, then these fields are needed at the server end and these other controls will be rebuilt. This would be virtually impossible to retro-fit into WebForms though.<p>3. UpdatePanels are a performance nightmare and still post back the entire page, usually they are only needed to update 2 or 3 of the controls on the page and a page method would be far more efficient, but UpdatePanels are just so darn convenient (especially given point 1) that they get over used.<p>Some abstractions are really nice and I totally don't care what happens beneath them, but WebForms is not one of them. Markup matters, IDs matter, upload bandwith matters. WebForms abstracted the stuff I care about and made bad some bad assumptions too.
When I was learning web dev I cared since it's a useful way to learn.<p>Now it's not that I care what my View Source looks like, it's that I care what my Source looks like. If big sites want an extra compile step before publishing that minimizes/compresses/optimizes/assemblies my nice-looking source, I don't really care. (And if your stuff is actually under an open source license I hope it's readable somewhere.) I just happen to not do that so my default non-caring state is a less-work state, my view source looks the same as my source (at least once a template is done populating).<p>I don't buy the "JS is the assembly of the web" line. If that's true, JS is a crap language for being an assembly. Have W3C make a standard for a language that would be a better assembly than JS and have JS compile to that. (Perhaps after the current set of browser wars dies down and a clear winner of a JS engine can be determined.)
The "end result" approach with a diminished focus on clean markup doesn't make sense. The "end result" is not going to be the same for every user - for starters, people use different clients, and not everyone is sighted.<p>Of course, this is also based on the premise that code is bad because it's not human readable when it reaches the browser. Maybe I'm getting hung up on the details when it seems like the article was written only to defend the use of WebForms.
the standards have changed. instead of viewing source looking to find a clean and concise markup, you now look for some minified and mangled source. if you dont find either, condemn that site to hell.