What´s wrong with webdesign...

The web has evolved a lot since the days of Tim Berners-Lee, who invented the “World Wide Web” in 1989. The initial Idea was to make scientific information more accessible. Researchers these days used ASCII-Terminals with 80 x 25 characters, so text formatting was limited to simple text decorations like bold face or italic and maybe some tables. With respect to the limited bandwidth, HTML was a good choice that exactly met this requirement.

When people started to use graphical interfaces and color screens (which was in the beginning 90´s -though not much later), the conceptual weakness of HTML became visible: there was no way to adequately map formatting, colors and graphic elements with HTML. So, CSS was invented to retrofit the missing functionality. With respect to limited bandwidth, CSS is highly efficient: it modifies the way, page elements are formatted, so you need to send the formatting information only once for every type of element.

From a designer perspective, CSS is a nice concept: As all elements of a type are formatted the same way, it makes documents look uniform. And it separates the definition of form and content, which allows designers to create professional looking style bundles that are used by authors, that can focus on the content.

From a programmer’s perspective, CSS is a real mess:

It modifies the behavior of the machine, so the results depend greatly on the current state of the machine, not only on the input itself.
CSS-definitions always have a global scope. This is very likely to produce side effects on larger pages.

CSS ignores the most basic principles of functional and object-oriented programming and makes it hard to apply one of these paradigms. This is not a problem, as long as you use the web as a simple text formatter (which I claim it never was). But it gives you some headaches if things are more complex.

And most of all: CSS and HTML are no programming languages!

What´s bad about that? Nobody said that they should be! Right, but this is the source of the trouble we are in today.

Example: HTML provides a handy ordered list facility <ol>:

this
is
HTML

This is ok for simple cases. But what, if you need to start at 2 or need a different numbering step 10, 20, 30… Or a different number formatting? Then you need some modifiers or a different type of list for this behavior. You will have to create a new directives for every thinkable situation. Finally you end up with a real mess of elements for all possible situations.

This is different with programming: a for-loop is not limited to a predefined range or numbering. Simply write for (i=10; i<100; i+=10) or whatever you like. Programming is a bit more complicated, but you are prepared for every possible task. Programming languages provide a very small, but universal set of commands to implement algorithms. Even unexpected situations can be covered using the same tools.

As we know, there are different programming options for the web available like PHP or Java. The trouble is: All these languages have to deal with the conceptual shortcomings of HTML and CSS. You can write perfectly encapsulated code in Javascript, but to access HTML-elements, the only option is to use global variables. You can manipulate CSS with perfect pure functions, but you never know if there are some conflicting definitions.

Today, most webpages will need some kind of “responsiveness”: the layout has to be different on different devices, content or styles should respond to user input etc. It is possible to do these things with CSS, but at a high price: Most CSS “frameworks” have an overwhelming number of features and options, which gives you a long and shallow learning curve. You virtually never come to an end but still are not prepared for the next task. As a result, there are hundreds of sites out there to teach “CSS-tricks”. It´s like trying to making a French menu from ready-made soup.

There is a strong trend to use “frameworks” these days to create responsive websites, but what precisely is a framework? The definition is not quite clear. Frameworks pretend to make life easier and to make codes “reusable”. Angular, React or Vue implement lots of useful tools and new concepts, and basically rely on the dynamic expression of HTML and CSS. They are not very squeamish about mixing syntactical elements of HTML, JS and their own creations. So, what people do, using one of these frameworks, can best be described as “programming tools to create HTML-pages”.

Does this overcome the shortcomings of the initial html-approach? Obviously not. It just helps to release the pain.

The days of terminals with 80x25 characters are long gone. So, why do we still use HTML? Adding directives like “ngFor” to HTML will not bring this dead man to live - or make HTML a programming language. The more people start to use browsers as a programming platform, the more it´s time to rethink the use of HTML and CSS in it´s current form.

Traditional programming is far more complex than creating web pages. A typical windows program compiles some 100.000 lines of code, not included the numerous external resources it uses. We have developed methods to write reusable codes long before the WWW was invented, so, why not use them? Javascript had a nice progress over the last years. Other languages like Java may serve equally well. Finally, our target is to create and manipulate DOM elements, so why should we use HTML? Using HTML and CSS is just a detour, direct DOM Manipulation is a logical solution to most of the current problems with web design. As most search engines do only understand HTML, SEO is still a serious restriction. But in the long run, this will not be.

What about rendering problems? Do we need a virtual DOM? In my experience, this is yesterday's news. Current browsers have brilliant rendering engines that cover most problems perfectly. So, for the user experience, working directly on the DOM is not a problem, it is blazing fast.

In my expectations, we will see some general changes in the future. The more the web establishes as a programming platform rather than a design tool, the roles will change. Hopefully we will see more well designed and straightforward concepts than we do today!