Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Accidental database programming

sqlsync.dev

Post reply on HN
Print view View original

251–260 of 310 posts

Re: Accidental database programming

#251

Post by FridgeSeal »

qudat wrote: post #196
FridgeSeal wrote: post #119

Earlier quoted context omitted.

I don’t know what SPA’s you have the pleasure of using, but most SPA’s I’m subjected to are an exercise in molasses like interactions and loading spinners.

Yeah, they are building SPAs incorrectly by relying on something like `react-query` which is waterfall rendering land. People don't truly understand the sacrifice they are making by using `react-query`. It isn't designed for large scale SPAs, it's designed for small sites that just need to fetch a little data.

I can’t help but feel, if SPA’s keep getting “built wrong”, then at some point, we ought to look at why people keep building them wrong.

Re: Accidental database programming

#252

Post by HatchedLake721 »

no_wizard wrote: post #40
HatchedLake721 wrote: post #4

Unless I misunderstood, feels like I’ve been doing this with Ember Data since ~2013. https://guides.emberjs.com/release/models/ There’s also https://orbitjs.com/

Ember.js has had more innovations contributed to modern framework ideas than any other framework, really. EmberData, Ember Routing, Ember Multi Applications (can't remember what its called, but its a precursor to microfrontends) all in one CLI tooling etc. I could never understand what holds Ember back from being more used. I think it used to be performance but I think they addressed that with Glimmer many years ago.

Ember Engines :)

It's not being used more for the same reason Ruby on Rails is not used more.

Both are batteries included frameworks, with a much steeper learning curve than e.g.

https://cdn.com/vue.js">

Plus people like to tinker and wire up things together themselves, like router, rendering, state management, testing, etc. That's more exciting than `ember new project`.

I was like that 10 years ago too, but now when I learned the ropes I just want to focus on shipping and providing value, rather than wasting my life wiring up 17 javascript packages of the month together.

Re: Accidental database programming

#253

Post by Multicomp »

slaymaker1907 wrote: post #190
theamk wrote: post #173

Earlier quoted context omitted.

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

And thus we get back to the need for Exchange Active sync icon from the Pocket PC era! I have finally lived long enough to see a full tech cycle go from new hotness to duh everyone does it this way to a good if boring option to that's so lame and worse, legacy, to what's that?

Re: Accidental database programming

#254

Post by holoduke »

lmm wrote: post #241
holoduke wrote: post #231

Earlier quoted context omitted.

What is exactly hard about sql? Every dev imho should know it. And sql syntax is good and proven too be long lasting. Maybe investing some time in actually learning it instead of bashing it will help you further.

> What is exactly hard about sql? - No non-nullable types (at the expression level). No way to express e.g. normal boolean logic - No real data structures (at the expression level), unless you count rows, which are not first-class values. Even collections aren't first-class - Very awkward control flow constructs. E.g. look at how you write recursive queries. Even if/else is weird. It's a classical Turing Tarpit: ever…

If you run into issues with non nullable types and missing of real data structures then i guess you dont get the purpose of SQL and its tech. Its a query language to retreive data. thats the only purpose. With under the hood a crafty machine that enables atomic principles and depending on the sql tech other different functionalities like scalability and more.. No Libraries? There are a zillion battle tested libs out there. Some are used by companies like Paypal, SpaceX, Tiktok, youtube, Gmail and many more. And why you would unit test datasets in a database? You normally use mocks to test against your data layer. Most if not all software stacks have mock libs available.

Re: Accidental database programming

#256

Post by naasking »

barumrho wrote: post #204
vemv wrote: post #62

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

Only for some class of websites with limited interactivity. On iOS/Android, before all the WebKit apps took over, many apps would use a local SQLite database to support offline edits and implement a syncing protocol to the server. It's a lot of work, but the end product can be quite handy. (This is how you'd expect your email client to work, for example.)

"Limited interactivity" is misleading. It allows much broader interactivity than you think, and arguably most sites and apps would work just fine in this context.

Re: Accidental database programming

#257

Post by naasking »

willsmith72 wrote: post #155
pas wrote: post #141

Earlier quoted context omitted.

I'm not a HTMX believer, so excuse my potential ignorance, but as far as I know the whole principle of HTMX is to keep things so simple that things cannot go out of sync. (Mostly because HTMX is basically a set of locally cute JS snippets helping with managing the very local interaction/state of a "user clicks button -> JS disables button, sends request to backend, waits for response, puts response somewhere in the D…

so for a typical spa, you can: 1. always refetch data. always in sync, but needs a server request, so it's slow. 2. cache some data on the client. faster, but you're "building your own database". can get out of sync (redux) 3. NEW: use SQLSync. fast, client & server stay in sync, don't have to "build your own database" what you're describing just seems like number 1, right?

> 1. always refetch data. always in sync, but needs a server request, so it's slow

Except you're not fetching data in htmx, you're fetching hypertext. This is an important distinction. With a JS app you fetch data, integrate it into some local data structure that is then rendered into some form that generates HTML that the browser then renders. With htmx, all of those steps happen in the (faster) server, and the client only receives and renders the HTML. The client-side steps are faster.

Furthermore, apps end up structured differently because you're not querying fine-grained data.

Re: Accidental database programming

#258

Post by GuB-42 »

roenxi wrote: post #102

There is an interaction here between the "what gets measured gets managed" principle and the sunk cost fallacy. The problem with databases is actually complexity. Any individual feature is more or less safe, but around the time reliability, caching and indexes get matched together there is a complexity explosion and it doesn't (normally, anyhow) make sense to implement a domain-specific DB (call is a DSD?). But, arou…

SQL often gets criticized, and I think for good reasons, but why didn't we come up with something better?

We have dozens of programming languages in use for general programming, it is a field that is constantly evolving. Even JS, which is hard to change because that's what browsers run and you don't control your client's browser is seeing some evolution, using transpilers, and now WebAssembly.

But for databases, there is only one, and that SQL. There are some alternatives, but no one comes close to SQL in terms of usage. So maybe SQL is not that bad after all.

Maybe the reason is that the relational model is really good, and attempts to deviate from this will only work in a niche. That a declarative style is also really good, and again, you won't have much success if you deviate from this. And if you end up doing SQL with a different syntax, for most people, it will be too small of an improvement to justify changing their way.

Re: Accidental database programming

#259

Post by mst »

frenchman99 wrote: post #247
mst wrote: post #124

Earlier quoted context omitted.

Could you clarify which of: - page storage - reducers - replaying mutations - acks you're unclear on?

In that context, I don't understand the word reducer.

The reducer takes objects representing mutations and applies the appropriate changes to the state.

It's called a reducer because it operates like a reduce/fold operation, in that if you take a given state and an ordered list of mutations, you'll end up with a new state out the other side, much like 'let newState = list.reduce(reducer, initialState)' would in JS.

The reducer model is how Elm's state management works, and Redux's, and is what allow replaying of subsequent changes against a previous state to get to a current state (which enables, amongst other things, some the features of those systems' respective dev tools).

The article links to the (nearly trivial) reducer for the todo example, which is on github here: https://github.com/orbitinghail/sqlsync/blob/ba762ce2a10afbb...

Re: Accidental database programming

#260

Post by BackBlast »

eternauta3k wrote: post #249
BackBlast wrote: post #205

Earlier quoted context omitted.

I work with lean, business speculative software mostly. Which means not cross-platform native development is simply not economical to do. I generally need to be able to hit Windows, iOS, Android, and MacOS square on with one code base. A "native" electron or capacitor distribution system is a fine extension of a local-first web client. And an advantage of building fat clients generally is they lend themselves to such…

Why not Java?

Java fails on multiple points.

First, my list failed to include web because of the context. Web is, by far, the largest and most important platform. Even if I'm building only native installers for a project, I need to be able to build web projects with the same tools to make this work.

Java also fails "one code base" requirement as desktop and mobile are very different. The poor iOS support is going to cause it to fail the "square on" requirement as well.

No on Java.

Post reply on HN