Who will save the tables?
April 2, 2009
About a decade ago, the web development industry made a decisive shift towards support for web standards. Though the effort encompassed many related efforts around HTML, CSS, the DOM and related technologies, perhaps the signature work of the movement was to encourage CSS-based layouts instead of the then-common practice of using HTML tables to design a page's visual appearance.
The campaign was extraordinarily effective, to the degree that most new sites that launch today use CSS as their primary system for styling and positioning. And the more socially inept web geeks out there still consider those who use tables for layout worthy of their derision, instead of opportunities for education. Tables have fallen so far out of favor that it's not uncommon for people to be reluctant to use them even for the presentation of tabular data.
In short, for front-end web developers, tables are definitely out of fashion.
More recently, web architects and developers have adopted a new generation of storage technologies for data, such as BigTable and SimpleDB. While these systems still use tables to store data, it's common to have a far smaller number of columns in these tables than were used in older systems. And their advantages in areas like scalability and partitioning, have encouraged lots of developers to consider adopting these new data storage systems despite their unfamiliarity.
In short, for back-end web developers, fat tables are rapidly going out of fashion.
Now, I don't mean to suggest that these technological trends are merely about geeks following what's faddish or popular amongst their peers. In fact, in both cases, the shift away from traditional tables might reflect the fact that our data has to be more nimble in both how it's stored and retrieved and in how it's presented and styled. These accommodations are necessary because the applications being built are more social and human-centric in nature, which means they have to be able to adapt and evolve as relationships and communities mature.
But part of me can't help but feel sad for the tables. I'm sorry, tables! I hope you come back in favor soon.
(Thanks to Mo for the image.)
12:14 AM
|
7 Comments
Leave a comment
- Earlier: This is how we should talk to kids
- Next: Elastic Happiness
"In short, for back-end web developers, fat tables are rapidly going out of fashion."
Noooooooooo ... in either direction (# of columns or # of rows).
Obviously there's optimizations to be had by minimizing the number of columns you've got in a database, but not only to the extent that you're pulling out infrequently-used data. (The most highly-trafficed tables on LJ had 10-15 columns each.) If you go too far in the other direction, you end up spreading your data around in too many places, and suddenly you've limited yourself and your ability to scale.
And partitioning etc is great, to limit the number of rows in any given instance, and a good thing to build into applications to anticipate future growth, but it's actually probably not something most sites ever have to worry about. (There's a post on the MySQL Performance Blog called KISS KISS KISS listing a bunch of scalability techniques and how they're most likely not necessary -- YouTube didn't have sharding until two years ago.)
There's no "right" implementation, IMO -- there are best practices, and there are advances in the field that help shift those practices (eg, memcached is a great example) but people need to build their applications in a way that's necessary to scale, and that means following certain principles (eg, "make it really easy to access commonly-used data") as opposed to specific techniques.
What about three-legged stools?
What about the spacer gif? Now there's something that really deserves our pity.
I don�t understand what you�re talking about here, Anil. Tables have always been OK for data, just not for layout. And you seem to be confusing back-end and front-end.
Tables are alive and well in HTML Email; many email clients have poor support for CSS in HTML Mail (especially web-based ones such as gmail and, notoriulsy, outlook 2007). Many RSS readers are even worse. Tables are often the only way to get even a decent approximation of what you want in mail and rss. It's a shame that the developers of email and rss clients feel they're entitled to abrogate the standards.
I find there are far two many data models and API data schemes that are pointlessly multi-dimensional. At the end of the day, so much of this data needs to be processed in columns and rows that it makes no sense to over-complicate.
Anil, don't forget that tables will have a second coming as CSS3 starts rolling towards us now that IE8 supports them.
Here's the critical difference between DIV-based and Table-based CSS layout: MS didn't start trying to implement Table CSS until AFTER it caught the standards wind.
The future is bright for tables. They're just moving from HTML to a new address: CSS.