

Why do you care what View Source looks like? - brianwillis
http://www.hanselman.com/blog/JavaScriptIsAssemblyLanguageForTheWebSematicMarkupIsDeadCleanVsMachinecodedHTML.aspx

======
sc68cal
_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

~~~
tzs
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.

~~~
sc68cal
There is nothing like hard numbers. Thanks!

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

~~~
arctangent
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...

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

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

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

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

