Skip to content
This day’s portion

Why I used to build websites

| Comments

Why I used to build websites

Build websites, not apps:

Websites have morphed into applications over time. Not something I am entirely happy about, but I suppose the web was always going to head in that direction after Web 2.0. Everyone would want to be the owner of a platform. I would go so far as to say there’s a certain kind of power trip or an ego boost from yelling at offline people, “Hey! I run a community.”

By Ru Singh. Originally published 05/02/22.


Add a comment

Required fields marked * I won’t publish or share your email address. Privacy statement.

Comments are moderated and won’t appear straight away. Subscribe to the comments feed to see when new comments are published.


The two paragraphs at the end highlight some of my biggest issues with modern web and software development. I don’t have any major qualms with markdown but it’s not a substitute for HTML even though people like to treat it as such. I prefer writing HTML directly instead of relying on abstractions but it seems that most people are vehemently opposed to writing HTML. This is in spite of the fact that even ancient editors can be configured to make the experience even less confusing than writing markdown.

I don’t think poorly of TypeScript or earlier abstractions like CoffeeScript but keeping up with them is quite cumbersome. Then there’s Less, Sass, and a million different CSS frameworks. Is writing vanilla CSS really that much of a problem?

I also miss when user resources weren’t completely mismanaged by extremely inefficient websites and by frameworks like Electron. Multi-million dollar companies with the resources to maintain native applications opt instead to manipulate document renderers into performing complex tasks as the expense of users. Hardware from 15+ years ago would still hold up well if not for resource-hungry web technologies constantly demanding more of users.

I suppose it’s no longer fair to think of web browsers as document renderers however. They have become as complex as operating systems. Nonetheless, I do feel that there should have been some sort of division of labor instead of trying to cram everything into web browsers. Web applications could have used a different protocol and a different technology stack. Those of us who just want to create, share, and read documents while taking advantage of the synergy between hyperlinks and a networking component could have stuck with the same technology that worked 30 years ago.



I guess the problem with abstractions is twofold. Firstly, without knowlededge of the underlying language, grammar etc. you become tied into whichever abstraction you choose.

In my case, I think it’s fairly low key and low stakes (jQuery, Markdown, Tachyons, Jekyll and – by extension – SASS), but then again, all I’m building is a blog (with next to zero javascript), and my knowledge of HTML and CSS is OK.

If Jekyll and Markdown disappeared I could just handcraft these pages and, if I was staring from scratch, I’d not use Tachyons or SASS, partly because CSS itself has developed with custom properties.

(Linked to this is the ability to evaluate and learn new abstractions; if you know the underlying language you can make those judgements a lot more confidently, I think).

Markdown is useful, but not quite as much as I thought it would be. For me writing this blog, yes; no matter how much your text editor helps, I’d be surprised if it was as easy as using ##, ** etc. But at work the website editors just use the WYSIWYG editor the CMS provides, even though they have the option of using Markdown.

Is the other main problem fragility? I think my set up is fairly simple and robust, but then I look at Jekyll’s dependencies and that list of technologies above… I dread to think how stressful some build chains must be when based on, say, NPM.

I have a different perspective on apps versus web. I suspect my only lasting contribution to the technological world will be this library self-service system, a progressive web app (built on React). From a cost and maintenance point of view choosing to develop a website is great – one codebase, device and OS agnosticism – and it’s possible to create good UI with HTML and CSS.

Is the problem here with moving the heavy data lifting and manipulation to the browser from the server; i.e. reaching beyond the browser’s original prupose of simply displaying the HTML it’s been sent? I guess this is what Hotwire is trying to solve. I have to admit, I don’t build technical enough things to make a proper judgement – presumably, there are good, solid reasons for creating complex apps in the browser.

Your final comment put me in mind of this article on creating a computer that will last 50 years. Publishing a blog like this should be possible on the set up I had back in 2004.