DISCLAIMER: This site is a mirror of original one that was once available at http://iki.fi/~tuomov/b/

1. As if it wasn't enough that GNU/Linux has become a clusterfuck of decisions made with the buzzword gleam in the eyes. Much of the time in front of the computer is spent using the Web these days, and it is crap. If a higher version number is supposed to be an improvement, I will take Web −2.0 over Web 2.0. It is not that I am opposed to “Web applications”, i.e. programs that are run in the browser, as such. On a fundamental level, I in fact like the idea, but only for things that are used only occasionally, and do not have to depended on. For many uses, however, Web applications are too unrealiable, and the interface leaves much to be desired. Such applications are also fundamentally incompatible with privacy.

For those few good use cases, the technology and implementation of Web applications tends to be utter and total crap. Implementing WIMPshit with Javascript and the abuse of HTML tables and layers – what are they thinking? Are they thinking? I doubt that. HTML is suited as a distribution format of relatively static documents, not applications. Applications are better described in other ways, and can then interface with the document(s).

Such HTML and Javascript hacks invariably need to make assumptions of the display capabilities of the browser, as well as its rendering model, for things to at least appear to work – for the very undemanding users. Usually things don't work, and the hacky interface components end up all over the page. Keyboard accessibility also usually leaves a lot to be desired – in which HTML's ‘access key’ features do not help at all. In fact, the feature tends to make matters worse, because browses' handling of the keys is totally arbitrary, and sometimes the keys override the browser's own bindings – which is undesirable – and sometimes it is the other way around. Even supposing these problems were solved, what if you don't like the provided keys? Would it not be easiest to have the browser do all the key assignments by action identifiers? And how about blind people? How about people with other accessibility requirements? How about people using a mobile device or otherwise small screens? Trying to access the page in text mode? Such low-level display capability, input, and rendering model assumptions are a major problem, that more abstractly defined applications could avoid.

2. Although I do not like Flash very much, and Flash applications are in many ways clunky, when applicable I usually prefer one embedded in a document over Javascript hacks. Java applets I have the problem with that Java Crashes Browsers; even more often than Flash, which also does not have that good a track record. If Java implementations (and the language, for the matter) weren't so bad, applets could also be an option for Web applications that are of such nature, that they can be embedded in a document.

Flash, Java applets, and the like, should, however, not be the only option as media players or, more generally, for viewing documents in other formats. In such use cases, sites should merely provide a default implementation, that users can choose to replace with applications that they prefer.

I also do not like using Flash or other such things for fancy links and such: that is best done with CSS or other such style sheet mechanisms alone. Please use CSS: it is a nice technology that is still used too little. Much of fancy layout and other effects could be done with CSS alone, without breaking the semantic structure of documents. I find it odd that the home pages of the text mode Links as well as Links2 browsers, for example, use awful table hacks instead of CSS, and yet alternative browsers in particular would benefit from a decent Web that does not assume much from the display capabilities of the browser.

3. Flash and Java applets also do not automatically solve the display capability assumption problem, and many Web applications can't be well embedded in a document. Rather, they embed documents themselves. Presently the way to achieve this is by ugly dynamic HTML hacks. There should be better, abstract, ways to describe the application, as well as to style it akin to CSS. But – what I'm talking about here is essentially Vis again. There could also be a language for describing Vis-style applications akin to HTML, but with semantic elements more appropriate to applications than documents (and better syntax), and embedded code in another language (even Javascript). This abstract application could then be styled with stylesheets, just like HTML can be styled with CSS. These stylesheets would, however, be quite different from CSS, although CSS could form part of them: some transitory versions could even generate typical HTML+CSS+Javascript abuse. Even if the browser could not render the application as intended by any of the provided stylesheets, it should often still be able to provide some kind of interface to it. Sometimes it could provide an interface better suited to the user in question, than that provided by the author.

Sometimes the line between an application and a document can be a bit blurry. A sidebar can be seen as part of the document, but it could just as well be part of an application containing the document, or even documents. I would tend towards the latter interpretation: the sidebar consists of controls to affect the actual displayed document(s). Documents are simple, applications are complex. Electronic media also offers for the possibility of embedded applications, and there are blurry lines between these and the containing document and the outer application as well. Sometimes the embedding amounts to nothing more than “linking” to the containing application. Dynamic HTML hacks are in a limited sense an extreme example of this, where the application has no permanent interface at all, but is only activated by linking. There are good uses for such linking, such as in application documentation or “configuration documents”, but more caution is needed than is applied in this age the barbwire Web.