Comment by goku12

Comment by goku12 2 days ago

The actual problem with Sandstorm wasn't the era in which it was released. It will probably have the same problems even if released today. The problem was its application isolation mechanism - especially the data isolation (I think they were called grains). The mechanism is technically brilliant. But it's a big departure from how apps are developed today. It means that you have to do non-trivial modifications to web applications before they can run on the platform. The platform is better for applications designed to run on it in the start. It should have been marketed as a platform for building web applications, rather than as one for just deploying them.

kentonv 2 days ago

Agreed. The best apps turned out to be the ones written for the platform. And many of those took people an afternoon to write, since the platform handled so much for you. Porting "normal" apps into Sandstorm felt like it defeated the purpose.

If I did it again I wouldn't focus on portability of existing apps. Especially today given you could probably vibe code most things (and trust the sandbox to protect you from AI slop security bugs).

Reply View 1 reply

goku12 15 hours ago

+1. Thank you for that fantastic effort! I followed the project since its earliest public announcement. I had high hopes for it, until it became clear that the porting was going to prove troublesome.
I'm not a big fan of the contemporary app hosting architecture, as it feels needlessly complicated. But if this entire discussion thread is any proof, it's that people rarely choose the most elegant ideas around. Instead, decisions are very often based on marketing clout.
Still, I hope that your concept finds its rightful purpose and mindshare in the future. It's encouraging to hear that it's a fantastic app framework. It would be such a shame to squander such a big advantage. Perhaps, that's the reason why your collaborators are so adamant about keeping it alive.

Reply View | 0 replies

ocdtrekkie a day ago

I think mistakes were made in not making it easier to adapt applications. (I disagree with Kenton's opinion this is futile, there are plenty of alternative systems which require bespoke apps, and if anything Sandstorm's biggest problem was not having enough name-brand ported apps working on it people expected.)

For example, making external network requests from a Sandstorm app is hard by default. Years after it was "dead", Ian Denhardt wrote a simple drop-in tool you could include in an app which would use a conventional HTTP proxy to hijack the requests from the app and turn them into Powerbox requests. Even though it isn't "the best" way to do it, it is very serviceable and approachable to devs. I think it's something Sandstorm should've supported by default, to abstract away that challenge.

The funny thing is, Sandstorm is actually kinda a pain if you know the engineering you want to do but the platform restricts you from it: It's actually much much better at nontechnical users just being able to use finished apps. I don't think the "use Sandstorm as infrastructure" story is nearly as good. The original Sandstorm company wasn't running a lot of their own infrastructure on Sandstorm, and some of it that was required hidden hacks to work around some of the big ways Sandstorm isn't really designed for hosting websites.

I still don't think it's dead, but since everyone who still really wants to work on Sandstorm has bills to pay and jobs to do (and kids to raise), we definitely aren't moving super fast.

Where I do agree with Kenton is that Sandstorm really excels at running vibe coded apps, I've been playing with it, and found it very easy to get AI tools to fix apps up for Sandstorm. And of course, a sandbox that only runs when the user is interacting with it and manages all of the authentication for you is the safest place to run untrustworthy code that may have security or performance bugs.

Reply View 0 replies