[annoucement] current state of Filestash

[mickael-kerjean]

Hello everyone,

I just want to make a status update on the state of Filestash, what's coming in and why I haven't been able to be as responsive as before in answering everyone's questions.

The gist of it is I'm rewriting the frontend of Filestash from React to Vanilla JS. The goal of this rewrite is many fold:

1. fix all the frontend hacks, improve the quality. When I got started with Filestash in 2017, I had no idea what it would become and how things will be. It was not supposed to be a project many thousands of people rely on all around the world. There's a few things like tagging, having a sidebar navigation and enable embedding in your website that aren't simple to implement looking at the current structure of things, cleaning everything up will align the codebase to where Filestash is going in the long run.

2. fix all the maintenance issues and unwanted dependencies. JS tooling is a pain to follow with things changing on a daily/weekly basis, making the maintenance aspect a lot more challenging that it should, the simplest cra web app has > 800 hundreds dependencies. Our industry has accepted this fate but I think this is insanity, I want to be able to audit all my dependencies making sure everything is clean and I don't ever want to go through the pain of migrating a webpack 2.2 code base to webpack v5. A couple months ago, I started working on what a simple es6 spa application could look like with "modern" code using only standards. I came up with this https://mickael-kerjean.github.io/skeleton/example/index.html which is just a prototype to fix some ideas before starting on the migration. Things are moving quite fast, the plan is to first migrate the admin side of things, release it to the public, get some feedback then start the more visible frontoffice side

3. make it simple to extend the core so you can customise things for your needs. The objective here is to end up such as you can open your browser developer console and say "wow, this is so simple, I can understand everything, let's make a patch that will add the behaviour I want" where your patch is just a diff on what you want to change, all in real time, no compilation necessary with a very small barrier to entry to start hacking

4. regaining control over every single details of how the application work, what I want is the best possible performance on the world shittiest devices, and to do that we need absolute control of every single piece of js that is being loaded, from where, when and how. I've seen people with insane setup trying to load buckets with millions of files, and this is where things become tricky. Filestash should accomodate the craziest use cases, getting the best possible performance with 0 overhead and no unwanted js code running on your device so we can tailor things to the finest details for the platform you use it from. Framework are great but all those abstractions have a cost and it's time to peel all those convenience layers off as introducing new libraries is just not gonna solve those pain points

[neingeist]

Thanks for your efforts!

[mickael-kerjean]

I finally released the very first part of this migration which is effectively a rewrite of the admin console before tackling the actual end user frontend later on.

Some interesting numbers with this delivery:

Build size:

	With brotli compression	uncompressed
current vanilla JS	60.6kB	156kB
previous react app	287kB	2.8MB

There's some more opportunities to reduce this further but we're running effectively 95% less code than before on the browser.

Time to interaction with the admin console with a server that is 10,000km away from me and a shitty internet connection:

• react app with a build: 4.88s
• current solution without a build: 5.3s

Without introducing a build step and using plain HTTP1, we're running very close to the original admin console app. There's a few opportunities to make this much better than before:

• leverage the interesting part of HTTP2 and/or HTTP3
• introduce an optional build step if there's some additional gain to be taken from a pure HTTP2/3 solution

EDIT: we're down to 3.5s using preload headers, potentially we could be a lot better using server push from http2/3 but that's another project for another day since HTTP3 isn't well supported in go yet and it's already much better than before

[sevmonster]

This is amazing. In today's dependency hell clown world, it's incredibly refreshing to see someone working toward a more sane benchmark instead of digging themselves deeper. Good work.