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.

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

The overly complex and messy generation of crappy HTML is bloat.

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.

  #include <stdio.h>

  int main()
  {
    printf("Hello World!");
    return 0;
  }

    .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

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.

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.

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.

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.

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.

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

If you use HTML 1.0 you can render something on most (but not all) browsers. EX: text only browsers will not show you imgs. And yes, these are still in use by the blind community.

If I was a cabinet maker and all I had to work with was sawdust, you'd sure as hell bet I'd invent a machine to compact it into something I could build solid structures out of. I wouldn't consider gluing pieces of sawdust together by hand to be any sort of meaningful craft.

http://www.zazzle.com/css_is_awesome_mug-168716435071981928

At least we got a sweet T-shirt and mug out of it.

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

While not a "web app", SpeedTracer ( http://code.google.com/intl/fr/webtoolkit/speedtracer/ ) was also made using GWT.

What's interesting, is that with the Adwords UI, Google started using GWT on an enterprise app, and thought about ways of writing such an app. This project lead them to introduce many best practices for large GWT enterprise apps:

- MVP (Model View Presenter) and testable UIs: MVP is good for SoC, but it's also very important if you want to unit test your UI logic in pure java (which is a lot faster than GWTTestCases)

- EventBus

- Command Pattern

- UIBinder (declarative UI in XML)

Ray Ryan's talk ( http://code.google.com/intl/fr/events/io/2009/sessions/Googl... ) at Google I/O 2009 created a lot of interest around these concepts, and many GWT developers around the world started discussing / following them.

Google I/O 2010's sessions also have a lot of talks about these subjects, and while the best way of writing GWT apps is not yet known, we are getting there.

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

edit: "currently" with that article being published June 25, 2010

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

Maybe. Personally I stopped using it when they started throwing pop-unders at me.

Or maybe it was because it jumped on to the whole "portal" craze and other SE's that were cleaner felt quite refreshing.

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.