I made a tool for converting a spritesheet into an animated GIF.

This program was borne out of a similar situation as the text editor one. I needed some functionality that was super simple but couldn't find exactly the right thing in an existing program.

I used to use a web application for doing work like this, but I don't like depending on web apps where it's not strictly necessary. Why, because when you upload your files or data somewhere, you're putting a lot of trust in that other party. They probably wouldn't mis-use your data, and the data isn't anything sensitive anyway, but the principle of it is undesirable.

There's also the fact that a web application is so much overkill for the task at hand. Think about it. Why do I need a full web stack, javascript interpreter, communication across text protocols, etc for something so simple like resizing an image, or changing the encoding? It boggles the mind. It's like SHOUTCLOUD but not ironic. I have nothing against web applications, but I don't think everything needs to be a web application. That stack is too thick.

As for the whole world heading to web applications, maybe that's inevitable. This idea could become feasible as internet infrastructure improves- in many countries it is not all that fast or always-on-and-everywhere, right now. The principle of a thin client with a smart server and a good internet connection seems interesting.

But why do these this future "web app" need to run in a browser? Why does it need to be built on HTTP, of all things? Remember, there's a difference between "internet" and "web pages". There was internet before web pages. There might well be internet after them. What is so holy about HTTP? It's hard to see anything good or holy about it, other than it's a standard (ish!) borne out of 2 decades of blood and tears. If you've had to do any work on a web browser, you'd know. I did a little. I've seen enough.

Indeed, a thin client can't even be all that thin if it can parse and display web page content. HTML5+Canvas, CSS, JS, SVG, weird extensions and back compat... there are a lot of sub-technologies required to get a competent web browser and light up even basic, typical scenarios. A lot of things could work via a simple page but in practice they do not. In the late 2010s it's not uncommon to see >10MB payloads for viewing a single site, and for pages where that payload isn't all images or video- pretty common- you can imagine the CPU necessary for unpacking some of that.

Put it all together with the fact that local computation, device battery life and internet connectivity haven't really kept up with rising web site complexities. If they did, none of this would even be a problem. I wanted to hold some optimism for here for phone apps but I highly suspect they're usually coded as web applications, hosted in web browser containers anyway.

It's nice, the idea of side-stepping that entire stack and running a program natively on your computer. If the program was written competently, it has a good chance of not being flaky. At least, it is not likely to be screwed by tech on which it is built.

Web pages are good for some things, things based around displaying text and images which are updated remotely. Maybe some light games. But you should probably not run your traffic lights, your pacemaker in a web app.

Anyway, as for this program- it runs natively, and includes some features that are useful for what I needed out of it.

Find it here on GitHub.