What is Exile Heavy Industries?

Exile Heavy Industries is an organization working towards re-imagining and re-inventing the ways we use computers, what a program is, and how to best solve the issues faced in the current computing landscape. We focus on simplicity, security, efficiency, and composability. We believe that complexity should only exist as an emergent property of smaller systems working together in ways that can be redefined at any time to better suit the needs of the situation.
It could be said that we exist to be all the things the modern computing landscape is not. We put control back in your hands, and provide you with the means to build whatever you need or want.

Why "Exile"?

The most direct answer to this is because the domain was inexpensive and matched the name I had given the VPS I was using. It's fitting though, since the approach and design we strive for is all but forgotten in modern projects. All these pages are hand-written in an nvim buffer running inside of tmux, all the projects reject pulling in needless external dependencies, rather, focusing on means to improve the software directly and tune it for its intended purpose. The single most expensive part of connecting to this site is in simply establishing the TLS tunnel.
Exile Heavy Industries emphasizes simplicity above all other aspects of the solutions being set up, it's more important that the stack remains understandable, than that we use the latest and greatest "Webscale" or now "Serverless" technology stack. Many of the problems we throw more resources at in the modern programming and systems architecture worlds would be solved by simply removing the portions that are inefficient. One of the best examples here is the promotion of Google's AMP, SPDY, and QUIC protocols. While TCP and HTTP may not be the fastest solution to the question of "How do I get my webserver contents to the user?", it's also not so slow that you need to change the fundamental technologies used in hosting the content, just examine how it's actually being presented to the user.
How many requests are made to get essential resources?
How big is the package I'm asking my visitors to download?
Can it load reasonably quickly even on old hardware or poor connections?
How much JavaScript is needed to get the page to a usable state? (hint: unless you're hosting a web application, the answer should be none)
These types of questions are important, because not only does it accurately describe the issues imposed by some larger sites, but it also addresses the underlying issue: you're sending too much to the client. If you have old hardware and can't afford to upgrade, it doesn't matter that you can download a single blob or establish several parallel connections, it's still going to be a terrible experience. If you're limited to 1Mbps or less, then that 32MB webpage is still going to feel like it's taking forever to load. This approach can even save you money, if you can reduce the size of the page you're shipping by 50%, that's 50% less bandwidth you need to pay for, or 100% more clients you can serve at the same time.

The Exile "Manifesto"

It's our "manifesto" because I think such things are a bit silly when it comes to tech, but it's also a bit on-brand with "Exile" and seems to be pretty popular right now. The simplest version of this is only two sentances: "The system should work for the user. The system should be as simple as possible where complexety should only be an emergent property."
So with that said, here's a slightly more verbose read:

The system should be as simple as possible
As in, we should eventually reach a point of "irreducable complexity", where doing any less would render the whole goal meaningless. What use would ls(1) be if it didn't actually list directory entries?
The primary constraint is simplicity
As described previously, no single aspect should grow to a point where it can reasonably be called more complex than is necessary to achieve the task it was built for. If such a scenario occurs, it should be examined to determine if breaking it into smaller parts would make sense.
System components should be composable
This is probably the single most sought-after aspect in modern programming, the ability to take disperate programs and have them interact in ways that the original authors may not have intended to create new systems to solve problems. It's the foundation of shell pipelines, but is often difficult to find or use in more complex systems.
Complexity is an emergent property
In keeping with the end goal of simple, composable parts, the whole system should be complex by virtue of how the user causes interactions in their persuits. No complexity should ever be foisted upon them, it should be something they create by using the tools available to them. Much like how a chisel, a hammer, and a block of marble can become a magnificent statue in the hands of an artist.
Security and Correctness
While simplicity as the primary design goal should aid significantly in writing secure and correct code, there's no guarantees that these alone will result in code that is difficult, or ideally impossible to compromise. Extra care should be taken to ensure that the code produced by Exile Heavy Industries does not expose consumers to additional threats. There's enough of that going around as-is, and we want none of it.
Performance is the final frontier
It's important to keep in mind that performance is going to be a key factor in adoption and longevity, so care should be taken to ensure that we're not producing code like you'll see on most big sites, consuming large amounts of RAM and CPU time for little to no benefit to the users. It also allows usage on smaller and older systems, which is important for consumers that are either less wealthy or in developing markets that don't have access to such powerful hardware.
It's for these reasons that the single most expensive operation in browsing the resources here at exile.digital are going to be establishing the TLS connection or will be clearly labeled as computationally expensive. For example, if a JS cryptocurrency miner was added as a means of providing support, the page it resides on would have warnings around the link warning users about the resource usage potential. The same goes for when the fossil repos are added.

...Still Loading...
Just kidding, I'm trying to find time to keep writing these pages
This page is pure HTML and CSS, it "loads" nearly instantly