Show HN: Grist, a Hacker Friendly Spreadsheet(getgrist.com)
getgrist.com
Show HN: Grist, a Hacker Friendly Spreadsheet
https://www.getgrist.com/blog
23 comments
Grist contributor here -
I got onboard 3 years ago right after Dmitry made a demo to me. What truly impressed me right from the beginning was the UI and how easy it was to build advanced views by simply using linking between records. To me, this plus the python formulas and the sqlite storage put together shows great potential to achieve distributed data management properly.
Note that it was even possible at that time to run Grist standalone using electron and to bring your data offline with you. It had been deprioritize and the feature had to be put on the side for a while. But it does not seem to hard to bring it back.
I got onboard 3 years ago right after Dmitry made a demo to me. What truly impressed me right from the beginning was the UI and how easy it was to build advanced views by simply using linking between records. To me, this plus the python formulas and the sqlite storage put together shows great potential to achieve distributed data management properly.
Note that it was even possible at that time to run Grist standalone using electron and to bring your data offline with you. It had been deprioritize and the feature had to be put on the side for a while. But it does not seem to hard to bring it back.
Yup, and in the meantime there's a docker image https://github.com/gristlabs/grist-core#opening-and-editing-... (hi Cyprien! waves in French)
Paul, Dmitry, thanks for the link, the idea of an SQLite-backed spreadsheet with Python for computations looks quite enticing.
Right now, the spreadsheet is unworkable (formulas are updating where I don't want them to, visual editing glitches), hope you iron out the bugs.
Right now, the spreadsheet is unworkable (formulas are updating where I don't want them to, visual editing glitches), hope you iron out the bugs.
For formulas: could it be that Grist formulas are per-column rather than per-cell? This can take a little getting used to, but we think it leads to neater spreadsheets, and there are other features that can take up the slack that mixed-content columns used to (like multiple views within a page/tab). Sorry you hit editing glitches - thanks for letting us know, and if you have the time I'd like to hear more here or via the "give feedback" button in the app. Cheers!
Ah, this explains a lot, sorry for the confusion. It's an uphill battle to make folks drop their ingrained Excel habits, though.
Column-wide formulas are an example of Grist data being more structured than a traditional spreadsheet. In a spreadsheet, one might type over a cell because it's an exception. In Grist, you'd need to think what makes it special, and
change the formula to reflect that. E.g. `=$Price - $Discount if $Status != 'Comped' else 0`. But once that exception is turned into a rule, it applies to all records. Which is a good thing.
cto here - I signed up to work on Grist because I like the UI, like it as a spreadsheet format, and think it has potential for decent version control - something lacking in data projects, and that I've been interested in for way too long - here I am ranting in 2013 https://okfnlabs.org/blog/2013/08/08/diffing-and-patching-da...
Great tool guys. I've been dreaming of such a flexible but convenient tool. The existing tools like Airtable, Coda or Notion are good up to certain point, but allowing Python functions really open up a higher level.
>> Grist tables are literally SQLite tables.
So whenever a new form/table is created, is it getting stored within a sqlite table on your backend ?
So whenever a new form/table is created, is it getting stored within a sqlite table on your backend ?
Yes, a new table in your spreadsheet is stored as a new sqlite table, plus some metadata about it in some other administrative tables. You get all of this as a standalone, round-trippable file when you download your spreadsheet.
That is cool. I have so many projects with sqlite but all on my local machine. Is it possible to import an sqlite ?
Also could you help understand what happens behind the scenes in your backend & some best practices involved in using SQLite in backend. Like how do you mount them on to say to your backend if you are using docker/kubernetes.
Also could you help understand what happens behind the scenes in your backend & some best practices involved in using SQLite in backend. Like how do you mount them on to say to your backend if you are using docker/kubernetes.
Ah, we do have a general purpose importer from sqlite lurking but not published, I'll bump its priority. In the meantime, you can use the hosted or local rest api from python or javascript to generate a grist spreadsheet https://support.getgrist.com/rest-api/. On the backend, for serving individual user spreadsheets, we use node/express workers connecting to a pool of sqlite files, persisted via the sqlite backup api https://sqlite.org/backup.html https://github.com/mapbox/node-sqlite3/pull/1116. If you want to dig in, you could poke around at https://github.com/gristlabs/grist-core
Hey guys, Instead of me trying to put together Jupyter and this can I just use Python in Grist like use the Pandas and everything else? Combining this plus the magic of Jupyter seems like my dream environment now :). No need to worry about anything else :).
When running locally, you can use whatever you like, pandas or anything else, which is fun (we've experimented with some options for Jupyter integration ourselves). In our hosted service, for security we have a locked down python sandbox with white-listed libraries. Definitely on our roadmap to liberate the full power of python libraries in hosted!
I have a Ubuntu running on a WSL2 with Jupyter Notebooks already on it do you have any recommendation or any url to integrate the two it would be really cool just like you said it sound like a lot of fun :). Or do you just call them separatly?
One simple thing you can do is read a table as a data frame with:
pandas.read_json("http://localhost:8484/api/docs/<document-id>/tables/<table-name>/data")love it but it's no spreadsheet
I hear what you are saying. Spreadsheet/database hybrid vigor :)
What made you decide to go open source?
It was a combination of the value to others we could liberate by doing that, and the value it would bring to us. As Grist took shape, it felt like a nice self-contained tool (and format) that could be useful at many points in a data pipeline, given its editing, visualization, and summarization functions. And spreadsheets have a long tail of features users want, so it makes sense to open it up to collaborative development, especially given how tech-savvy our users can be.
While working at Google years ago, I co-founded a nonprofit for math enrichment classes. I ran it in my spare time, using Google Sheets, until the spreadsheet setup grew too unwieldy, time-consuming, and frustrating. Back then, I bit the bullet, and rebuilt it using Django. It took months of my evenings and weekends — just to recreate a database version of what I almost had with a spreadsheet.
That got me thinking what made spreadsheets my tool of choice to start with, and what made me switch to a database, and if we can have the best of both worlds. So we built Grist to be a “relational spreadsheet” — most of what a spreadsheet has, but with more structure, linking between records, and a flexible UI on top.
I’ve been using Grist daily, it’s now my tool of choice. I’d love to know what uses you put it to as well!