Live data from Hacker News

Accidental database programming

sqlsync.dev

181–190 of 310 posts

Re: Accidental database programming

#181

Question: what's the browser compatibility?

Currently got it working across Safari/FF/Chrome + iOS Safari + a couple android devices I was able to test. Requires fairly recent versions everywhere though. You can test out your own device using this demo: https://sqlsync-todo.pages.dev/

Please file an issue if you find it fails somewhere :)

Re: Accidental database programming

#182

Earlier quoted context omitted.

I took a close look at htmx, and my impression is that the problems it addresses can be resolved with even fewer than its 4000 lines of JS [1], and without having to familiarize myself with its many opinionated approaches. The crux of the matter is to generate HTML on the server, as much as possible. I know how to achieve that without htmx. The marketing materials for htmx are also a bit off-putting to me, and the au…

i don't think htmx is very opinionated: it generalizes hypermedia controls in HTML and that's about it. No strong opinions on how you use it beyond that, can work reasonably well w/ any back-end that produces HTML. The goal is to expand the set of UI use cases that can be cleanly expressed in HTML w/o resorting to (user) scripting. Yeah, htmx is 3800 LoC, and you could do an 80/20 version of it for a lot less, but th…

My tone was a bit strong—my bad! I appreciate your thoughtful response. I must add I realize running an OSS project and writing a book is a massive effort. Big respect for not just sharing ideas but actually implementing them.

Re: Accidental database programming

#183
post #113

Earlier quoted context omitted.

It solves so many problems and makes it so easy to implement if you go this way. But just like mentioned it is hard to convince people that it is what they actually want. People fall into some grand illusion that everything should be always available but in reality then one person is doing changes at a time and if somehow 2 or more people have to work on something - more often than not they should be talking or commu…

you can only have one person work on the code at a time? that seems, very very obviously dumb

[deleted]

Re: Accidental database programming

#184
post #75

An old company I worked for used project management software with a check-in/out mechanism for making changes. When you "check out" a project it downloads a copy that you change locally, then "check in" uploads it back to the server. A project is "locked" while in the "checked out" state. We all felt it was an archaic mechanism in a word of live updating apps. After 10 years of building SPA "web apps", that data sync…

Sounds like Lotus Notes.

CouchDB is a lineal descendant I guess.

Re: Accidental database programming

#186
I misinterpreted the title, I clicked because I thought it was literally about how we should stop building and designing more actual databases, which is something that I agree with and is perhaps a hotter take than the one in the article.

There are hundreds of subtly different database out there, but there are only a dozen or two that really ought to exist. So stop making new databases for every little thing folks. They are

Re: Accidental database programming

#187
post #151

Earlier quoted context omitted.

Not the GP, but I would include optimistic rendering on the list of common patterns that really are a bad idea. Optimistic rendering means your frontend and backend are tightly coupled, error recovery and synchronization is much more complex, and you are locked into (likely heavy) frontend rendering patterns that add even more complexity and coupling. We've spent well over a decade trying to avoid the fact that front…

the real UX goal is to minimize data loss (ie. provide the ability to resume whatever the user was doing, from a point that's as recent as possible), and for this it becomes necessary to provide "auto-save" at that point there's already a diverging state problem, even if it's saved to localStorage (but obviously it's much better to save it on the server) it's absolutely ridiculous that we spent the last 10+ years sim…

> the real UX goal is to minimize data loss

Can't say I've been asked to build optimistic updates for that reason, but the irony there is pretty rich if that's the UX goal you've seen it used for.

In my experience optimistic rendering actually creates more data loss risk than it solves. Caching layers are involved, state is duplicated, and routing comes into question as users could leave the page before a failure state is returned.

Re: Accidental database programming

#188

Earlier 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.

I'm on the fat client train with my company and I nudge my clients that way if they're open. It's just a great way to build a system.

Great until you have to support n versions on m platforms and half your customers are enterprisey and stay on a 6-year-old version from before your last LTS version on a now-unsupported platform because they built a core part of their business processes on a a misfeature.

Re: Accidental database programming

#189
post #88

Earlier quoted context omitted.

And, of course, the default mode of Microsoft Team Foundation Server [0], decades after there were better patterns. So many forgotten locks from lazy devs... [0] https://en.m.wikipedia.org/wiki/Azure_DevOps_Server#TFVC

Back in the early days of TFS I was briefly at a company that went all in on MS tools. TFS was used and to avoid the lock each developer had a clone made and after checking their clone in the “TFS Guy” in the office would merge it. He also had to merge things when later checking had conflicting changes. Now, the best part of this shit show was they had ~30 different customers and each of these customers had a clone o…

That sounds like torture, he deserved that money.

Re: Accidental database programming

#190
post #173

Earlier quoted context omitted.

This isn't a problem of only websites. Should mobile and desktop ecosystems start making a big move for thin-client like the browser? Should a simple app like Apple Reminders or Google Tasks have the GUI pause if there are delays or connection issues?

> Should a simple app like Apple Reminders or Google Tasks have the GUI pause if there are delays or connection issues? Yes, they should, because I _need_ good feedback for connection issues. I have not used those two specific apps, but for other "online first" apps it's such a common problem. Open an app, type a note, switch back to a different app (or turn off your phone, or close laptop lid). Later on, you want to…

I think my preference is that it works instantly, but have some sort of indicator that it is syncing working. Users should be able to see when it is safe to assume state is consistent with what is on the server.
Post reply on HN