Google Coders Need To Go On An HTML Diet
geekypeek.com
geekypeek.com
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 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.
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:
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.
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
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.
I don't think many people stopped using AltaVista because it was too slow.
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.
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.)
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.