Why do you care what View Source looks like? | Hacker News Reader

Why do you care what View Source looks like?

hanselman.com

16 pointsbrianwillis11 comments

JavaScript is an assembly language.

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.

Also - Has the author not heard of compression? Especially since Google uses that as a site metric for rankings?

There is no need to "tighten up"* a page if the output is going to be compressed before transmission to the client.

* This assumes sane markup

I find your comment on "tightening up" before page compression interesting as I'd never heard that logic before, not discounting it though. Does doing minification before compression schemes such as mod_gzip or mod_deflate really not make much of a difference? I'd be interested in seeing a side by side comparison when put in this context.

The simplest and biggest space saver that minification does is remove excess whitespace and newlines. Compression schemes do the exact same thing, as well as compress all the other characters used in the source.

Yes, the browser will have to decompress and the whitespaces will be included in the parsing step for the javascript engine, but at this point we're deep in the weeds. The biggest driver of speed for web pages is the network.

I tested this with jQuery:

   236k  jQuery not minified, not compressed
    91k  jQuery minified, not compressed
    68k  jQuery not minified, compressed with gzip
    32k  jQuery minified, compressed with gzip

Looks like minifying is still a substantial savings, even if it is going to be send compressed.

There is nothing like hard numbers. Thanks!

Yet another thing that Hanselman and I disagree on.

The problem is not HTML/JS minification. Everyone agrees that's a good thing, even though it effectively breaks "view source".

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 around 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 don't know ASP.net all that well since I'm the open source skunkworks guy in my organisation. But sometime I look at applications produced by our ICT department and I notice that they carry a whole load of crap in this ViewState thing. I'm only vaguely aware of what it does, which is apparently more than ICT do because lots of weird behaviour happens when you use the back button in the browser.

Coming back to the actual point: I don't care what your source code looks like when it's sent to my browser. Presumably the developer features of modern browsers should be able to show/export a cleaned up version of the source? I've never checked since I only look at my own pages, which are of course beautifully indented...

I've never used GWT but there are three things that I spend a lot of time dealing with in my day job:

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

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.

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.

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.

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).

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.

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.

Reply on news.ycombinator.com