Starting a Blog II – Engineering

I promised some technical stuff, well here it is: If you just came for the cookies, you can skip a couple of paragraphs.

On the web there are three languages that are used to do, well, literally everything. The problem, though they are designed to work together, there is no strict separation for what context they should be used. This missing separation makes it super hard, to write decent webpages. Additionally, there are different browsers, using different default values, making it even harder to develop a website that looks and feels good across devices and operating systems.

From HTML …

HTML is the format we use to structure our website. And just pure HTML already mixes up at least two domains of context. The first domain is the content itself, meaning the words or type of content, like an image, that is shown on the website. The second domain connects to the shown content a semantic context. Does the element belong to a heading, an article, an ordered or unordered list? Moreover, a hierarchy between the elements is introduced, as those elements define the structure of the website. At this point things become messy, as we have the content of the website in one hand, the structure in the other hand, and the role of the element in the third hand. Three hands, I hope you can see the problem? No wonder that things get messy in one HTML document. And this even without dynamic elements nor a description how they should be rendered.

To CSS …

CSS is the language that is used to format an HTML webpage. Meaning how much space is between a heading and the following text element. How big is the text, how is a list rendered. All those elements can be configured, either as preset, or by custom classes (reusing the semantic context of an element) or directly as inline CSS in the HTML document. We now also allow writing custom layout rules and commands to the elements, introducing a fourth domain to our elements. Even though CSS allows us to write templates of configurations (for different kind of semantic elements like headings), we still have to apply them to the elements where we use them. For example, when we want two level two headings with different style, we have to mark one heading in one style, and the other in the second style. As a consequence, we mostly have to annotate the elements, how they should be rendered. That is, in my opinion too much and to opaque annotations for one element, especially if you consider that there lots of elements and custom elements per website.

The consequence is missing re-usability of one nicely defined, formatted, semantically annotated group of elements: If we want to have the same style across multiple documents (or multiple elements using the same group), we do not only have to use the same style-sheet – there it is for – but also have the same structure of elements annotated with the right classes. We lose ourselves in copy-pasting styles, classes, layout across HTML documents, making general changes super hard. If we thought we were clever and use a shared style to format our elements, we run into the danger that changing this stile to fix one document, can destroy the formatting of another document.

To JavaScript …

I will keep this section short: There are use cases when we want to allow our website to change dynamically, e.g., for performance when loading remote data, or for custom interactive elements. However, HTML itself allows us to define default interactive elements covering most of the use cases we have on modern websites. Moreover, websites are build to provide information and rarely, to respond to user input, or to adapt to custom input in complex ways. In my opinion, the use of JavaScript everywhere and especially for content where it is not required, comes in with a hidden dark side. It invades the users privacy and security and reducing the availability, usability, and stability of the website. Especially the latter points fall back on the website provider, meaning that a well-designed website uses JavaScript, when there is no other way, and uses HTML and CSS to archive the necessary stability and usability of the website. I think by using less dynamic stuff, we can archive a faster and clearer website. The latter two should be our final goal when developing a website.

To Web-Frameworks

So get rid of that mess, I described previously, higher programming languages have at least one framework of predefining elements that should speed up the development of websites. However, this said development speed-up comes with a price to pay. Websites get forced into the design philosophy of the framework, which might fit in some cases but fails in others. In the end, the frameworks have to do some trans-compilation to HTML, CSS, JavaScript or Web-Assembly to become a website. As the frameworks have to cover all corner cases on how the components they define are used, either the frameworks get huge and messy themselves, or the developer has to fall back on custom HTML, CSS, and JavaScript. Especially the debugging and customization gets difficult, as we have to change the properties in the framework differently, then the resulting HTML that get produced by the framework. So to speak, instead of simplifying the process, we add a layer of indirection, introducing more potential origins of error, and increasing the complexity of our website without need.

Oh, and Cookies

First, I have to say that cookies are super. There are plenty of use cases where you can take great advantage of them, for example: When you want to impress your girl-/boy-friend. Some would call it bribing. Or for bribing people. Or for making new friends by bribing people. Or to mess with others people healthy diet. You devil! Or if you want to put something into your coffee and eat it afterward. Well, the latter might is somewhat ridiculous.

You thought this article would be about the technical stuff, like web-cookies. Well, if your cookies grow webs, they got forgotten, or were just disgusting, or both. Shame on you, in any way.

There really is not much use but storing a state on a device. No, not a state like Germany or Sweden but the state of a website. If the title should appear in red or blue. I see so many websites in the wild using them, where I really ask myself what they do with all that state. And where is all the state? The only stateful element on the website is the accept-decline-element of the cookies themselves. I hope you can see now, why I find it just stupid.

You can delete the state, edit the state, and do what ever you want with it. As a consequence, your website should store important stuff server-side anyway. And yes, they are often used track user sessions and integrate authentication to a website. About first, there are other (better) ways. About second, in most cases that is just a dangerous idea, so you really should know what you are doing. HTML was not designed to support this last use cases properly, IMHO. Authenticated use sessions, that’s a hard thing. Honestly, maybe I should write a whole post about it.

And still you see cookies everywhere, or at least the you-know-which-element. It is the worst thing about nowadays websites and shows how broke the web is (or at least most websites you find online). There can’t be any engineering behind it, or please explain it to me! It is like making cookies with a concrete mixer. Possible, but the result is rather unsatisfying.

Finally, I now understand why people say no, if people ask to accept their cookies. Just think about it for a moment, and the states, all those beautiful states that get lost. I know at least one person who would like to rule (own) them.

My Approach

As we have seen, there are many details and contexts we have to consider building a website. Instead of using a framework top down that creates our website, I build this blog bottom up. Starting from nothing, only introducing elements we really need. Doing so I have full control over the HTML elements created. The framework I use maps its element directly to the generated HTML tags. Moreover, it allows us to specify any attributes for formatting or linking to the tags in an additional statement. This allows us to create exactly the semantic structure for our content we want.

So why is this approach better than either writing pure HTML, or just using a top-down framework. About former, by using a higher level programming language, we can make use of type checking and other advanced programming features. I surely will write an article about the thoughts and ideas behind the framework, without formally reimplementing the HTML standard. Moreover, it allows us to strictly separate the content from the template, allowing us to reuse components and generating the website dynamically. Gaining advantages of a high level language, the codebase still stays as close to the HTML document as possible, making it easy to fix bugs and formatting issues. About latter, every HTML element that gets created corresponds to an element in the code-base, where we can make the changes if necessary.

Anyway, this project is a playground and in digging into the fundamentals, I spend some time understanding and researching the HTML standard, its concepts and how it is used with CSS. As the framework, I am using is super incomplete, it will grow when I need its features.

Some Final Thoughts

I hope I did not rant too much about nowadays web design – probably I did though anyway – so I hope, I founded my arguments well, at least. To conclude I want to say that I have mixed feelings about it. It is surely not true that I hate the web, but rather that it is still way below its capability and potential. There are some political and socially negative tendencies, but they should be part of another post. All in all, the web like it is today is an infinite source of information and human creation. It is a statement of expression and sharing knowledge and all the tools and languages that are out there allow exactly that. Most problems have a long historical, technical, economical and financial background, so instead of dooming everything, we should take a look at the things that work great and focus on them. I would like to call the web a playground for technology, but instead of trying to conquer and control as much as possible of it, we should tear down the walls and play together.