@collinsworth yes.

code bloat, administraive bloat, opex bloat, feature bloat, design bloat, staffing bloat, and UI bloat are neither golden nor standards. they are waste.

efficiency is not glamorous and often not even visible, as you say.

this is a valuable idea you've put into our heads to look for it.

@collinsworth @danilo this is the kind of tech that I try to build in my open source work, and… it’s really hard, and people *say* they want it, but it feels like swimming upstream. The nine-layer architecture diagrams suck up all the oxygen in the room

@collinsworth nah, Google once wrote some overly optimistic quarterly goals on a whiteboard and then they took over the world, so now we all have to make OKRs, that's just how it works

@collinsworth Having worked in a big (multi-billion dollar, hundreds of millions of concurrent users) I concur so hard.

Scale is a trap.

I am, at this point, something of an expert of doing a lot with very very little, and this is the skillset I am the proudest of.

@collinsworth This is one of appeals of writing servers in Rust to me. It has a better chance of just working really well by default. Granted I'm not sure if I could deploy to a VPS though. I think Svelte on the front end is a similar appeal.

@collinsworth I used to do exactly this for a living. But then the market fell out from under classic content marketing and I couldn't afford to be an indie, SMB-focused blogger. Everyone else I know was driven out at the same time. By the end of 2018 there were almost none of us left.

@collinsworth 100%. More discussion and case studies would help a lot with evaluating tools against the kind of situations I might actually encounter. On the business as well as the technical side: one of the reasons I’ve been using Laravel is the business model seems much more closely aligned with my goals, giving me hope the direction will be more aligned longer term.

@collinsworth damn right

@collinsworth I get what you’re saying, but if people weren’t constantly trying to break in to systems, the need for these knowledgeable people whose salaries are based on the costs of getting the knowledge to some degree. Scaling is easy. Securing the contents is hard. And system updates need to be tested for breaking changes (Windows 11 has some big ones coming up that break a lot of third party tools for instance)
It’s a great idea damaged by bad actors.

@collinsworth This is why I converted all my websites to SSG and started https://barley.cloud/

@collinsworth

Coincidentally I was at #AdvancedLigo this weekend and heard one (tax-payer funded) programmer share "most of my work is #bash and #Python because it's the best for processing large amounts of data..."

@collinsworth totally, the vast majority of tech inside Amazon makes zero sense for anything smaller.

@collinsworth There are. Ask the erlang/elixir folks. We have tales.

I can tell you the 99% result if you want. It gets killed. Because it does not fit the growth view of the world. And not spending money faster is a death sentence for a VC startup.

Also means managers cannot easily use metrics proxy, because you cannot ignore the complexity.

The biggest recent case is Bleacher Report

@collinsworth Quietly leaves this here:

https://codeberg.org/kitten/app

And this:

https://ar.al/2020/08/07/what-is-the-small-web/

And maybe this, to see where it’s at:

https://ar.al/2024/03/26/draw-together/

💕

#SmallWeb #Kitten

@collinsworth Today I seen news that Firefish development is continued etc. Took a look at how it looks and decided that It would be nice to try to get running a single-person or family-scale instance of this.
Took look at that and ended up discouraged as it require some complicated flow of setup. This is surely not for "single-person or family-usage" scenario, it seems. Everyone uses "corporate-scale" tech like postgresql and other "heavy" stuff from the start, and as result, it get "too big".

@collinsworth

Me.

I'm this case study.

I'm the guy who built a global >100gbps network spanning 8 locations on 3 continents, based mostly on SME FTTP, secondhand eBay hardware, and a couple of strategic colocated racks.

If you want this case study, talk to me.

[edit: now that VyOS is more mature, I probably would need half the hardware]

@collinsworth @bjoreman I’d say we need to redefine ”scale” to mean a relevant number of users - nobody has a billion users, few have millions of users, most have thousands of users on a good day.

@collinsworth
Reminds me of this: https://world.hey.com/dhh/why-we-re-leaving-the-cloud-654b47e0

But given the size of the big three the marketing pushing everyone to the cloud is massive. And the messaging is clear; if you don't move all workloads to the cloud you are stupid, a laggard and old fashioned and will never be able to compete.

@collinsworth @tychotithonus but if our architecture isn't webscale, how will we ride the hockey stick from zero customers to... umm... zero?

@collinsworth

Similarly, when you participate in a forum on Stack Overflow or Reddit and get criticised because the tech you are using doesn't scale on million node clusters and takes a few seconds to run.

@collinsworth so true. A very real requirement in some markets/use cases is the ability to scale *down* and the kind of highly distributed solutions which work at Amazon scale just do not do small scale efficiently

@collinsworth wait you guys are getting half a million?

@collinsworth what Amazon and Google won't tell you is they run all their own infrastructure on #OpenLDAP. And it doesn't need armies of engineers to optimize because it already scales perfectly linearly across arbitrarily many CPUs without any tuning.

@collinsworth
Yes, and there will be examples of exactly this, scaling without infrastructure costs - so a single part time person can create an app that scales world wide without spending a cent on hosting.

#Autonomi is a secure, privacy focused platform that will change the rules, expectations and possibilities in favour of developers and users.

@collinsworth ...back in 2016, and after over two decades of working for big telco names, we decided to go 'solo' and put all that wireless exp to good use...omg what a wild ride of thinking all was gonna be a 'piece of cloud cake' (it wasn't, nor it is reliable or cost-effective), with dozens of proprietary solutions tried-n-tested TO having no alternative but to do ALL ourselves, in-house with the strictest of budgets, open-source, non-proprietary tools - and the results are just beautiful

@collinsworth So much *this*. Small, self–contained binaries that store all their state in a SQLite database, where you backup those two files onto a removable disk you physically put somewhere safe.

@collinsworth the ideal usecase is a practice-oriented business running out of a server a nephew set up ten years ago before going off to college and forgetting all about it

@collinsworth My favourite philosophy for these tech stack choice questions is "Choose Boring Technology" https://boringtechnology.club/ Similar to what you're saying, but it's not exactly about targeting the "cheap-ass VPS somewhere". If you want room to grow that may be a mistake (yes, maybe you have some cringeworthy optimism about having 1000 times the number of users some time soon) but then again the well-established well-used boring technologies are usually good at scaling down as well as up.

@collinsworth this is the way!

The inefficiencies in the industry is probably by design to generate more revenue out of training, cloud costs, etc.

@collinsworth @joel I would absolutely (pay to!) subscribe to that magazine.

@collinsworth ha yeah well look over here 😄

@collinsworth
I've worked at both huge-scale companies and small. Both require very competent people to avoid tech failure - although huge vs small require different competencies.

@collinsworth @dsalo seriously this is my next academic project :) it’s been a huge part of my opt out experiments, seeing such maintenance and care as a value and part of how tech can knit us together meaningfully instead of shred our social fabric.

@collinsworth @dsalo there was a time when Amazon and Twitter were scrappy startups that had genuinely figured out ways to move rapidly and build lightweight scalable systems without “enterprise” baggage, and that time was 20+ years ago

@collinsworth Small things that can run forever on a small box in someone's cupboard make me happy.

@collinsworth This (ancient) piece on a dating site run by one person from about a single rack for about 6 billion pageviews a month is memorable for me.
https://highscalability.com/plentyoffish-architecture/

I love this exact kind of tech you describe! The #SmallTech and the #SmallWeb and, by extension, the #IndieWeb @collinsworth

@collinsworth and some jamstacks were too efficient to be profitable

@collinsworth hadoop and kubernetes have certainly been great technology for staff engineers. so many years of job security.

@collinsworth this was essentially my message from my PerfNow talk: https://youtu.be/f5felHJiACE?si=eCLusFP4iWa-_BRw – I included how my teams were burned by this, so somewhat of a case study.

@collinsworth this is a big part of the book I'm working on, at least as far as math is concerned https://pmfpbook.org

@collinsworth this is challenging me in a healthy and uncomfortable way.

@collinsworth
I think people use shortcuts when evaluating tech that's similar to how bikeshedding works.

Compare frameworks on benchmarks only rather than how they help structure applications, as the latter evaluation is much harder.

Use something that is used by big tech because they surely have thought it through and our tiny app is a temporarily embarrassed web scale app, right?

Nobody got fired for buying IBM is also a classic.

@collinsworth
If you're talking about "per year" and US salaries, half a million dollars gets you maybe 3 people, not a small army.

@collinsworth Check out #Haxe, my favourite languages, transpiles everywhere and built entirely by enthusiasts.

@collinsworth we're literally this case. i get annoyed when i see people (mostly DHH) shit on serverless tech or the cloud, saying it's cheaper to run your own data center. Not when you're a small agile tech team with tight budgets, it's not.

@collinsworth Agree, but the incentives to find such tech are just not there.

@collinsworth @nitot Ca te parle sûrement ...

@collinsworth I regularly say something similar, which is "why are you trying to imitate a company that literally has more money than it knows what to do with"?

This also looks “so frontend development.”

For 15–20 years we’ve been looking at how big companies are solving their big problems, instead of learning how those of us with small problems (individuals and SMBs) best solve their small problems.

That’s our Occam’s razor why frontend devs know Bootcamp/Tailwind, jQuery/React, bundle/deploy, and have every 10-visitor site sit on all edge servers—but for whom HTML is `div` and CSS is broken.

The craft died in Big Tech.

#frontend #html #css #craft

@collinsworth this, always this

@collinsworth THIS THIS THIS.

Honestly, it was incredibly dispiriting to hear the words "we don't know if big websites will use this feature so arent sure we should develop it" from a member of the Safari team this week.

Like... can we please stop developing web tech *specifically for giant sites and corporate entities*. That is explicitly *not* what the web was built for.

It feels like such a betrayal.

@collinsworth @ash you can do a lot by picking boring technologies but all the cool blog posts on ci systems or whatever are written by people with tools teams.

Those boring tools lock you into other decisions. Use GitHub? You’re probably locked into the GitHub issue tracker as well (unless you want to do integration, so you need a tools team). And their ci. Etc.

And this is _good_. These tools scale cheaply because you make fewer decisions. But it makes them hard to adopt incrementally.

@collinsworth but there are - the high availability blog for example (used to?) have tons of those and if you look into a lot of scaling articles they also show how amazing lots of tech is in the hands of a tiny team of 2-4 people

@collinsworth I know that the main sqlite + fossil architecture is backed by a couple low-end VPS nodes and CGI scripts which seems entirely reasonable to me.

@collinsworth seriously most startups and small businesses using cloud to "scale" could actually try to do it on a VPS for a change, to see how much of a bloated clusterf*ck cloud services really are: makes sense to no-one except to those selling them and people drinking their expensive kool-aid.

@collinsworth heh, i was just wondering this morning whether those nightly batch perl script that have been running successfully for 20 years should be considered tech debt or an astounding accomplishment in continuity

@collinsworth

But who would pay for that case study then?

@atkelar

@collinsworth “100 amazing technologies you can setup in a day and then never worry about again”.

@collinsworth after hearing this reasonable take being ignored through my entire professional career, I gave up. Excited engineers will always follow "industry leaders" without criticism. Dissent is confused with ignorance.