291–300 of 310 posts
This part… makes me feel odd. Is it actually realistic? Reducers for everything, keeping WASM and backend code in sync. Sounds like a lot of work and cognitive overhead.
Earlier quoted context omitted.
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.
Ohh can't wait for the inevitable next step of dropping the "web" part of web assembly and doing, ya know, native fat clients again.
Then we can write apps once and run them everywhere, desktop and mobile.
Author here. Finally got through most of the questions, will keep checking periodically for ones I've missed (has someone built a better way to track HN discussions?). I'm very happy to see the discussion thus far. This first post focused on the parts of frontend engineering that motivated me to create SQLSync rather than specifically how SQLSync works. I'll be addressing that in my next post. Thanks for all the grea…
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…
I wish Postgres had a stable, more low-level API than SQL. Perhaps something that resembles the query plan I get from EXPLAIN. An application written against this API could implement an SQL DB: (1) parse SQL (2) implement a query planner that spits out a query plan written against this API.
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…
I would love to be able to say e.g.: this column is either a PK in the “results” table or a PK in the “errors” table.
Earlier quoted context omitted.
I've used Meteor. I thought it was a good system. It didn't have offline capability, at least not back when I used it. It really needed to be connected to work. But conceptually, yes, it had a very similar system.
If Meteor could scale, we'd probably hear about it way more these days. I remember having problems with 200 users serving from my above average dev pc for testing internal tools. It's a DX dream though.
Earlier quoted context omitted.
If Meteor could scale, we'd probably hear about it way more these days. I remember having problems with 200 users serving from my above average dev pc for testing internal tools. It's a DX dream though.
Meteor works fine. We've served tens of thousands of concurrent connections on a low grade EC2 instance with some apps.
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…