[HN Gopher] Grist - Open core alternative to Airtable and Google...
___________________________________________________________________
Grist - Open core alternative to Airtable and Google Sheets
Author : paulfitz
Score : 524 points
Date : 2022-02-18 22:51 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| jszymborski wrote:
| I've been looking for something like this for ages! Self-hosting
| is so important for databases; I plan on piping way too much data
| for me not to own the stack.
|
| Baserow seemed to be my best bet initially, but it seems like the
| Grist feature set is way more what I'm looking for.
| paulfitz wrote:
| Recently someone asked for a comparison of Grist and Baserow on
| their respective forums (posting the same exact question on
| both), and their founders answered. Here is the Baserow-expert
| answer: https://community.baserow.io/t/comparison-with-
| grist/249 and here is the Grist-expert answer:
| https://community.getgrist.com/t/comparison-with-baserow/572
| (disclosure: I work at Grist).
| mackrevinack wrote:
| if i remember correctly, the self hosted version of baserow
| doesn't have all the features that the paid version has, which
| is something that made me a bit apprehensive about using trying
| it out
| jszymborski wrote:
| agreed. I'm all for "open core", but some of the premium
| features are pretty basic.
| throwaway81523 wrote:
| "Open core", seems to mean the low level libs (useful for sure)
| are FOSS while the full featured apps are proprietary. This is
| kind of unpleasant since it creates a tension between a natural
| desire to build featureful apps with the low level stuff, and not
| wanting to "bite the hand" that supplied grist-core. Similar
| things happen with other partly-proprietary programs like
| ansible.
|
| Aren't there already some FOSS alternatives to google sheets? No
| idea about airtable, don't even know what it is.
|
| As for simple ways to write a form app, ActiveAdmin is one of the
| few things I like about Rails.
| conradev wrote:
| This reminds me of Tailscale, which has open source clients,
| but the server is not open source
|
| and, sure enough, someone wrote an open source server:
| https://github.com/juanfont/headscale
| csmpltn wrote:
| Why does every "Show HN"-style thread on here always starts
| with a comment from somebody complaining about about the
| project's license, or how the project isn't "open-source
| enough" for them?
|
| The authors are at liberty to choose whichever license they see
| fit, they have their reasons, what else is there to complain
| about? Can't we just debate the actual contents of the project?
| ChefboyOG wrote:
| I don't disagree, but I will also take debates about
| licensing over 30 separate "Looks cool! I've built something
| similar here: PLUGS PROJECT" comments.
| aembleton wrote:
| I like those comments; I enjoy seeing and trying
| alternatives.
| Macha wrote:
| The title previously said open source, not open core.
|
| When its marketed as a pro of the project, is debating it not
| debating the contents of the project?
| qnsi wrote:
| and the commentor has a liberty to comment if they dislike a
| given license. If the core of marketing benefit is a given
| program being open source, yet the license is limiting in
| that sense, I don't see anything wrong with mentioning that
| issue.
| Tyr42 wrote:
| and people can counter comment complaining about
| complaining...
|
| It's allowed but you need more than that to justify it.
| paulfitz wrote:
| Open core is definitely a tension (disclosure: I work at
| Grist). Specifically for Grist, we differentiate by offering
| data portability and autonomy, and a full-featured open-source
| app is part of how we do that. I invite you to check the repo
| out, you'll see we're not holding back. We did want to flag the
| project as open core from the start, since we will build
| proprietary services and features around the core app (which
| again is very featureful!), and don't want that to come as a
| surprise down the line.
| sdesol wrote:
| Hey great product! Wondering if you can provide some
| development insights. I'm looking at the activity for the
| grist-core repo
|
| https://oss.gitsense.com/insights/github?q=pull-
| age%3A%3C%3D...
|
| and it looks like not much has changed in the last 4 months.
| Is development mainly happening on your SAAS product or is
| there another repo I can analyze?
| paulfitz wrote:
| Development currently happens on a private mono-repo with
| all sorts of stuff in it - including for the SaaS
| environment yes, and bits left over from when Grist started
| out initially as a stand-alone desktop app, and so on.
| Commits are pushed to grist-core about once a week, using
| git subtree. If you look at commit history, you'll see
| plenty of features going in month after month. Since we
| currently develop elsewhere, you'll see few pull requests
| on github. Internally we use phabricator, which is
| deprecated now, so we'll need to rejigger our setup soon.
| It would definitely be good to get more of the development
| process out there, especially now more people have found
| us!
| sdesol wrote:
| Thanks for the insights! I'm trying to support different
| workflows and hearing about yours helps.
| manojlds wrote:
| Oh so it's not even open source core then.
| sundarurfriend wrote:
| I appreciate you taking the time to answer this question.
| Often projects seem to skip over such difficult/awkward
| questions, but seeing an honest reasonable answer to it makes
| me want to check out the project and its ecosystem more.
| nerdyadventurer wrote:
| What do you think better way for opensource startups if it is
| not open core model?
| brunoqc wrote:
| When they offer you to pay for support and hosting it for
| you.
| judge2020 wrote:
| Calling it open core / open source isn't a requirement, and
| often it looks like it's only done to attract engineers that
| want to work on OSS and as a marketing funnel for PMs that
| don't expect the software to have a paid tier.
|
| In my opinion, the differentiator is how viable the 'open
| core' product itself is by itself; I can't speak for the
| thread's product, but Redis is an example of the good side of
| this coin: core functionality, even that related to security
| and user permissions isn't gated to their paid plugin system,
| while Elastic before 6.0 (IIRC) was pretty bad as application
| authentication wasn't included in the open source edition.
| Also, Elastic and Mongo's current SSPL license is just a
| workaround for not wanting to associate their respective
| codebases with the string 'AGPL' while still preventing cloud
| customers from running hosted versions, all in an effort to
| hopefully not turn away good talent/good customers that want
| to use "open source" software.
| jmacd wrote:
| For anyone wondering what Open Core means, Grist explains their
| approach: `Grist Labs is an open-core company. We offer Grist
| hosting as a service, with free and paid plans. We intend to also
| develop and sell features related to Grist using a proprietary
| license, targeted at the needs of enterprises with large self-
| managed installations. `
| 1egg0myegg0 wrote:
| Does this support live updates as other users make edits (without
| refreshing the page)?
| paulfitz wrote:
| Yes it does, changes are broadcast to all connected clients and
| applied in place. Disclosure: I work on Grist.
| HWR_14 wrote:
| Did you settle on "last change wins" for simultaneous
| changes, or was that even an error state that occurs? I'm
| pretty sure GoogleDocs just have the second
| text/cell/whatever replace the new edit as soon as it hits
| the server.
| protomikron wrote:
| How does this compare to Baserow (I think also an airtable and
| sheets alternative)?
| petr25102018 wrote:
| https://community.baserow.io/t/comparison-with-grist/249/3
| [deleted]
| kwhitefoot wrote:
| I don't think many non-enthusiasts will use it unless it can be
| installed without having to install docker first.
| samanator wrote:
| It seems to come with a web server. An enthusiast can host it
| and publish it to non-enthusiasts as a web application.
| nulbyte wrote:
| But can you run it without docker? I have some FreeBSD hosts,
| for example, making a dependency on docker a no-go.
| samanator wrote:
| I'm not the author of this post or the software, but as a
| general rule, if docker can run it, so can a host machine
| without docker (unless docker itself is a dependency which
| is rare and generally only done for Docker specific
| tooling).
|
| Here you can see the the image is based on buster which is
| a Linux type host. So you can almost certainly get it
| working on FreeBSD
|
| https://github.com/gristlabs/grist-
| core/blob/main/Dockerfile
| thrdbndndn wrote:
| I tried it for 5 minutes on docs.getgrist.com.
|
| Maybe it's similar to Airtable (never used it), because it has
| nothing similar to GSheets/Excel other than it's a table.
|
| Like, I don't even know how to do "=A1+A2".
| syntaxing wrote:
| Yeah, I used to think the same thing (that Airtable is a
| Gsheets and Excel competitor). I find it more like Access +
| Excel. It's a database software with a nice and powerful front
| end.
| viraptor wrote:
| Like airtable and ms access, this is a bit more structured. You
| can do `=$A` to reference A from another column in the same
| row. But if you want A1+A2, then you probably want a summary
| table like "group by", or chart it, or do something else. Think
| about it like a database - summing a column from rows 1 and 2
| is not something you normally do.
|
| You can still do this if you want: (there may be an easier way
| though) =sum(row.A for _,row in zip(range(2),
| Table1.all))
| jeffbee wrote:
| I tried to load the CSV that I most recently imported into Google
| Sheets into this hosted Grist and it choked. The behavior of the
| progress bar implies some kind of super-linear algorithm.
|
| The most important component of "alternative to Google Sheets" is
| function. "Open core" is an aesthetic matter of little interest
| to most users.
| troynt wrote:
| This was my experience with a well. I was testing with a 36MB
| dataset and it was choking. The CPU was sitting at 4% usage.
| [deleted]
| heavyset_go wrote:
| It's a Node app, so CPU-bound work will run linearly on a
| single thread unless work was done to break up work into
| multiple processes or worker threads.
| jeffbee wrote:
| It's behavior was more suggestive of Zeno's paradox than of
| single-threadedness.
| paulfitz wrote:
| (disclosure: Grist employee) You're exactly right
| https://github.com/gristlabs/grist-
| core/blob/7f1f8fc9e60a2e1... - sorry the import choked!
| pdpi wrote:
| This distinctly reminds me of MS Access. Was a teen at the time,
| but saw (through my father) a whole bunch of small businesses
| that basically ran off of an Access database with a bunch of
| forms for invoicing and such.
| anyfactor wrote:
| My education was in business and accounting. But working with
| data these days I am surprised to find that the popularity of
| MS Access was greatly exaggerated.
| pdpi wrote:
| I'm not sure I understand what point you're making?
| replwoacause wrote:
| Neither do I.
| stadium wrote:
| I learned schema design and BCNF on an access database. Applied
| database elective during undergrad. Built a career off those
| fundamentals.
| debdut wrote:
| No no, it's not an alternative to Airtable and Google Sheets,
| it's much more than that! Seeing the demo, coupled with the
| Python support, I felt like anyone could built a complex SAAS
| like Salesforce on it.
| kinduff wrote:
| There's even a meme generator. The tool looks very powerful!
| freen wrote:
| I looked, but it seems to run on SQLite. Makes me a bit
| concerned about scalability.
| kissgyorgy wrote:
| The use-case of this app is that a couple of people editing
| things at a time, which is perfect for SQLite. It can read a
| lot, only struggles when you have hundreds of parallel write
| transactions. It's a big misconception about SQLite that it
| doesn't scale. It absolutely can if you don't write it a lot!
| speedgoose wrote:
| If you don't need concurrent transactions, SQLite is usually
| more than enough. A lot of people's "big data" problems, not
| really big data but still significant data, can be solved
| using SQLite.
| tony-allan wrote:
| They mention 100,000 rows as a soft limit.
|
| SQLite is the underlying database technology and it has a
| maximum database size of 281 terabytes. Enough for a weekend
| project!
|
| [1] https://support.getgrist.com/limits/
|
| [2]https://www.sqlite.org/limits.html
| freen wrote:
| More worried about write contention than storage.
| sdoering wrote:
| Thanks for the reminder of SQLite's limits. I knew that
| they were enough to just not think about it for everything
| I could imagine practically doing. But that I could even
| extend them beyond even that was nice to see:
|
| > The default setting for SQLITE_MAX_COLUMN is 2000. You
| can change it at compile time to values as large as 32767.
| i386 wrote:
| Grist is a terrible name. Gristle.
| paulfitz wrote:
| Decided not to do a Grist take on Wordle for that reason. But
| Happy Gristmas works! Grist comes from Grid + list.
| gilrain wrote:
| Most users will assume it's a reference to the common English
| word...
|
| https://www.merriam-webster.com/dictionary/grist
| kanonieer wrote:
| It's funnier for Magic: The Gathering players. Seeing a
| sentence like "grist employee" is hilarious. See:
| https://mtg.fandom.com/wiki/Grist
| mackrevinack wrote:
| i wouldn't be mad about the name either. it doesn't really roll
| of the tongue and i can see it being misheard easily when using
| it in conversation.
|
| something like gridbase, gridrow, gridtable, gridlist, would
| have been better i think, even though they are very generic
| sounding
| i386 wrote:
| I'm not mad about the name. It's just an ugly one.
| mikeflynn wrote:
| Here's a better link directly to the project on GitHub:
| https://github.com/gristlabs/grist-core#readme
| dang wrote:
| Thanks! We've changed to that from https://old.reddit.com/r/sel
| fhosted/comments/su6tv3/grist_fr.... People might want to take
| a look at both, since there's background info there too.
| s3arch wrote:
| As a developer who has been in React/Angular/Vue era, why didn't
| this project leverage these modern technologies for UI and
| instead went with Backbone and Knockout?
|
| I am just trying think outside of the modern widely used
| frameworks and see how they solve some unique problems?
|
| Please anybody can tell me why still anybody use good old
| technologies for frontend in their products?
| vasachi wrote:
| Why shouldn't they use stable technology they are proficient
| with?
| s3arch wrote:
| Thank you for your reply.
|
| Can you please help me understand in what ways
| Backbone/Knockout is considered more stable than
| React/Angular/Vue technologies?
| vasachi wrote:
| Well, think about it like this. React had several major
| versions in recent years, and did remove several APIs. Also
| the whole thing with the new hotness of the hooks API
| (which, honestly, I just truly don't get).
|
| Angular had the whole thing with Angular 2, where they just
| shipped a whole new framework with the same name. So
| everyone with angular 1 codebase was, well, stuck with
| angular 1.
|
| Don't know much about vue, but I think there was some drama
| about rather large API changes from Vue 2 to Vue 3. Correct
| me, if I'm wrong.
|
| Backbone and Knockout, on the other hand, look fairly
| complete. Almost no chance of backwards incompatible
| changes there. So you can just write your code and be done
| with it.
|
| But, honestly, one should use things that one knows. My
| current project is written in React. I'm fine with it. And
| if I had to start a greenfield one, I wouldn't use anything
| else, because I am proficient with React. I can deliver
| features. After all, our customers want the features, not
| the hot new framework.
| thecardcheat wrote:
| > is considered more stable
|
| Was not stated.
|
| > Why shouldn't they use stable technology they are
| proficient with?
|
| This perspective is one of the major indicators of an
| engineer with more experience managing real projects.
| Making a technology choice or transition is a
| milestone/roadmap affecting decision. To do so for
| preference over deliverability has killed many a project.
| vasachi wrote:
| Eh, I'm pretty sure Backbone and Knockout are more stable
| than React :) They didn't have a release since 2019.
|
| I mean, React itself is quite fine with backwards
| incompatibility. But how many completely backwards
| incompatible versions did react-router have? I think
| there four, but I can be wrong.
| s3arch wrote:
| I can't agree more on your point made on deliverable.
| ricardobeat wrote:
| Despite all the talk, there isn't a world of difference
| between how apps used to be written 10 years ago and more
| modern frameworks. The tooling and the language have
| evolved, but you still manage state in similar ways, fetch
| data, build components, render.
|
| Mainly you'll be managing the rendering lifecycle manually
| in Backbone, which you'd end up doing in React anyway to
| get the best performance for an app like this - you'll get
| molasses if you naively build a spreadsheet in react.
|
| One thing I consider a huge advantage: you can read and
| understand the source in one afternoon. Makes debugging and
| optimization a lot easier.
| s3arch wrote:
| >you'll get molasses if you naively build a spreadsheet
| in react.
|
| I digged a bit more on other real world applications.
| Found two interesting posts from atom text editor
| implementors. [1] Why they moved to React. [2] Decision
| to implement text editor DOM updates manually instead of
| via React
|
| [1] https://blog.atom.io/2014/07/02/moving-atom-to-
| react.html [2] https://github.com/atom/atom/pull/5624
| mritchie712 wrote:
| It's a pretty old project (Grist was founded in 2014)
| HeavyStorm wrote:
| Damn, I've been dreaming of building something like this for some
| time now. This is incredible.
| hliyan wrote:
| I wish more code was written like this:
| https://github.com/gristlabs/grist-core/blob/main/app/server...
| lysium wrote:
| Why? What do you like about that code?
| unixhero wrote:
| I looked at it for 5 seconds and was able to understand what
| it does without fine studying the functions. That is
| therefore an excellent example of coding practice. Good
| structure, clean, excellent comments that were explicit not
| tacit and provide any newcomer to the code with information
| about what is going in. A great way to future proof the code.
| nefitty wrote:
| Coincidentally, I was once passed up for a job after
| writing code like this. Verbose code is apparently cartoony
| to some people, but I believe code should be written to be
| read.
| unixhero wrote:
| Sounds like a terrible leader to work for anyways. Good
| riddance.
| wilmoore wrote:
| 10,000%
| [deleted]
| r2222 wrote:
| What's up with the naming :)
| utdiscant wrote:
| The pricing seems weird. Why is there a limit of 10 documents on
| the pro plan? Even as a small team we have 50+ bases in Airtable.
| dahpu wrote:
| Where do you see a Pro plan? Their pricing[0] lists a 10
| documents limit for the free Individual plan and unlimited for
| the paid plans Team and Enterprise.
|
| [0]: https://www.getgrist.com/pricing/
| slightwinder wrote:
| Their pricing-site is just broken. You get the 10 Documents
| for teams on mobile or when you shrink the window on desktop
| small enough to force the side into a vertical(?) view of the
| blocks.
| paulfitz wrote:
| Thanks for pointing this out, we'll get it fixed (the
| desktop version is the correct one).
| resoluteteeth wrote:
| I see a 10 document limit for the Team plan when I open that
| page.
| fouc wrote:
| Great idea! I wonder if there's anything similar to this in other
| programming languages?
|
| Would love to see something like this in Ruby or Elixir.
| petr25102018 wrote:
| Baserow (https://baserow.io/) is in Python/Django.
| boundlessdreamz wrote:
| This looks good but you need to import the data into it. It would
| be great if it can be connected to an existing DB. From the
| discussion, came across https://nocodb.com/ but the authorization
| levels doesn't seem fine grained enough. For ex. limiting access
| for group of users to a particular schema in postgresql
| xfz wrote:
| I was tempted to try this but I'm fed up with getting spam from
| US-based companies so I'll only jump on board if they either
| comply with GDPR or otherwise tell a really good privacy story.
| Sadly that doesn't seem to be the case here, with a paltry
| privacy policy hidden even further out of sight than usual and no
| promises about handling data at the point of capture.
|
| Sure, I could sign up with a temporary email address to try it
| out, but why invest that effort if I know that I'm not going to
| trust them if I become a regular user?
| cyberge99 wrote:
| Then use a non-US alternative.
| xfz wrote:
| Believe it or not, I have actually considered that
| possibility.
|
| However, I think Grist looks like a great project and I can
| see they are reading the comments here. They might appreciate
| the feedback and it might not be hard to act on it.
|
| Plus, they might be small enough to fly under the CCPA radar
| for now, but I suspect privacy matters to many people inside
| the USA too.
| manigandham wrote:
| Some other interesting complementary projects found from that
| reddit thread:
|
| Budibase: https://budibase.com/
|
| NocoDB: https://nocodb.com/
| m-p-3 wrote:
| Also ToolJet: https://tooljet.com/
| badestrand wrote:
| Also TogetherDB: https://togetherdb.com
| scottc wrote:
| This looks like just what I needed when I built my "admin ui"
| last year.
|
| Instead of building an admin ui with Django or similar, I
| encourage you to just stick with a web-based spreadsheet for your
| internal users (if you have a small team, technical teammates,
| startup, etc).
| viraptor wrote:
| In that case you may not even need to build a web based one.
| There's lots of nice DB GUIs which will connect over an SSH
| tunnel. If you're after a record editor, they're often enough.
| iamAtom wrote:
| Is it truly open source ?
| paulfitz wrote:
| grist-core is released under the Apache 2.0 license
| https://github.com/gristlabs/grist-core#license, an OSI
| approved license (disclosure: I work at Grist)
|
| Answer to a related question here:
| https://news.ycombinator.com/item?id=30393794
| viraptor wrote:
| That is amazing. I've complained about the lack of "spreadsheet
| but more structured" ms-access-like solutions here a few times.
| I've been a happy airtable user for a while. But this is really
| the next step. I love it and can't wait to give it a go (self
| hosted)
| pankajdoharey wrote:
| It definitely is superior to airtable, it has many new ideas.
| [deleted]
| sprucevoid wrote:
| Airtable makes most money from pro/business use cases and that's
| what alternatives mentioned here compete for.
|
| But consider personal/family use: Recipe collections,
| inventories, todo, personal project planning and tracking, ...
| There competitors won't need more powerful
| scripting/customizability, just basic feature parity plus cutting
| the dismal ~6 seconds startup time of Airtable's Android and
| Windows apps. "Same but faster" wins me over.
___________________________________________________________________
(page generated 2022-02-19 23:01 UTC)