Web Applications from the Future: A Database in the Browser
1–10 of 75 posts
Re: Web Applications from the Future: A Database in the Browser
#2I don't mind the technical discussion at all, it's a fun write-up, but if you "look at the the ecosystem of web applications and measure by difficulty" and find the most difficult possible app you can, and using that to shape your vision of how to build web apps, lionize what a web app is, I think one is very very liable to end up with a completely non-web monster that ignores many of the strongest strengths of application & site design that are possible.
Google Docs is themselves moving to canvas based rendering, which might as well be turning the screen into a giant VNC session into their codebases[1]. Web, dead, pushing pixels in people's faces, in. All the extensions that extend & enhance Google Docs are about to die, being replaced with a very small, much narrower API provided explicitly by google.
I see statements like,
> This gets me excited about whats to come, because what's at the edge of difficulty today tends to become the new normal tomorrow.
And think, please, let us not be path dependent on a web-recreation of classic desktop apps. The web is more interesting, it has online content, liveliness & connectivity to it that far surpasses the other platform's norms. Let us think of how we might advance the web for good web things. There's worth & value to examining hard problems, but I am worried that this attitude has us set out to build faster horses.
Re: Web Applications from the Future: A Database in the Browser
#3This is an incredibly well-written article and helps track and rationalize some of the trends I've been seeing as well around backends as a service that enable developers to easily spin up modern web applications
Thanks so much for writing it!
Re: Web Applications from the Future: A Database in the Browser
#4We 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. The browser is not the app platform of the future, it’s the current bandaid solution is all. I also don’t agree that this article is well written. It exclusively addresses the world according to front end dev, mulch as graphql does. I’m sorry that coding elaborate stuff requires you to keep track of your elaborate stuff. Set your global var equal to the parsed xhr.result and redraw your GUI and get over it, IMO
Re: Web Applications from the Future: A Database in the Browser
#5We 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"
Re: Web Applications from the Future: A Database in the Browser
#6We 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"
anyway, Postgrest already existed before GraphQL
Here's a frontend devs BAAS, replete with soup and desert.
(if you don't mind using db users, you even get user-auth per route...)
Re: Web Applications from the Future: A Database in the Browser
#7Earlier quoted context omitted.
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"
anyway, Postgrest already existed before GraphQL Here's a frontend devs BAAS, replete with soup and desert. (if you don't mind using db users, you even get user-auth per route...) https://postgrest.org/en/stable/
But hey, now I'm suspicious... are there Meteor dev's here?
IIRC, right on the heels of Meteor we got Apollo from the same folks...
The thing is, I'm puzzled, given the insane unnecessary complexity all this ES2030 and "build toolchains" (who knew javascript needed to be compiled, are we making binary bitstreams? is this an embedded microcontroller? is this an FPGA?) and other esoteric "let's replicate all of comp-sci in the browser" frontend tech, why on earth do such smart folks need the backend as a service? surely such folks who can deal with webpack build scripts can write a little php or ruby or java or something...? What is with this desire to completely neutralize and gut the backend stack? why on earth invert what a webserver is? Request=> Response (which might possibly be a rendered webpage) do folks actually think any of this is necessary and/or good?
Look, I'm all for web API's, web audio, webrtc, etc... I just don't see where a database in the browser is anything but 'cruisin for a bruisin'...
it's not like databases get their own dedicated servers or anything..
or do you mean something like a mobile app using pouchdb? "offline first and syncing to a single real database in the cloud as soon as one rejoins the network"
because a browser-based database can only ever be a compromise, such that a compelling reason could force it, but that's something akin to "DB per user" aka the Couch/Pouch ecosystem.
Re: Web Applications from the Future: A Database in the Browser
#8We 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.…
> instead of pretending that cpu cycles and RAM are free.
Don’t pretend security is free either.
Re: Web Applications from the Future: A Database in the Browser
#9Not 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.
Re: Web Applications from the Future: A Database in the Browser
#10You should have a look at RxDB which does exactly what you have described. Also notice that neither firebase nor supabase is really offline-first.