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.
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.
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.
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!
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).
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.
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.
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.
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
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.
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.
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.
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.
"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.
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.
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?
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!
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.
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.
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?
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.
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.
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)
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. `
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.
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))
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.
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.
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
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.
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
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?
> 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.
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.
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.
>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
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.
112 comments
[ 2.8 ms ] story [ 174 ms ] threadSQLite 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
> The default setting for SQLITE_MAX_COLUMN is 2000. You can change it at compile time to values as large as 32767.
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).
Baserow seemed to be my best bet initially, but it seems like the Grist feature set is way more what I'm looking for.
The most important component of "alternative to Google Sheets" is function. "Open core" is an aesthetic matter of little interest to most users.
Would love to see something like this in Ruby or Elixir.
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.
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?
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.
and, sure enough, someone wrote an open source server: https://github.com/juanfont/headscale
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?
It's allowed but you need more than that to justify it.
When its marketed as a pro of the project, is debating it not debating the contents of the project?
Budibase: https://budibase.com/
NocoDB: https://nocodb.com/
Answer to a related question here: https://news.ycombinator.com/item?id=30393794
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".
You can still do this if you want: (there may be an easier way though)
https://www.merriam-webster.com/dictionary/grist
something like gridbase, gridrow, gridtable, gridlist, would have been better i think, even though they are very generic sounding
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.
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
Which means that only enthusiasts will do it.
>An enthusiast can host it and publish it to non-enthusiasts as a web application.
So the person "getting it working" would need to be enthusiastic about it!
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?
Can you please help me understand in what ways Backbone/Knockout is considered more stable than React/Angular/Vue technologies?
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.
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.
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.
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
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.