Dmitry Petrov Back

github.com/can3p twitter.com/can3p Atom feed About

On Web without HTML

07 Apr 2020

Intro

Note: I use markdown throughout the text but you can replace it with you favorite comparable markup language of choice.

Internet is a very interesting place now. We have moved from a totally decentralized place to the one with very few giants in all fields (Amazon, Facebook, Instagram, Reddit, Medium). There is a lot of discussion about this state of affairs and I don’t want to discuss the obvious.

What I want to discuss is another wave, that came our way without too much publicity - simple markup languages like markdown. One might wonder - what’s so interesting about it? I think this wave is not accidental and goes along with big social platforms and decline of html/css hype.

Let’s start from the last point. Anyone who has been in web development comunity for a while remembers good old days when the movement for web standards was strong and the community itself was very vibrant. Lots of new hacks, tricks and technologies, a lot of discussions. I might very well be out of the bubble now, but from my observations it’s all gone now. People were obsessed with pixel perfect design back then, just remember all possible ways to get perfect round corners or opacity or any other design element. Where is it now? It’s still around us of course, but in many cases it lost it’s relevance. And the reason is not only because we got flexbox and new features in css. Most notably, content and community is the king, especially when visuals are good enough.

I still have my active account on Livejournal.com where people were people were obsessed with keeping their diary in their style and were very vocal about it. It was mainstream back then, but it isn’t anymore. It appeared that once you have people around, design becomes much less relevant. Instagram, Twitter and Facebook are good examples there. Instagram is extreme in this case - only plain text is allowed, no customizations at all. On twitter users used to post text as pictures to work around text limit. On Facebook there’s a bit more freedom in sence that you can use markdown but that’s it. None of them allow to do any significant customizations and all of them have lots of users that post valuable content, connect to the loved ones or do business there. With zero css and not caring about pixel perfect design a single moment. If you think about it, all these platforms became browsers in browser and all the markup and styles are out of play there. The reason why it’s so is because this form of content is much easier to handle. There are no special cases, everything is under platform control. It’s much easier to do a mobile version, it’s much easier to do an app on any type of hardware/software.

Next, let’s have a look on Markdown. It’s not about it in isolation, of course. It’s rise is only partially thanks to it’s simplicity, a lot of it is due to platforms like Facebook, Github or Gitlab, that render it in a good way along with links, which means you can have a site with hyperlinks for no cost and it will be accessible to users. As you see, it’s the same here, no css involved, all is needed is a browser in browser, that converts the markup to some tolerable form.

And we also have a huge movement of static websites. HTML and CSS are still there, but underneath it’s often the same markdown. We do design only once (like on this particular blog) and then work only with markdown, because it’s easy and good enough and what happens underneath is a conversion of markdown to a good enough html/css, I’ll put it into the same bucket with github/gitlab.

And to make things even more interesting - all major web browsers have a reader mode now that takes any wonderful well designed page with ads, noise etc takes the main content and renders it into a simple easy to read form. From what’s supported one might argue that an opposite conversion takes place - from HTML/CSS back to markdown with it’s limited support for headers, lists images and a bit more. Or you can take any of Dan Luu’s posts which look bad only till you enable the reader modex in firefox which makes them near perfect.

We didn’t talk about money so far. The situation improved quite a lot from early days in sense that there are solutions like Stripe now that allow to implement payment solutions with much less effort and there is Patreon that provides a distinct monetization strategy by allowing to support a person on ongoing basis. There are even projects like Substack.com, that allow to do paid newsletters. And we thought newsletters were dead.

The last part is community and there is a split there too. While back in the days everybody was busy integrating something like Disqus comments (this blog included), I have yet to see lively discussions happening in standalone blogs. Discussions happens in places where people actually hang out, hence they’re all on Hacker News, Reddit or big social networks now. Of course it’s possible to name some exceptions, but it’s safe to agree that it’s exactly that - an exception.

What that means is that you don’t need HTML/CSS to be popular and facilitate discussions. Two good exteme examples of this are blog of Dan Luu and essays of Paul Graham.

One can look at this trend from a different angle too. Semantic markup, precise styling, strict protocols were all about effectiveness. How do we describe page in the best way, that it will be technically possible to render it like we want. How do we integrate payments in our platform in the best possible way? It’s still there, but what is also there now is that people find new ways of working with restricted platforms that do not support a lot/any of it.

I can definitely say this for the russian part of the Instagram, but I guess it should be the same for other segments too. Users sell things, facilitate courses or workshops and handle a lot of things manually or by combining existing tools. Want to make a payment? Just transfer money on someone’s bank account. No need to make a separate courseware - yet another closed account or Whatsapp group is enough. Everything that software engineers hoped to solve in a perfect way was successfully hacked around by ordinary people with much more limited technical skills.

The last thing that’s worth talking about in this long intro is a concept of ownership and distribution. On classical websites author controled all of it. And you can see copyright notes all over the place. Does it really work on big social networks? Distribution is lost for sure. Once you make a post, it’s visibility is certainly out of your control. It’s up to facebook to put it in front of millions of users or never show it to anyone and the only tracking you can get is the one that’s provided by the platform and you only can trust it, the same goes for any other platform and there is nothing users can do about it. And what’s interesting people are fine with it too, even with reposts, since there is little left of the concept of a “place” of a person on the platform.

To sumarize, what people really want is:

And as you can see, it appeared that there is a very limited need in complex markup language, styling and scripting in this usecase. Moreover it can now be considered as a burden, since there is a lot to learn there, a lot of platforms to support, a hosting and related costs to worry about with modest benefits compared to social networks solution.

No HTML

Now, having said all of this, it’s time to think about if we still need html now in the form as it is now. For complext usecases we certainly do - it’s hard to implement amazon in markdown without extending it the extend that it becomes similar to HTML, but for many other cases it might be a really good fit. And the fact that it’s constrained is more of an advantage than a drawback.

For example, it’s much better for the bandwidth, can be easily stored offline. What’s more we move from pixel perfect design which requires effort from authors to browsers that are now responsible for all visual aspects.

Can we imagine a situation where we skip all the HTML/JS/CSS and serve a page in a language like markdown directly? It’s like going to pre-CSS era, but it doesn’t sound aweful anymore.

Also, it’s kind of solved on big social platforms, however can we take this bit out of them and put it in the wild?

Features we would like to preserve are identity, distribution and payments. None of it necessarily requires any complex markup to be solved, especially if we assume that browser takes care of it. So, what if we return to a concept of browser fully owning the presentation layer?

We can also split different aspects apart. It’s not required for all these features to be on one platform in case page itself has some metadata that can be used by the browser, and that also opens up an opportunity to build the best possible experience on this particular platform.

For example, if you want to sell the access to an article, you can encrypt it with your favorite payment provider and mention required data in the header, so that browser can display all necessary information to the user, facilitate a payment using open protocol with this provider and get a key to decipher it.

In the same way it’s possible to have a link to a site that facilitates discussions, however it’s up to browser to check your favorite one to see if a post is being discussed there.

If you think about, taking monetization strategy and discussion apart also means that you don’t really care if a page has been really served from your website, since there is no dependency on pageviews anymore.

All this does not mean that it has to be self hosted, but it might be coupled with rss to make it discoverable and different content aggregators can use it to show you personalized suggestions.

Moving all the rendering functionality to the browser also means that it becomes a point of extension. If you want to support a different type of content, you might need to have a different render, which might even be the same html/css, but it will be only one of possible options.

There is still place for them of course, especially for big application that will never fit into a constrained solution, and making a separate extension for all of them is probably not an option.