Aral Balkan

I have currently found myself in love with a new topic (new for me), “The Small Web”.

Which is not completely new or strang actually, as I have been doing so in the first days of my web dev journey, when I uploaded sites (html and php files) using ftp (Fillzila?) and Boom the site was online (let’s assume the domain&dns were already set).

Those days I was more focused on building what I had in my mind rather than getting stuck on NPM, lots of dependencies, deployment, Https, and etc.

How did I meet the small web?

I was looking to simplify my web dev stack researching and looking for the tools that could simplify making a simple web app.

Tools that can help indie devs make their MVP ⌛quicker/easier and launch asap, rather than getting stuck on the development/building phase and/or worrying about scaling issues from day one (what I did before).

What is the small web?

Who can explain the small web topic better than my friend Aral, the man behind the amazing “Kitten” project.

FYI “Kitten” is a complete Small Web development kit. Which is exactly the tool I was looking for.

Here is a part of Aral’s note on “The Small Web” and a link to it to read more.

You can also visit my blog (linked above). I will write more about this topic, and also sharing any helpful resource that can simplify our job in making websites and web apps.

Aral says:

“ The Small Web is the Single Tenant Web

Small Web applications and sites are single tenant. That means that one server hosts one…

Not well. I'm optimistic about the web in general, but I consider good, reliable clientside storage to still be an unsolved problem, at least for the moment.

Some of the things we're still missing:

- the ability to easily share data between domains without opening yourself up to massive security risks.

- the ability to share data with native apps.

- the ability to move data between browsers without syncing it to an online account.

- the ability for normal users to inspect offline data.

- the ability to trust that browsers like Safari won't just arbitrarily delete your data one day.[0]

- the ability to trust that browser upgrades won't ever corrupt the data you have stored.[1]

- the ability to share large amounts of data without worrying about storage limits (this matters a lot if you're making an editor like Atom or Visual Studio).

Typically, what I see with offline apps is that they'll use offline storage, but they don't trust it. They use it when possible as a progressive enhancement, but then they have to sync that data to a server someplace if it's something that users actually care about. And that matches my experiences as a web developer as well. I can't imagine building something like a password manager or text editor in-browser that was only storing data locally, I wouldn't trust that.

It's also not just a technological problem, it's a problem of UX. If I tried to make a purely offline web app, I'd be getting angry customer calls in a week asking where…

Your coworker gets it :) It’s simply a matter of business models – you don’t even have to like Apple or think they’re lovely people (everyone I’ve met there has been).

Google’s business model is to digitise you and own that digital copy. They use this proxy of you to manipulate and exploit your behaviour for profit and to indirectly rent access to aspects of you to their customers (currently, advertisers).

Apple’s business model, on the other hand, is to make great tools and sell them to you at a price that makes them happy.

(So if you were to buy an Android phone and never use it, Google would be very unhappy. If you buy an Apple phone and never use it, Apple’s still made their profit.)

To cut a long story short, privacy is an absolute competitive advantage for Apple. It is a thing that they can compete on without breaking a sweat (as it doesn’t impact their bottom line negatively) whereas, if Google was to try, they would go bankrupt (as their business model depends on profiling you and violating your privacy).

All you need to understand to grok why Apple is protecting your privacy is that multibillion-dollar corporations don’t get an absolute competitive advantage over their main rivals everyday and – if you do find one – you’d have to be an absolute idiot to squander it. (And I don’t believe the folks at Apple are idiots.)

So yes, Apple’s systems are proprietary and closed, and no, you don’t have to love everything they do, but when it comes to protecting your…

Let’s build it: The Sovereign Individual (1997) + The Sovereign Consumer (2018) + AI Community of people that practice and develop tools for achieving digital sovereignty, digital immortality and autonomy. Roadmap of products: • social co-pilot | social os for building and maintaining relationships with best people • life OS — ai-native workspace with long-term tasks to be executed by ai, gamified, execution-free. • self-hosted automated LLM-based recomendation system (aka beeper.com + Loyal AI) with MCPs and A2A protocol. • self-hosted self-sovereign identity (ref. timelinize.com + https://beepb00p.xyz/hpi.html Roadmap of problems to solve: • solving loneliness and isolation for people (stop losing people and messages from) • solving social engineering for senior people • solving productivity for power users through automations References: • socialinbox.dev • lifeweeks.app • timelinize.com • beepb00p.xyz/hpi.html • beeper.com • reddit.com/r/DataHoarder • reddit.com/r/selfhosted/s/n8uxvYYa1V • https://postplatforms.org • book: The Sovereign Individual (1997) + Sovereign Consumer (2018) • small web / small technology https://ar.al/2020/08/07/what-is-the-small-web/ • indieweb.org 1000 people sovereign community • #quantified self • independence part of diagram.website

I'm not sure what they ran, but if it's Mastodon: it scales in troublesome ways.

For one, it uses Rails and is very big. Rails is known for being extremely slow¹.

A difficulty with ActivityPub is that it scales rather weird. If your server has (accounts with) many followers, you're essentially DDOSsed through activity. So it scales weird in the sense that not activity on your server demands Resources, but that activity on the fediverse, which you don't control, does.² So it can get very expensive really fast.

Maybe something like gotosocial could lower these costs. But that's not "stable" (as in: frequent, disruptive upgrades and missing features) enough for a govt, I'd say. Its software design, however is far better aligned with a server with relatively few (one, or a few dozen) accounts. Accounts that can have large following and activity. Whereas the Rails project is much better aligned with servers with (tens of) thousands of users. I.e. with mastodon.social.

1 I've been helping companies scale and tune Rails for over 12 years now. I know it can be done, but also what the limitations are. They are real.

² https://ar.al/2022/11/09/is-the-fediverse-about-to-get-fryed-or-why-every-toot-is-also-a-potential-denial-of-service-attack/

> Most of the noise comes from Web technologists don't want to learn anything beyond JavaScript.

I agree with a lot of what you wrote, but not this. PWAs are the only path for allowing open publishing of apps that is not gated by a large tech firm. While I completely understand the value proposition of app stores, there are tons of app scenarios held back by them. Two instances are small web[0] and situated software[1] as app stores keep people from publishing apps meant for small audiences by their very definition. Both of these fall under your desire to maximize the user experience.

Furthermore, PWAs are the closest thing we have to a “universal” platform. Personally, if I could write an app that worked on all mobile devices and the web in COBOL, I’d be thrilled to write “PROCEDURE DIVISION” every day.

The web is a mess because it is open. The web can be scammy because some people are scammy. Restricting PWAs doesn’t mitigate scamminess - it just restricts openness.

[0] https://ar.al/2020/08/07/what-is-the-small-web/
[1] https://www.gwern.net/docs/technology/2004-03-30-shirky-situatedsoftware.html