I write code, and sometimes have opinions on technology.
I've finally set up an old Windows 10 machine as a CentOS 8 Linux server in my house.
It serves a Minecraft server, an FTP server so I can transfer files to and from it, SSH (obviously, so I can get in) and a gopherspace for myself (mainly to keep track of my gopher bookmarks, and to house my personal journal, because I need to trick myself into journaling every day).
I was concerned that it may not be able to handle serving Minecraft, but the 'top' command shows that the Minecraft Server software actually uses surprisingly few resources.
I'm sure if I tried to host a hundred people or something it would start to slow down, but for 3 or 4 players at a time at max, this will do great.
I also got an external harddrive to run a few basic backups.
I set up cron to use the 'rsync' command to take a copy of the /home directory, the local gopherspace root directory (/var/gopher/capsule.home/), and the minecraft world map data, and save it all to a big, dated '.tar.gz' file on the external drive. It'll run that once a month automatically, but I end up running the /usr/bin/backup.sh script manually myself on most days.
There's just something about typing plain text into a Linux command line that really works for me.
I've fiddled with Linux for years, and I've always been in IT, but now I realize that I have acquired the capacity, for the most part, to be a Linux administrator professionally.
Linux always seemed like this giant beast that I'd never fully grasp... but here I am, starting to grasp it.
Now that I've gotten it all set up and I've installed everything I wanted, I'm almost disappointed that I don't get to keep working at it.
The truly rewarding part of this stuff is the journey.
There's just something about Linux.
From the readme of Solderpunk's amazing custom webserver:
Shizaru is a minimalistic web server whose guiding principle is “serve no evil”. Precisely what counts as “evil” can be configured by the user, so perhaps Shizaru is best explained as a webserver for imposing strong opinions.
An article on the gemini:// network (good luck with that link... here's a web proxy) notes that, if one wanted to put a label on such a non-tracking subset of the web and deliniate things as SafeWeb/UnsafeWeb, and maybe even release a SafeWeb-only browser which would really only display documents by design, it wouldn't even display the vast majority of the web (or, heck, even a good chunk of NeoCities), and you'd be left in the margins, sharing only documents with other programmer weirdos, and building your little communities from nothing.
In the end, what comes out of the idea is something that looks very much like what I have called the unweb. And I agree with the article: effort toward a set of "SafeWeb" standards will only push such a community further into the margins, to toil on their niche tools and not visit half the web, occasionally fronting a petition or "open letter" to air their grievances (like Linux users have been doing for decades), which will go completely ignored by everyone except for a smirking article on a few tech blogs, and probably a post on hackernews, and the comments will all be things like "I don't understand why they keep doing this sort of thing. I admire them, but what do they hope to really accomplish? Just contribute content to the Gopher or Gemini communities, but don't publically demand that Mozilla or Google bow to your demands."
Still, the conversation is worth having, and there should always remain a place for a strongly semantic, document-focused web, even if that place is a tiny community full of programmer weirdos. Unrelated link.
My latest meandering internet sojurn has been an exploration of two alternatives to the HTTP-based World Wide Web, the brutally simplified internet networks Gopher and Gemini.
Gemini is in its infancy, and it is similar to Gopher in many respects, but aims to be more powerful and less legacy. Its markup language is a bit closer to Markdown in syntax, but even lighter. Again, rendering decisions can be made by the client. Gemini is like Gopher plus a proprietary, minimalist markup.
There have been clients programmed by the communities of both of these protocols, and even clients that support both. Oddly, some also support Finger, the old protocol designed to tell who was at their terminal, and when they had last checked their mail. I haven't figured out why that is yet.
Both of these alternate internet protocols, which persist through sheer force of their communities' stubborn unconventionality, are decidedly not the Web.
Users will even refuse to use the word "Blog" because it implies "Web Log," with Gopher writers opting to go with either "Phlog" or "Glog," and Gemini writers usually opting for the term "Gemlog."
I've come to the conclusion that, when it comes to large bodies of community-generated content, a higher barrier to entry is far better than no barriers at all. This way, the content stays at the center. Only those who are really driven to create will publish. Instantaneous thought-spewing of the sort that is enabled by social media, and the sort of shallow non-interaction that the modern web enables and enforces, are not possible on Gopher or Gemini (or Neocities!).
MVP.css is a minimalist CSS framework that uses semantic HTML elements only.
In other words, no classes or IDs.
Just plain, bare HTML in a structured document, and that's it.
If you're interested in how this would play out in practice, check out the basic template that showcases all the components, and bust a "view source" on that bitch.
I haven't gotten a chance to implement this anywhere yet, but it's similar in practice to the design philosophy behind this website.
I use classes in my HTML still, but the focus for me, on the front-end, is on a subtle, clean, crafted look.
This site focuses on words and content over images, but there is certainly some creativity and particular focus at work in the font choice, the way I format header text, and other considerations.
Ultimately, I think HTML is the best way to write (at least, if your brain works like mine does).
My hypothesis is that it engages your left-brain to write the HTML document, which naturally helps you organize your thoughts better.
The nature of HTML as document markup rather than precisely a "programming language" means that the whole page and all of its code exists, or should exist, in service of the content.
In other words, the modern web of relative time stamps, infinite scrolling, and animated icons (AKA speed, perpetuation, and addiction) goes against the very foundation of the web itself: documents, the content of which is front and center.
The Web was built as a system to share structured documents, which demand that the reader slow down and focus on the content.
The Internet was designed to be, and could have been, a system that helped us all to slow down and focus.
In my eyes, we are morally obligated to treat it as such, and to reward websites and services (like Neocities!) that do that as well.
Web components are often a forgotten paradigm of web development.
At first glance, it looks like it could be an alternative framework.
The obvious application of this quatrain of web component specifications is to build a library of frequently used branded elements, and include styling in each component according to your organization's branding guidelines.
That way, every time you need a header element in the proper font from the branding guidelines, you can just include your existing branded header component, and everything is already built and styled.
Customer touch-points will feel more unified, and devs don't have to repeat themselves.
The tendency to use web components as though they were a framework misses the point.
Web components clearly fit within and alongside frameworks.
Any organization with a front-end development team should standardize a full vocabulary of reusable web components that can be kept in sync across all web applications.
This certainly seems to have been Microsoft's conclusion on web components.
When Microsoft's "FAST" popped up on hackernews, many people commented something like, "Oh, Microsoft is competing with React and Vue."
But no, actually, web components are something completely different than frameworks.
Microsoft specifically avoided competing with React and Vue with Fast, and they say so on their front page.
Overall, web components are a much needed and very welcome addition to one's frontend repertoire.
Every organization with a lot of in-house front end development work should build their own internal library.
At its genesis, the Web was a system for distributed document-sharing.
It was designed to be mostly static at first, under various other projects, until Tim Berners-Lee realized its potential as a more dynamic multimedia experience.
Now, the old document-sharing system has evolved into a system for dynamically streaming an infinitely varied set of multimedia applications
(or hypermedia, as Berners-Lee called it, extrapolating from the term hypertext in his initial anticipation of the potential of his idea, in his initial proposal for the WorldWideWeb while at CERN).
Effectively, web apps are now a functional alternative to App-Store-style downloadable apps.
Instead, you're now streaming the app as needed, caching it in your browser rather than downloading and installing it to your device, with barely more than a webpage load.
This is an exciting way to think about the web, and it has led, in part, to the explosion of web apps as a development medium for wide consumption.
At the birth of the web, everything was written in HTML.
With HTML, content is king, and the structure serves the content.
The barrier to entry then was higher, so the content was created with love by intensely smart people who got genuinely excited about very niche subjects.
One looks back with misty, reminiscent eyes at the late-BBS-early-Web days when content was at the forefront, by necessity, with few frills.
Make way for React
Move over, make some room
"But still, my scheme for creating and saving user config files and data locally to preserve them across reinstalls might be useful for--wait, that's cookies."
ReactJS, in my experience, is one of the first front-end development frameworks that truly accomplishes the goal of the above comic.
The initial load time is slightly longer (though the code is obviously minified), but once loaded, all navigation within the app is done within the browser, on the same code that is already loaded in memory.
Others splitting the difference
All of these different methods are intended to cut down on sending fully-formed HTML documents from the server for every single page request which, because the XML-type syntax has so much overhead, can get expensive at a larger scale.
Ultimately, it's still a matter of developer preference.
The web's original intent has been outgrown, or at least expanded beyond, and developers must choose which modern method suits the needs of their particular project.
For the most basic things, and for the IndieWeb, yes, plain HTML will always be there, and it will likely remain the primary language of the web indefinitely.
Despite its syntactical overhead, it is still an excellent way to present a hierarchically structured document.
Otherwise, users often expect an app-like experience when using the web, thanks to the rise of SocialTM.
Who are we to argue?
We just build this stuff.
As the web ages, its visual design has finally begun to mature.
After Apple's early 2000s glossy skeuomorphism faded, minimalist design, flat design, and material design have all taken center stage in their respective domains (along with some notable others).
The web is incredibly good at its basic core functionality and, as developers, we should not be afraid to use it as intended, when appropriate.
In architecture, brutalism is a style characterized by bare, unadorned building materials and intentionally very plain and straightforward shapes.
Toward the goal of specifying a form of "brutalism" for the web, a new design trend has emerged of being intentionally user unfriendly and visually jarring.
This culminates in the creation of the brutalist CSS framework.
Though certainly "brutal," this specific design style doesn't seem especially "brutalist," in the sense of the plain, bare architecture from which the name derives.
If one were to aim for a style of web design that is true to the idea of unadorned, raw, straightforward functionality, it would be more along the lines of David Copeland's treatise on the subject.
Brutalist Web Design is honest about what a website is and what it isn't.
A website is not a magazine, though it might have magazine-like articles.
A website is not an application, although you might use it to purchase products or interact with other people.
A website is not a database, although it might be driven by one."
This idea places Copeland's design philosophy in stark contrast to the current paradigm on the Web.
The word "site" in the developer world is almost considered outdated.
Nowadays, the web is full of apps with carefully crafted and maximally pleasing UX design.
To eschew this effort intentionally, as the brutalist framework does, is one thing.
To reclaim the original intent of the web, on the other hand, and to remind ourselves what it is best at represents a reclamation.
What Copeland wrote about, and outlined so well, can't be termed brutalism;
That term is already taken by a CSS framework the design of which is certainly not "unadorned."
In fact, the brutalist framework emphasizes, brutality, ugliness, busyness, and intentional maximalist excess.
What Copeland described should be termed "utilitarianism".
Utilitarian design is minimalism meets brutalism.
"A website is neither an application nor a video game," explains Copeland.
"It is for content, and so its design must serve that purpose."
Utilitarianism in web design is an opinionated return to basics.
It has no colors or elements that aren't directly functional in service of the content.
So, next time you develop a website, "...start with left-aligned black text on a white background, and to apply styling only to solve a specific problem."
NOTE: If you're interested in more intentionally horrific web design, see Brutalist Websites.