James Westman @flyingpimonster@fosstodon.org

I'm so excited to see my camera app working on a real #PinePhone! Now I just need it to work *well*.

I'm not too fond of the crates system, though. Why do all the examples for something as simple as generating a random number involve downloading a separate crate?

Serde is also awesome.

I'm trying to learn WebAssembly/Rust, and it's surprisingly easy.

The mockups of Hourglass, our third-party project manager for #GodotEngine, are starting to come to life! Here is the Projects tab.

Federation is what gives Mastodon users control over the platform, but I think of that as an implementation detail, not the main point.

"User-run," I think, gets straight to the last point: Mastodon is better for society because its users control it.

And *now* we get to the part that's important for society: federated systems are resistant to censorship and abuse of power, because there is no single organization to take down, and if users aren't happy with *any* available options, they can create a new one with minimal effort and consequences.

Then you have to understand the main impact of federation: that there are multiple, interoperable providers that you get to choose from, and if you aren't happy with the options, you are free to start your own.

First, you have to know what "federated" means in the context of web services. In an age where centralized platforms are the norm, most people have no concept of what a not-centralized platform would look like.

The closest well-known analogy is email, but even that is a bit of a complicated jump, going from direct messaging to social media.

To understand the benefits of a "federated" network, you have to understand multiple layers of definitions.

I wonder if, instead of promoting Mastodon to the general public as "federated," we should call it "user-run." That emphasizes the governance model of our network rather than the technical implementation.

Is it a technical problem? A problem with developer mindset? Obviously it's *possible* to make smaller websites, even *easier,* we just... don't.

Actually, what I really want to know is how to fix it. This isn't a mismanaged company making a bad product. It seems like this is *how modern web development is expected to be done.*

What I really want to know, I guess, is what caused this. What combination of factors led to a product being developed and released in this state? Because I'm assuming nobody at the company *wanted* to make a website this slow and cumbersome.

I reloaded the page again and now it's closer to 10mb. To be fair, it compresses to about 3mb.

Is it images? Nope, that's only ~250kb. Most of them are SVGs.

There's about 400kb of CSS. That's enormous but not really the problem I'd want to fix first.

It's mostly JavaScript. 9 megabytes of it.

I just measured the page size of my math homework site. It's 7.48MB, with tracking protection on.

That's not the assignment page, it's just my list of assignments.

I wonder what, other than a few dozen links, could possibly take that much space.

If you're bored and looking for something to do, you could add contact information for your favorite local restaurants on #OpenStreetMap.

I fail to see why Google Play needs >400MB of space to install an 8MB app update. This is on an old, cheap phone running Marshmallow.

At first I was disappointed that Respondus Lockdown Browser wasn't available on Linux, then I realized I would never in a million years run it on my Linux installation anyway