this was written in 2014, http://tonsky.me/blog/datascript-chat/ No offensive to any parties involved, but this seems more straight forward then re-frame. Why isn't it more widely used/talked about? 🙂 My first thought was that its because of performance
Hmm... if this is as it looks, it may be a bug. I would expect :db-before
to have count 2 as well. Maybe worth filing a GH issue (unless someone sees something I don't).
@brewmasterv I agree that a lot of docs seems to be old for DataScript and it's hard for me to get into (went through most of "docs" part here https://github.com/tonsky/datascript#resources and http://www.learndatalogtoday.org/)
and now that you mention performance, I don't remember where I read it but someone could not use DataScript due to performance reasons (I wish I could remember where I read it!)
One problem with re-frame (and Redux too) is the need for normalizing and denormalizing
With Redux you'll often use something like https://github.com/paularmstrong/normalizr for normalizing the data. This normalized data is hard to use in the view so you'll need https://github.com/reduxjs/reselect or something to denormalize it so it's easier to consume in the view
I don't see how it's different with re-frame since you want everything normalized so you'll only update one place
It's just a lot of boilerplate and the query + pull from DataScript seems to solve this problem
Thanks for explaining, i agree.
DataScript seems to support a superior fetching strategy with query + pull vs selectors
I guess it's also nice that DataScript is not tied to anything like re-frame is to Reagent in case you wanted to try Rum for example 🙂
I think this is what I remembered reading from here https://github.com/Day8/re-frame/blob/master/docs/ApplicationState.md > "We'd love! to be using datascript database - so damn cool - but we had too much data in our apps"
Datascript performance is pretty good even for somewhat largish databases. But part of the problem is that querying on a local in-memory datascript db vs data on a server db somewhere is that at a certain point you start maxing out on the amount of memory you can reasonably assume someone to have in their browser. So for such cases, submitting queries to a server for execution, and then handling the results on client becomes preferable. It can also depend a little on how many queries you end up wanting to run, but depending on your situation you can get around this by being judicious about how you organize your queries and design your app.