Decided to try it out. After the installation, it asks to "create the library", share the analytics and log in - not exactly what I expected compared to other file explorers. Next, I decided to navigate to a random directory on one of my drives. After double clicking, nothing happened. Opening a dir with a context menu action did nothing too. Turns out 15k files in a directory make it effectively non-navigable. Total Commander and Window Explorer have no such issues. Spacedrive still has to iron out the basic file explorer features, it seems.
Hey thanks for trying Spacedrive! The bug you're experiencing is known when browsing before adding a "Location". We index Locations ahead of time to generate a cache that makes browsing super fast, Spacedrive is, contrary to some replies here, designed for big data, we cache and virtualize everything.
Next update we'll fix the bug browsing non-locations, as those who open the app tend to try browsing first, before adding as a location it seems. It's alpha software so I hope you give us time to iron it all out!
There has to be a better strategy than caching and virtualizing to not tip over with large files. Why not just do whatever is your system's equivalent of a SQL LIMIT query? I can't think of a good reason as to why you need to index everything when the view is limited to maybe 100 files tops.
Honestly, you can't call yourself a "file explorer" if you fail the basic task of exploring files without an additional step of "adding a location" (wat?)
Also, judging from the GitHub description, it's not a file explorer. It's a slightly extended Dropbox:
--- start quote ---
From cloud services to offline hard drives, Spacedrive combines the storage capacity and processing power of your devices into one personal distributed cloud, that is both secure and intuitive to use.
We're early alpha, our product is free and open source
At the end of the day, it is an amazing experience simply just to search and organize files from not just devices, but disconnected drives. Search is lightning fast, the UI is clean and you own all the data, given its local first and peer-to-peer.
Hate it if you must, but we're super passionate about it and are ruthlessly working to reach full stability across all platforms.
Firstly, I'm not really an expert on marketing, so take what I say as mere opinion not fact.
I think that you should be pitching it a little differently: many people are confused about what your soundbite is actually saying (I also thought it was a file explorer, like all other file explorers I have even used).
Maybe lean hard into a phrase like "Unified file browser; see all files on all your devices, all at once, all the time".[1]
The other thing I would emphasise is that this isn't syncthing. You don't have to mention syncthing by name, but you could emphasise that "Your files aren't synced between devices, they're visible to all your devices".
Too many people who would otherwise use this would dismiss it with "I'm already using syncthing"! AIUI, you aren't syncing files between devices, only syncing file-listings.[2]
PS. For my own use, unfortunately, I don't need something like this. Sorry.
While it would be a nice to have in theory, it just doesn't solve any pain-points I am currently experiencing.
For example, any important document I need to read on different devices is already either in my email, or on google drive. I view movies on Netflix+AMZ+Disney+, I only ever share photos with others, not with other devices that belong to me. It's rare that I look at a file stored locally on my phone and say "I need to see this on my PC", or vice versa. It just never happens.
[1] That came out sounding super-weird: I did warn you that I wasn't any good at marketing :-)
[2] I expect you provide value on top of that, like transparently copy-n-paste between two different devices, even from a third device.
You are definitely suffering from miscommunication here. Calling it a file explorer is a bit misleading. I think what your project aims to be is really cool and very useful, but a file explorer is a secondary trait to what it actually is.
You know, I had quite a bashful [though in a good spirit] comment on your work before, but, thankfully, HN throttled me.
But thanks to your reply here now I not only can't endorse you, but I have an evidence what you really make some extremely opinionated thing and everybody else is wrong.
I can't wish you luck and I don't see myself as someone who would wait for news for this project.
Why are people pricks like this? Actually building a product and getting early feedback is literally the play book YC live and die by.
Here you are in the church of pg giving shit to people following the scriptures of pg.
Creators - ignore shit like this. Keep iterating. I like your idea, your execution will get better and better. Well done both on releasing stuff and going open source!
The explanations tell's me it's loading and interacting with remote file systems, not hosting them on their own. Which makes it different from dropbox&co., and a file explorer.
It uses Tauri which is the Rust equivalent of Electron.
I'm building an app using it now and it's significantly better than past attempts at browser-based, cross platform app development. It is extremely fast and efficient so apart from UI controls not looking the same it will be on par with a native app.
And one of the big advantages for me is that I get to leverage Rust's excellent low-level capabilities e.g. cross platform SIMD support, io_uring with minimal investment.
> t is extremely fast and efficient so apart from UI controls not looking the same it will be on par with a native app.
It uses system-provided WebView (WebKit on MacOS and Linux, and Edge on Windows) to display the UI shell, so the UI portion will be just as slow as any Electron app.
Sure but most of the issues with Electron apps aren't to do with the web layer.
It's the fact that the app is so slow to launch, consumes ridiculous amount of resources, does not take advantage of the hardware, is unstable etc. And then when you're using the app all of the interactions are slow because NodeJS's concurrency is so poor.
Rust and Tauri fixes all of those. It's not perfect but for a cross-platform app development library I've not seen anything better. Happy to be enlightened with alternatives.
It could target Win32, GTK and Qt all at compile time (even Android and OS X but that never got developed all that far AFAIK), depending what runs on your target platform, while you get common components and RAD at design time. I haven't seen anything like it since and sadly the language and ecosystem are mostly dead, which is a shame, because the idea was brilliant and it actually worked (and is still used in some software, like CudaText and PeaZip I think).
> It's the fact that the app is so slow to launch, consumes ridiculous amount of resources, does not take advantage of the hardware, is unstable etc.
You've just described almost any web-based UI ;)
> And then when you're using the app all of the interactions are slow because NodeJS's concurrency is so poor.
Most of the slow interactions come from the web-based UI. I mean, Slack needs 17% CPU to draw an animated emoji. And it's already running in a hyper optimised Chrome: https://twitter.com/dmitriid/status/1486364312910368769
I tried to build something much simpler than this.
For integration with cloud services you're going to run into OAuth, and guess what, that dance happens in a browser: get access to cloud drive -> get sent to provider login <<web>> page (or authorization page) -> get sent somewhere else.
I mean, you can build it without the browser, but a key and very early step involves a browser, you need it anyway. Might as well ship your own if you can do it.
Seems like a very nice app that works on multiple platforms, and it's even gifted to the community as open source. I don't know where you found the audacity to call something waste of time, but please keep it to yourself.
I presume that by TableView you mean List { } component. Sadly, there is no component for large horizontal lists in SwiftUI and no, ScrollView with LazyHStack is not an answer due to memory issues.
You can use one of the React-Virtualized components without the slightest idea how it works. TableView from SwiftUI is the same thing - a component that implements virtualization on top of the base GUI library for you.
React is not a UI framework, it's a low level reactive library with very limited scope - even the DOM bindings are shipped separately, and it can be used for much more than just GUI, for example VR experiences or cloud infrastructure deployment. Bring your own batteries.
The issue with the “bring your own widgets” approach in my experience is that it’s unusual for third party widget packages to have anywhere near the sort of depth and breadth of capabilities compared to the same widgets that come OOTB with native UI toolkits. This means “shopping” for the widget with the best tradeoffs for one’s particular use case and making up for whatever inadequacies it comes with yourself (or just living with the inadequacies, resulting in a crappier app), which is annoying at best.
It’s so much nicer to just be able to trust that an extensive library of stock widgets will be able to do whatever it is that you need, as tends to be the case with AppKit/UIKit.
When you're building a cross-platform app OSX isn't the weakest link. It's older versions of Windows and Linux.
And UI libraries like Tailwind, Shoelace etc are surprisingly extensive and constantly being improved. And if something isn't to your liking it's often to trivial to change it.
That'd be something provided by the Web platform (through the DOM bindings), not React. React provides a way to work with the DOM elements/native components/etc in a reactive way.
The real problem is that the Web platform doesn't offer a good set of customizable UI elements other than the most barebone basics.
Windows Explorer does struggle with many files in a directory on a HDD. It doesn't cache the sort order, so opening it with anything other than alphabetical order means waiting 5+ minutes for it to sort them.
