Pinderkent

I read through an article today that shows the struggles Web developers go through to perform basic layouts using CSS. In the article's particular example, it's simply some images and some associated textual content displayed in a grid-like manner, with the amount of text being variable.

In short, it's a practical, real-world data display that should, one would think, be very easily accomplished using CSS. As is often the case when using semantic markup and CSS, what should take only a few minutes balloons out into a battle against unexpected behavior, browser incompatibilities, browser bugs, and so on.

Whatever benefits CSS might have brought are quickly eliminated by the time and effort necessary to get the content displaying even remotely correctly. But we must also consider that the end result becomes nearly unmaintainable. Other Web developers working with the code later on will likely not appreciate or understand the struggles that went into getting everything working in the first place. Making even minor changes might not be possible, or might be extremely time consuming, with much care needed to avoid rendering incorrectly in various browsers.

I'm not suggesting that HTML tables would necessarily be a better solution. I just find it extremely bothersome that such a simple task so quickly becomes such a huge hassle when using CSS, with the end result being quite fragile. This is what we'd expect to see from an immature technology, yet CSS has been in the works for roughly 15 years, and has been implemented by a number of different groups. It's pretty pathetic, really.

Ron Garret's recent publication of his "Why CSS should not be used for layout" article has resulted in there being much discussion about whether CSS or HTML tables should be used for Web page layout.

This post isn't going to argue in favor of one or the other technique. It'll just link to some of the more prominent articles written recently. But if we do try to draw a conclusion from all of this discussion, it would have to be that as is often the case in the computing world, that there is not a single technique that is sufficient for all users.

Although it's not a new concept by any means, the use of JavaScript for server-side development has gotten some attention recently. This is unfortunate, as JavaScript is not the sort of technology you want to use when developing the back-end for a Web site.

Even as a client-side language, JavaScript has proven to be of a very questionable quality. I think Jonathan Edwards was correct when he described JavaScript as being "quick" and "dirty", and only just "good enough" for most users. For years now, even the major JavaScript implementations have exhibited horrible performance. Only after 15 years of use are we seeing that start to change, with faster VMs from Adobe, Mozilla and Google. As a language, JavaScript itself does very little to encourage the development of secure, high-quality code.

Server-side development calls for a more rigorous programming language and environment than JavaScript can offer. Considering JavaScript's performance problems on the client-side, it's likely they'd be magnified when it comes to server-side development. And JavaScript really doesn't offer anything beyond more traditional server-side languages like Java, C#, PHP, Perl, Python and Ruby. As is mentioned in the Ajaxian article, there is a huge amount of basic Web back-end infrastructure that will need to be built to make server-side JavaScript even barely comparable to any of the aforementioned programming languages.

What's worse, however, is the general "attitude" associated with JavaScript. It has always been a language that appeals to those who want to get their scripts written quickly, even if the quality is terrible and there are major security flaws. It has often been used by Web designers to quickly add some interactivity to the pages they have designed, without needing an extensive programming background. Indeed, this amateurish attitude becomes very dangerous on the server.

PHP is a good example of such danger. For years many PHP developers generated SQL queries directly using data sent to their script by the user, with little to no filtering. This resulted in SQL injection attacks becoming very common for PHP-based software. We still even see this sort of development happening today, in some very sad cases. Meanwhile, more mature server-side languages and environments like Java and .NET have for years provided support for parameterized SQL queries. But even the most inexperienced of Java and .NET developers know better than to not appropriately filter user input.

While there will of course be some professionals using it, and using it well, I fear that the rise of server-side JavaScript would lead to nothing but problems. Just as the PHP community is starting to get its collective act together, we might see a new generation of inexperienced, amateurish developers start with server-side development using JavaScript.

Then again, maybe that's not a bad thing. It'll guarantee a steady stream of work for those of us who have made a career out of fixing such mistakes. But it is unfortunate that we couldn't stop such problems in the first place, but using better languages for server-side development. With some work, Haskell could become very useful for server-side development where quality is concerned, while Erlang plays its part in reliable and highly-scalable systems. Regardless, the main thing we need to keep in mind is that JavaScript should be avoided for server-side development.

Over the past week or so, I've seen links to this diagram of the MediaWiki database schema posted on a number of other sites and blogs. Now, MediaWiki is no minor piece of software. It is used to power Wikipedia, which Alexa currently states is one of the top ten most popular Web sites on the Internet.

At many of the companies I have consulted with or worked for, it is rare to find a document or diagram as precise and effective as the one for the MediaWiki database schema. It's even rarer to find a real-world database schema that is so consistent and sensible. Clearly, a great amount of care and experience has gone into the development of this database.

Even without studying it for very long, it is apparent that it is a rather clean database schema. One thing that is apparently almost immediately is the prefixing of the table columns. This is a technique often used to reduce the ambiguity between identically-named columns of separate tables when those tables are joined. It also helps make it more clear from which table a given column is coming from when looking at the results of a query.

The one minor inconsistency I do see is that the names of some tables contain words that are separated with an underscore (for example, user_groups, user_newtalk, page_restrictions and site_stats), while others do not separate the words (for example, filearchive, oldimage, pagelinks, searchindex, and recentchanges). At least the tables related to certain functionality tend to have similar naming conventions.

The normalization and the relationships between the tables appear to be quite sensible. The short descriptions, even if only a sentence or two long, do significantly help make it clear why a certain table exists. This is something that is lacking from many enterprise databases.

Performance is clearly an issue, so we see some caching-related tables in the top-right corner of the current database schema diagram. We see other tables, like job, testitem and testrun, that show that this is a real-world database where we have external batch jobs, as well as testing. This isn't just some academic exercise dreamed up in a classroom where the necessities of the real world are not to be found.

Any piece of software backed by a database should strive to have a similar schema diagram. And it needs to be kept up-to-date as changes are made to the database. This single schema diagram teaches us much about the MediaWiki architecture, but it also speaks to the quality of the product. Software that is built upon a sensible data model often proves to be very natural, and thus in many cases easier to develop, which often leads to a higher-quality product. If a production database schema can be kept as clean as that of MediaWiki, then we'll likely see greater programmer productivity, and higher software quality.

I read through an article today that suggested an idea for a Web site where a user can specify a task in a programming language they know, and the site tells them how to perform it in some other language.

This is an interesting idea, and no doubt could make for a useful site in some cases, but would likely run into problems creating the relationships between languages. Even something as crucial as string handling can differ significantly between different languages. C treats strings as arrays of characters. C++ treats strings similarly to C, but also has for example the std::string class for representing strings. Java treats strings as an object. Erlang treats strings as lists of integers.

So operations that are available in one language may not really have an immediate equivalent in another language. Likewise, the approach taken when using one language may be completely inappropriate, in terms of performance or memory usage, when using another language. Such a Web site would need to ensure that these differences and the potential risks were clearly stated. But otherwise, I think it might actually be useful, even if the article suggesting it was somewhat in jest.