Live data from Hacker News

Web Applications from the Future: A Database in the Browser

stopa.io

11–20 of 75 posts

Re: Web Applications from the Future: A Database in the Browser

#11
Having been a dev on EtherPad, Google Wave, Coda, and other real-time collaborative apps with OT, undo, and so on...

I think it's correct that, ideally, there would be a framework that handles real-time collaboration, undo/redo, and offline support for you, and then you build your app with these problems already solved. I will probably create such a framework eventually. I don't see it as a database engineering problem, it's more like a framework or application architecture, which every app like Google Docs or Figma has its own version of. Writing such a framework is not too much harder than writing such an app, it just requires a little more abstraction and some documentation.

If you've never written an undo manager, sync engine, etc., and you aren't writing a complex app, it's hard to arrive at the right design by thinking about pure data sync. Also, storing and querying data are solved problems; it's more a question of coming up with a generic data model for an application and defining its semantics.

Re: Web Applications from the Future: A Database in the Browser

#12

We had Meteor with “mini mongo” and you locally subscribed to streams and it was all a quite bloated PÓS IIRC. At some point someone will make a virtual browser that runs in the browser, or maybe a kubernetes that runs in the browser and the circle of ironic self referencing will be complete. Just replace the browser and use ports 80 and 443 and be done with it, instead of pretending that cpu cycles and RAM are free.…

> or maybe a kubernetes that runs in the browser and the circle of ironic self referencing will be complete

https://blog.stackblitz.com/posts/introducing-webcontainers/

Re: Web Applications from the Future: A Database in the Browser

#13

Not a single mention of CRDTs or operational transforms in the article. If all you need is a client side database to replicate Figma and Google Docs then they would have long shut down.

"as long as we’re okay with having a single leader, and are fine with last-write-wins kind of semantics, we can drastically simplify this and just facts are enough"

It's not a direct reference to CfRDTs or operational transforms. They're not wrong that last-write-wins is easiest to implement, but some applications it doesn't quite cut it.

Re: Web Applications from the Future: A Database in the Browser

#14

Having been a dev on EtherPad, Google Wave, Coda, and other real-time collaborative apps with OT, undo, and so on... I think it's correct that, ideally, there would be a framework that handles real-time collaboration, undo/redo, and offline support for you, and then you build your app with these problems already solved. I will probably create such a framework eventually. I don't see it as a database engineering probl…

Where would one go to follow along if you start building this framework? You’ve got one pending GH star from me :)

Re: Web Applications from the Future: A Database in the Browser

#15
post #14

Having been a dev on EtherPad, Google Wave, Coda, and other real-time collaborative apps with OT, undo, and so on... I think it's correct that, ideally, there would be a framework that handles real-time collaboration, undo/redo, and offline support for you, and then you build your app with these problems already solved. I will probably create such a framework eventually. I don't see it as a database engineering probl…

Where would one go to follow along if you start building this framework? You’ve got one pending GH star from me :)

+1. I would even pay to watch you code this.

Re: Web Applications from the Future: A Database in the Browser

#16

We had Meteor with “mini mongo” and you locally subscribed to streams and it was all a quite bloated PÓS IIRC. At some point someone will make a virtual browser that runs in the browser, or maybe a kubernetes that runs in the browser and the circle of ironic self referencing will be complete. Just replace the browser and use ports 80 and 443 and be done with it, instead of pretending that cpu cycles and RAM are free.…

Backend devs, meanwhile, wonder where their Frontend as a service is... "backend as a service" = "can you just, like, do that magic CRUD stuff or whatever you do"

I've always thought of apps like Retool as a Frontend as a service, and even as a mostly-front-end-person I've started using those more

Re: Web Applications from the Future: A Database in the Browser

#17
post #14

Earlier quoted context omitted.

Where would one go to follow along if you start building this framework? You’ve got one pending GH star from me :)

+1. I would even pay to watch you code this.

Didn’t know there was a market for coding session watchers. Let me know if someone’s interested in watch me slow-code my current long running side project: Focusly.

Re: Web Applications from the Future: A Database in the Browser

#18

Not a single mention of CRDTs or operational transforms in the article. If all you need is a client side database to replicate Figma and Google Docs then they would have long shut down.

"as long as we’re okay with having a single leader, and are fine with last-write-wins kind of semantics, we can drastically simplify this and just facts are enough" It's not a direct reference to CfRDTs or operational transforms. They're not wrong that last-write-wins is easiest to implement, but some applications it doesn't quite cut it.

Most CRDTs (last-write-wins being one of them) will result in a terrible user experience, and nobody would want to use it for collaboration. That's why most of these collab systems use OT, which is not trivial to implement.

Re: Web Applications from the Future: A Database in the Browser

#19
this comment turned into a bit of a personal rant, apologies.

I really liked this post, because it touches on so many things that I have to build as well at the moment. I'm building a configuration management interface; the front-end is basically authentication and heaps of forms, the back-end transforms it into XML and uses some shell scripts to rsync them to servers and SNMP to trigger a deployment. But the users have worries about overwriting each other's work, they ask for undo / revert support, and there's things like audit logging, user and permissions management, etc involved.

At the moment I'm slowly building all of that with a React/TS front end and a Go backend using a REST API, just trying to be as tidy and complete as possible. But it's a lot of work, and I'm afraid that once I get to things like versioning, locking, undo / revert, auditing and permissions, my fairly straightforward codebase will just explode in complexity, with each endpoint having loads of documentation and code to represent the different concerns. Client- and server-side validation is another concern, importing existing data, migrating user data from a staging to production environment, etc.

It's a lot. It's a project that should be done by a full team of developers, maybe even multiple but ATM I'm doing it on my own.

I'll never finish it. I'm currently trying to plough through and make sure everything is set up, but I'm hoping we'll get a big financial injection and I'd be able to hire a bunch of consultants (that I'm familiar with as being decent if expensive developers).

I don't know how the previous guy managed to get as far as he did on the older version, other than being a mediocre but productive and persistent developer for all that time, seeing the whole thing grow over time instead of trying to reach feature parity with a product nine years in the making.

Re: Web Applications from the Future: A Database in the Browser

#20

Not a single mention of CRDTs or operational transforms in the article. If all you need is a client side database to replicate Figma and Google Docs then they would have long shut down.

"as long as we’re okay with having a single leader, and are fine with last-write-wins kind of semantics, we can drastically simplify this and just facts are enough" It's not a direct reference to CfRDTs or operational transforms. They're not wrong that last-write-wins is easiest to implement, but some applications it doesn't quite cut it.

last write win isn't that easy either, it's easy only if you ever only send the full data at each write, which is not a great system for large data.
Post reply on HN