My web site philosophy

This one reads really rambl-y. Heads up in advance, and don't take anything I write here too seriously 😅

When I think of the internet, I think of free and easy access to information.

Writing web sites and reading them should be free, and easy.

I typically use the Free software foundation's definition of 'free'.

There is easy to write, and easy to read.

Easy to write implies that the basic technologies & concepts needed to create and host a web site on the internet are easy to learn and access.

At a very minimum, understanding HTTP, HTTP server software, and HTML are necessary. Thankfully, these are very straightforward.

It is not particularly difficult to rent out a server, install Apache, and begin serving HTML documents. In addition, HTML is a very simple, human-readable language too.

Easy to read implies that the content being served by the website ought be presentable and clear on any internet browsing software. Additionally, website content filesize should not exceed what a user would reasonably expect.

To achieve but of these, I cut out JavaScript and CSS wherever possible. Pages on my website use very little CSS, usually making use of flex just to center a few elements, or remove the body margin.

Pages on my website use no JavaScript. JavaScript is the original sin of websites and I believe it should be abolished.

I don't believe websites should track you. In using an HTTP client, your browser already sends a variety of 'headers' to HTTP servers containing bits of information about yourself. These are often included in an access log by default for many implementations of HTTP servers.

Generally, I am not concerned with HTTP headers. They transfer your IP address which can be used to narrow down location, your preferred language, and your browser user-agent. I don't collect them in the first place on principle, but remember that you are always trusting websites you visit with them.

IP addresses can be collected and tracked accross multiple sessions. When Facebook code, embeds, iframes, etc are included on a website page, Facebook will collect your IP address and connect it to the page it's on. Always be careful what sites you are visiting and what code is running on them!

JavaScript generally allows for far more trickery in tracking specific user activity. I would actually claim that in 2019 the most frequently kind of JavaScript code executed on the client side of a website is associated with tracking, thanks to Google Analytics. Following that, I'm sure it's a jquery or bootstrap related set.

Outside of tracking, JavaScript is really only good for manipulating the DOM and loading dynamic content. Both of these things are very useful - animation, no page reload, "interactive" pages, etc...

In my opinion, websites that rely on JavaScript to organize content such that it's easier to parse or browse are relying on a crutch. It is a sign that your website architecture hasn't been well thought out in the first place.

There's nothing wrong with a page reload, as long as it's fast.

When you reload a page, images, scripts, and external CSS are loaded from the server, or the browser cache. Then, they are rendered onto the page. Often, this can result in numerous content reflows, especially if JavaScript is manipulating the DOM on load. Bad!

If you build a website elegantly, such that images are minimal and filesize optimized, CSS is minimal, and page URLs correctly represent the content being served, it is far more useful for reading/writing web pages to keep it lean.

I don't think "back" buttons are necessary UIs. I think the whole concept of "UI" in websites is just another way people have been dealing with the problem of having too much stuff for one website. The web browser already has a back button - a lot of websites will fuck just a touch with the history state, making the back button unreliable. In an elegant websites, it shouldn't be problem.

I don't believe in big title headlines. Every web page has a URL which is displayed in the address bar, and a title meta tag. Both of these will accurately 'title' the content on a web page, and can be read by users and machines.

I don't believe in icons. We have unicode emoji which are widely supported. The set of existing emoji serves pretty much any need that one would typically fill with image icons.

The history of the internet is a funny thing.

The idea was, to have a global system wherein users could easily share information between each other. HTML and HTTP were developed as open standards to this end.

The thing is, capitalism has largely been a fetter on this.

The need to sell, to profit drove much of the new content being put on the internet.

There is a difference between advertisement, and sharing information desired by someone else.

Products being sold needed to be appealing. This meant colour, styles, animation. This meant CSS and JavaScript.

As it got more popular, marketing divisions need to be able to calculate how many visitors see or read ads. Thus, tracking.

As JavaScript occupies a bigger and bigger place in web development, people start deciding, 'hey! why don't we just program the whole shebang in JS'.

Which you totally can. I don't mind NodeJS being run server-side for handling HTTP requests and serving HTML.

I am STRONGLY opposed to libraries like React which rely completely on DOM manipulation to render a website to users. This is the opposite direction we ought to be taking.

You should be able to read a website in as many cases as possible. That means that if I don't have hypertext rendering software that processes JS or CSS I should be able to read it. Websites that rely on React or Bootstrap for clarity in content presentation flunk terribly when viewed in console-based browser software for example. Historically, they've also flunked on phones. There are no issues in either case if the two are avoided entirely.

JS and CSS are useful tools. Over-reliance on them is a mistake. Sticking to hyperlinks and keeping content relative to what users would expect from the address bar is key to elegance.

I don't like to touch fonts where I can avoid it. I trust the browser generally to choose respectable font sizes and families for the paragraph and header tags. Where I know I'll have longer, variable-length content, I will often set the font-family to 'sans-serif' and leave it at that.

I've heard that text becomes more readable when the not spread across an entire 1080px viewport. In cases where text is longer, I'll often limit the maximum width of text to around 500px.