[HN Gopher] Web Applications from the Future: A Database in the ...
___________________________________________________________________
Web Applications from the Future: A Database in the Browser
Author : w1nter
Score : 34 points
Date : 2021-06-07 16:31 UTC (6 hours ago)
(HTM) web link (stopa.io)
(TXT) w3m dump (stopa.io)
| ampdepolymerase wrote:
| 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.
| whoisnnamdi wrote:
| This 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!
| eyelovewe wrote:
| We had Meteor with "mini mongo" and you locally subscribed to
| streams and it was all a quite bloated POS 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
| hootbootscoot wrote:
| 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"
| hootbootscoot wrote:
| 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/
| hootbootscoot wrote:
| 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.
| canadianfella wrote:
| > instead of pretending that cpu cycles and RAM are free.
|
| Don't pretend security is free either.
| rektide wrote:
| I 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.
|
| [1] https://news.ycombinator.com/item?id=27129858
___________________________________________________________________
(page generated 2021-06-07 23:02 UTC)