Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> we haven't solved getting people a server easily

It doesn't help that Sandstorm focuses on apps that are architected with a devops-heavy mindset. Many apps don't really need anything more complicated than PUT and DELETE (no POST special handling required), esp. since they're already doing so much on the client, anyway. This really calls for an auth-protected document store more than it does what Sandstorm tries to provide; the difficulties of "getting people a server" probably starts with assuming/insisting that that's what you need to do in the first place.

Those kinds of architectures are only necessary when you really do need some way to offload computation to a remote, high-availability machine, but things like online image and document editors aren't that. (Even then, what you really want for that is some sort of mobile code architecture that lets you squirt lightweight payloads at some sort of fleet of faceless workers, preferably in the same/similar form to the kind of code that you write for doing useful work on the client...)



I really don't agree. I think loading a bunch of client-side crud from a random web server and storing it in opaque browser buckets is super untrustworthy. I think to some degree modern web app development has gone off the rails a bit.


Why are you moving the goalposts (ignoring the premise)? Sandstorm apps (like e.g. Etherpad, advertised right on the front page) aren't already doing lots of client-side work (locally), like I originally said?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: