3 ms·

I experimented with various approaches to client-side data handling and ended up realizing that I do not want a client-side database at all. I'd much rather hol

by jwr 6y ago

I experimented with various approaches to client-side data handling and ended up realizing that I do not want a client-side database at all. I'd much rather hold data in language-native data structures (in my case, Clojure/ClojureScript). These are very powerful and there is zero impedance mismatch: after all, they are a part of the language. Yes, you do need queries, but there are not many and they might as well be coded as functions. You can do all the indexing you want, if you need to, but JavaScript in browsers is so incredibly fast these days, that even a linear search works well for most cases. Unless you are handling gigabytes of data client-side, of course. But that wouldn't make much sense. Data modification needs to go through a server API anyway, because the client environment can't be trusted, so two-way sync would be useless. I want the server to perform data model operations while verifying everything, I do not want data sync.

dsun180 6y ago
If you do not need a database at all, of course you can just use the plain programming language.
treis 6y ago
>I'd much rather hold data in language-native data structures (in my case, Clojure/ClojureScript). These are very powerful and there is zero impedance mismatch: after all, they are a part of the language. >Yes, you do need queries, but there are not many and they might as well be coded as functions. You can do all the indexing you want, if you need to, but JavaScript in browsers is so incredibly fast these days, that even a linear search works well for most cases. That's just a bad database. It will work for small amounts of data and simple queries. But add in something complex or lots of data and it will fall over.
- mumblemumble 6y ago
  In theory, if it's all in a single application's memory and using langauge-native data structures, then you have a lot of power to tailor the data model to meet your application's needs. Barring concerns like object overhead (which I realize is a major consideration in languages like JavaScript and Clojure), you should be able to come up with something that is more efficient than a general-purpose solution like a database without too much trouble. It's really just a special case of the Chuck Moore style, "I coded my own $thing in 1/10 the code and 10x the performance of the popular off-the-shelf option, in a week. NBD, it's easy if you simply choose not to implement any of the features you don't need." thing. Where DBMSes truly shine is working efficiently with data that you can't or don't want to keep in memory all at once, or for which lots of different clients need concurrent access. The first of those (but hopefully not the third) are absolutely considerations for certain kinds of browser apps, but maybe not something the parent was worrying about.
phaedrus 6y ago
I've long thought there's a potentially-useful/missing piece of software infrastructure that's midway between code or data-written-as-code and a full blown database (even one as small as Sqlite).
m_fayer 6y ago
I can see this being sufficient as far as performance and development-ergonomics. But. I would miss the safety and durability of a (preferably relational) database. In the end, what I would gain in convenience and development speed I would lose in having to build my own guardrails.

by jwr 6y ago

dsun180 6y ago

If you do not need a database at all, of course you can just use the plain programming language.

treis 6y ago

>I'd much rather hold data in language-native data structures (in my case, Clojure/ClojureScript). These are very powerful and there is zero impedance mismatch: after all, they are a part of the language. >Yes, you do need queries, but there are not many and they might as well be coded as functions. You can do all the indexing you want, if you need to, but JavaScript in browsers is so incredibly fast these days, that even a linear search works well for most cases. That's just a bad database. It will work for small amounts of data and simple queries. But add in something complex or lots of data and it will fall over.

mumblemumble 6y ago
In theory, if it's all in a single application's memory and using langauge-native data structures, then you have a lot of power to tailor the data model to meet your application's needs. Barring concerns like object overhead (which I realize is a major consideration in languages like JavaScript and Clojure), you should be able to come up with something that is more efficient than a general-purpose solution like a database without too much trouble. It's really just a special case of the Chuck Moore style, "I coded my own $thing in 1/10 the code and 10x the performance of the popular off-the-shelf option, in a week. NBD, it's easy if you simply choose not to implement any of the features you don't need." thing. Where DBMSes truly shine is working efficiently with data that you can't or don't want to keep in memory all at once, or for which lots of different clients need concurrent access. The first of those (but hopefully not the third) are absolutely considerations for certain kinds of browser apps, but maybe not something the parent was worrying about.

phaedrus 6y ago

I've long thought there's a potentially-useful/missing piece of software infrastructure that's midway between code or data-written-as-code and a full blown database (even one as small as Sqlite).

m_fayer 6y ago

I can see this being sufficient as far as performance and development-ergonomics. But. I would miss the safety and durability of a (preferably relational) database. In the end, what I would gain in convenience and development speed I would lose in having to build my own guardrails.