

Google Coders Need To Go On An HTML Diet - nano81
http://www.geekypeek.com/?p=640

======
jasonkester
It's worth noting that those 400 lines are not what's sent over the wire.
Generally, you'll send something like this as a little snippet of JSON then
tear it apart on the client and construct whatever HTML you need to render it
nicely.

I suspect the author had a look in Firebug and came to the wrong conclusion.

So no, it's not bloat. It's just presentation.

~~~
msy
Just because it's only presentation doesn't mean it's not bloat. Assuming this
is a rendered JSON object that's still a ton of extra HTML elements and CSS to
render/instantiate than should be necessary to produce the same effect and
while that might not be noticeable on your top-end MBP with safari for a lot
of devices it does.

It's also just poor craftmanship, I think that's what really bugs me.

~~~
falien
It would be bloat if, as the author irresponsibly implies, all it did was
display the basic data of a single text message. In the case of that single
instance for the author it may do that (I didn't care to look that closely),
but it provides for much more to be possibly displayed, and much of that
presentation can provide extra information to a viewer (or a machine for that
matter). Also with modern javascript and html engine optimization, its not out
of the realm of possibility that generating all of this every time is faster
than only generating exactly what is required for each message.

------
daleharvey
when you work on something significantly more complicated than a run of the
mill django/rails type website, you quickly find out that a lot of the "bad
practices" you taught yourself out of, can actually be actually completely
necessary

inline styles and javascript are really really fast, innerhtml can be a lot
faster than dom methods, doing everything with fancy css selectors is a good
way to completely kill a page and destroying your markup by adding html over
the place and id='' attribute on everything, can actually be the right thing
to do.

~~~
iamelgringo
I noticed that when I first started thinking about the Css v tables debate.
Google uses a fair number of tables for layout in its designs. Noodle around
on Google's site with the web developer toolbar and Outline->Tables->Table
Cells. If you're a CSS purist, you'll be horrified. Google's front page makes
prominent use of a table for layout. The autosuggest drop down is also a
table. Gmail: tables all the time.

------
scott_s

      #include <stdio.h>
    
      int main()
      {
        printf("Hello World!");
        return 0;
      }
    

Becomes:

    
    
        .cstring
      LC0:
        .ascii "Hello World!\0"
        .text
      .globl _main
      _main:
        pushl   %ebp
        movl    %esp, %ebp
        pushl   %ebx
        subl    $20, %esp
        call    L3
      "L00000000001$pb":
      L3:
        popl    %ebx
        leal    LC0-"L00000000001$pb"(%ebx), %eax
        movl    %eax, (%esp)
        call    L_printf$stub
        movl    $0, %eax
        addl    $20, %esp
        popl    %ebx
        leave
        ret
        .section __IMPORT,__jump_table,symbol_stubs,
          self_modifying_code+pure_instructions,5
      L_printf$stub:
        .indirect_symbol _printf
        hlt ; hlt ; hlt ; hlt ; hlt
        .subsections_via_symbols
    

Look at all that bloat! I just want to write out "Hello World" to the screen.
Why do I need to create a function stack of 20 whole bytes? What a waste! And
when I do that, I have to go through the onerous effort of saving my stack
pointer to a whole 'nother register. What a waste of my system resources.

It's bad enough I have to call printf in the first place when I really could
just use the write system call, but look how it doesn't even call printf right
away! First I have to call some locally defined function which has to allocate
even _more_ space for _another_ stack. More waste and bloat. And look at how
all of this is organized, these sections are completely unnecessary. I just
want to write out something to the screen! I don't need this level of
organization and abstraction to do this simple task.

------
tumult
Who cares, if it works? I don't personally consider HTML and CSS either
elegant or efficient, so if they've abstracted over it in order to do things,
and it works, what's the big deal? HTML by hand seems mostly like a waste of
time, to me. Most of the impressive web apps don't do much markup and styling
by hand. Cappuccino/Objective-J is an extreme (and good) example of this.

~~~
mr_eel
Well personally I care about good craft and elegance. These are subjective to
be sure.

But I'm immediately suspicious of the statement "who cares if it works?". As
if any old rubbish will do. I have a pact with myself; I'll stop working with
the web if I ever gain that attitude. Nothing more depressing than a tradesman
that doesn't respect his tools.

~~~
axod
The question should be: "Will it make a difference that degrades user
experience".

If no user ever notices, who cares?

Most programmers don't use assembly language. Their code is full of redundancy
and inefficient bloat. But it's a trade off, and most people don't really mind
too much.

To many, HTML/CSS is machine code. Some love hand crafting it, some leave it
to automated 'compilers' to create it, and just like all compilers, that means
you often end up with inefficient mess.

~~~
indiejade
Compiled code is only as good as the compiler. This is why I favor the side of
hand-crafted CSS.

The biggest problem with the code example listed FtA on Geeky Peek is that it
showcases HTML tables, which are what tend make HTML most inefficient. CSS and
JavaScript can both solve the "table" problem that HTML has been plagued with.

HTML5 and CSS3 both are moving away from this deprecated "table-oriented"
formatting, fwiw.

Table-less CSS (e.g. CSS3 specs) cut down on the amount of HTML generation and
can basically cut out the bloat. Problem is it takes an _artist_ to write good
CSS.

Since "most programmers don't use assembly language" (I don't actually know if
this is true; have no reference to cite; am just quoting axod here), it would
seem analogous to hundreds of tiny band-aids where one large bandage is
needed.

~~~
axod
>> " which are what tend make HTML most inefficient."

Can you cite some numbers here. Browsers are _hugely_ optimized for displaying
tables. They have tables down to a fine art.

Do some benchmarks of a table layout vs CSS. In the rare instance where you
can actually achieve the layout using CSS, I'd expect it to run slower.

I'm not saying tables are great, use tons of them, but they have their place,
and browsers are _really_ good at coping with them.

~~~
indiejade
_Can you cite some numbers here. Browsers are hugely optimized for displaying
tables. They have tables down to a fine art._

I'm completely unqualified to be talking about this, so only to a certain
extent do I even feel like I should answer this: I have simple and mere
examples of what works on production sites I've prodded and nudged into
working.

If talking numbers / citations is the solution:

<http://www.calculae.com>

No tables, pure CSS (design) working w/ PHP (calculating as per SASS/HAML).
Not even any JavaScript. Site runs really fast. Even checked on YSlow, it runs
quicker than most tabled sites doing the same thing.

I don't have a CS background; everything I've learned has been self-taught. I
consider myself more of a CSS "artist" than a real "programmer". So YC News
_hates_ me 95 percent of the time, as I've had a hard time melding with the
"set-in-stone" terminology people here like to downmod for. However, I do
know, intuitively, why and how certain things work why and how they work. Most
of the time, I simply prefer the large bandage to the 1000+ small band-aids on
browsers. Can work both ways. :)

------
geekypeek
I'm the author, this is definitely sent over the wire as I'm building code
that is scraping it right now (which I'll opensource soon). Since I deal in
the mobile world, its especially critical to keep bloat minimal so people
don't pay data charges for your poor coding. I hate fatty, fat code.

------
mey
GWT at work?

<http://code.google.com/webtoolkit/>

~~~
Robin_Message
None of the class names used are GWT class names, so I doubt it. It'll be the
output of an internal template engine. Interestingly, AFAIK, most of Google is
not written in GWT -- anyone know any production Google stuff that is? (I
think Wave is.)

~~~
mcxx
GMail is.

~~~
Robin_Message
I'm pretty sure that it is not GWT since:

1\. It was released several years before GWT.

2\. It has no GWT CSS class names on anything.

3\. It does have some weird IFRAME structures that are unlike what GWT uses.

4\. It doesn't have any of the long hexadecimal identifier files that GWT uses
to compile to different targets.

5\. On the wire, it doesn't look at all like GWT AJAX requests.

6\. Isaac Truett <itru...@gmail.com> says it isn't at
[http://groups.google.com/group/Google-Web-
Toolkit/browse_thr...](http://groups.google.com/group/Google-Web-
Toolkit/browse_thread/thread/beb685af839718d2/2dd5665b53a6eb11) This was in
2007, but I don't believe they threw away a working product to do a rewrite in
GWT, which was still not fully mature and is still hard to get just right. And
if they did, they'd also have had to make it look like it is not written in
that framework in every way I can think to check easily.

(EDIT) 7. Since nothing significant is written in GWT, they'd be trumpeting it
from the rooftops if GMail was.

------
philfreo
While I agree this example is pretty ridiculous, Google is spending a lot more
time innovating in web performance than most

~~~
gruseom
Yes. Moreover, web performance was one of Google's differentiating features
right from the beginning. Arguably the most important, in fact.

~~~
arethuza
I would have said that their key differentiating feature was that they were
_much_ better at actually finding relevant stuff than the competitors.

I don't think many people stopped using AltaVista because it was too slow.

~~~
gruseom
_I don't think many people stopped using AltaVista because it was too slow._

That's exactly why I stopped using AltaVista. I never noticed Google's search
results being more relevant. I distinctly remember this because I was aware of
the hype around relevancy at the time and was trying to notice a difference.
What was magnificently different, though, was Google's subsecond page load and
search response times.

One interesting thing about marketing is that the reason one gives for using a
product is often rather disconnected from its real utility. (The book
_Positioning_ is about this.)

------
eli
Given the choice between elegant high-level code that generates verbose and
ugly HTML versus complicated and ugly high-level code that generates very
tight HTML, I know which I'd choose.

------
tszming
Send the link to Steve Souders. (www.stevesouders.com)

------
tzury
If one will inspect a blip in the google wave, one cannot think how many
Wikipedia's articles could those bytes feed.

I suspect it has allot to do with the GWT.

a .NET DataGrid or whatever it is called these days would looks just the same
comparing to a simple HTML table structure.

------
jonursenbach
I'd be curious to see how much bandwidth they save by cutting this down a
hundred lines.

~~~
bnoordhuis
As jasonkester pointed out, the HTML is only sent out once and then
dynamically updated with AJAX (or AJAJ, as the case may be). So in the grand
scheme of things, those few hundred lines of HTML don't matter much.

------
sliverstorm
Ahh, bloat at it's best. If we could understand machine code as easily, we'd
probably see the same sort of thing at the core of a lot of software.

------
lancashire
Don't show him Google Calendar.

