Over the past year I’ve had a steady stream of emails asking if a Fileside version 2 is coming. One even wondered whether the project is still being maintained. The short answer is yes. Fileside 2.0 is deep in development and will be the biggest upgrade yet.

The need for a rework

Building a new piece of software from scratch is always a learning process. When starting out, you can’t yet know what you don’t know, and yet you have to make decisions that will affect those unknowns.

As you gradually figure out the details of how each feature should work, you get a better and better idea of what the supporting architecture needs to look like. New ideas and requirements also pop up throughout, which might not always fit that well into the stucture you devised at the beginning.

Predictably, as the 1.x series progressed and evolved more features, they increasingly had to be shoehorned into a less than ideal code infrastructure.

With this new knowledge in the bag, we have a better chance of doing a better job of it the second time around. “Plan to throw one away” as someone wise said. Thus, Fileside 2 is a fundamental rearchitecture that lays the foundation for the next several years of development.

What to expect

The initial 2.0 release won’t ship full of new bells and whistles straight away. But it will have the capabilities needed to eventually build everything that’s needed to reach file management nirvana. I’m planning a pragmatic approach here of progressively adding new features on top of this foundation during the 2.x series (while taking feedback on board), rather than incurring a lenghty delay to deliver a jam-packed initial version.

The scope of 2.0

Having said that, the following oft-requested new features are planned for the initial launch:

• Gallery view: A grid view for visually scanning thumbnails of media files.
• Reworked layout management: Layouts that work more like documents in an editor with auto-saving dirty and clean states.
• Non-blocking file transfers: Copying and moving will happen in a different process to avoid blocking the UI.
• Navigation history: Back and forward actions for locations separate from undo history.

There will also be much that you won’t see directly, but rather feel: smoother running overall, and fewer mysterious hiccups due to sub-optimal application state handling.

The scope of subsequent releases

Once 2.0 is done and dusted, some possible future features with foundations already laid are:

• Flexible query system: Express what you want to see, rather than just the location. E.g. advanced search, flat recursive listings, recent files views etc.
• New item types: View other types of items like network drives etc.
• New scape types: View items as tables, lists, trees, columns etc.
• File system adapters: Browse other storage systems, like Android phones or FTP servers.
• Tagging and colour coding: For both files, folders, panes and layouts.
• Extended metadata: Format-specific metadata for media files etc.

Peeking under the hood

This section goes into some technical detail. Feel free to skip ahead if you’re not a nerd.

Client-server architecture

For its sins, Fileside is based on the cross-platform software development framework Electron. It has its pros and cons, and I still believe the pros outweigh the cons, so it’s staying for v2. However, it has changed enormously since 2018, when the first lines of Fileside code were written, and now mandates a whole different client-server architecture than what was the case back then.

Therefore, Fileside needed to be split up from a monolith into a distributed application that handles the UI aspect in a set of renderer processes (clients), and everything else in a server process (main). All communication between them needs to be shuttled over an inter-process communication (IPC) channel.

Generic abstractions

While starting to break things up, I also took the opportunity to remodel the domain abstractions Fileside works with to become more general and flexible. Fileside can now be thought of as a generic viewer/editor of collections of items (e.g. files, folders, drives) presented through different scapes (representations such as table, grid, tree), living inside panes organised into layouts.

This will make it easier to add more item and scape types going forward.

Dependency-injected services

Taking a cue from the architecture of Visual Studio Code and the principles of Clean Architecture, every distinct piece of functionality (or module) is now an independent unit managed through a dependency injection system.

The result is a codebase that’s more robust, and safer to extend and modify without risking introducing new bugs. It opens the path for more advanced features without turning the code into a popular Italian dish.

Timeline and expectations

I’ve been telling people that the goal is to have the new version out before the end of 2025. That is now looking unrealistic. More likely is a public beta starting early next year, followed by a solid 2.0, and thereafter a steady cadence of 2.x releases over the succeeding months.

The timeline below represents the current state as of 1 October 2025.

I had high hopes that AI coding agents could help speed up this process, but they are still best suited to greenfield projects, and require very careful guidance when deployed to refactor existing code.

Thanks for your patience and for all the thoughtful emails. Back to building.