frontend “engineer”
Accidental database programming
211–220 of 310 posts
Re: Accidental database programming
#212Coming from the backend world, I've only done small frontends that don't get this complicated. Assuming there are legit reasons for a FE to have complex state, a relational database is probably one of the first things you need. It's almost an automatic decision on a backend to have one, same should apply here. Using SQLite instead of Redux sounds reasonable.
> Using SQLite instead of Redux sounds reasonable.
The trick is reactivity. `redux` handles surgically updating the view based state changes. It's not enough to have sqlite, you also need reactivity. Further, apply strict types on top of sqlite/SQL is another big challenge.
Re: Accidental database programming
#213No.
Re: Accidental database programming
#214Stop writing blog posts about why you should stop building databases.
Stop writing comments about blog posts that ask to stop building databases.
We can keep this going guys.
Re: Accidental database programming
#215Earlier quoted context omitted.
You’re not wrong, but the web won because it had a superior delivery system: URLs. Everything weird about the web era of development has been about contorting everything to be URL-oriented. But consider how WASM is now turning the browser into an app delivery client. Not a “html and json bodged into an app”, but a real honest to god app. This project happens to be browser based because that’s convenient place to put…
Not just delivery, but also security. Browsers offer a level of isolation and safety that you generally don't get with native desktop apps. Things like iOS do bridge the gap a bit more though
They don't, though. Browsers are almost trivial to exploit.
There have been seven (7) 0day exploits in Chrome this year (that we know of). Know how many CVEs there were for Chrome in total in 2023? Two-hundred and forty (240). That's impressive. And this is the browser people brag about as being secure.
Re: Accidental database programming
#216Off-topic, but was these diagrams created by hand or is there an app that will make hand-drawn diagrams like this?
Re: Accidental database programming
#217This seems to be one of those problems that entirely disappears by ditching SPAs. Using solutions from the Hotwire or htmx family would mean that a query is just a server query - making those fast is a better-understood problem.
“Just don’t have a highly interactive web app.”
“Just don’t run services that require more than one VM.”
It’s a ridiculous take.
Re: Accidental database programming
#218Earlier quoted context omitted.
i don't get it, how does that solve the same problem for an interactive website?
If you want new data, you just fetch it again from the server, and the server returns inherently-fresh data, reasonably fast, along with the HTML fragments necessary for a re-render (over ajax or websockets)
You’re not explaining anything that an SPA can’t do and you’re missing everything that an SPA can do that htmx can’t.
Re: Accidental database programming
#219Earlier quoted context omitted.
Yay, we're moving back to fat clients! What has been is what will be, and what was done is what will be done, there is nothing new under the sun.
Those pesky backends are so annoying, so why don't we just put a backend on every client?
Schema and data migrations are too tricky, so why not have every client do it.
Re: Accidental database programming
#220Off-topic, but was these diagrams created by hand or is there an app that will make hand-drawn diagrams like this?
I don't know what program the author used, but I'd be surprised if he did them by hand. Excalidraw (https://excalidraw.com/) will give a very similar feel.