Grist – Open core alternative to Airtable and Google Sheets
github.com
github.com
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/
SQLite is the underlying database technology and it has a maximum database size of 281 terabytes. Enough for a weekend project!
> The default setting for SQLITE_MAX_COLUMN is 2000. You can change it at compile time to values as large as 32767.
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.
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).
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!
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.
Would love to see something like this in Ruby or Elixir.
The most important component of "alternative to Google Sheets" is function. "Open core" is an aesthetic matter of little interest to most users.
Baserow seemed to be my best bet initially, but it seems like the Grist feature set is way more what I'm looking for.
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)
=sum(row.A for _,row in zip(range(2), Table1.all))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?
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.
I’m genuinely curious - I run a SaaS and have spent way too much time ensuring privacy and refusing the use 3rd parties whenever possible. I get occasional emails from folks asking me to delete their email address in our system - we do not send almost any email ever and every email has an unsubscribe link - but I can’t sort out the goal - if you sent me an email so I get rid of your email - aren’t you… giving me your email? I can’t make it into a reasonable position in my head. What is the dream system from your perspective?
In ascending order of impact from slightly annoying to serious issue:
1. Sending marketing without consent. In the EU and UK this is unlawful (PECR regulation 22); elsewhere it's still highly unwelcome. This applies to users/customers who have chosen to sign up (just ask when you collect the data).
2. Sending reminders for unnecessary actions such as giving feedback. Reminders should be for genuine problems like unpaid invoices.
3. Missing/broken unsubscribe link or not acting on it. The latter is so common I began to doubt my memory and started saving screenshots. Even years later, marketing often resumes, perhaps after a botched provider migration.
4. Data breaches. Whether sold, given away or lost the effect is the same: too much spam to wade through (when looking for false positives), eventually making my email domain unusable and forcing a migration. I've used a different email address for every company to track this (> 20 years) and around 1 in 25 providers are affected.
Points 3 and 4 might help to explain why people are asking you to delete their data. Even if you have done none of the above, the well of trust has already been poisoned by others.
Companies that win my trust tend to follow a couple of broad principles: be transparent about how you use data (and keep promises), and give the user control.
To your last point, yes it's difficult to fully erase data immediately, especially by email.
By way of example, in cases where GDPR applies, a data controller might need to keep a record of the request for a while to demonstrate compliance. This is provided for in the regulation but the company would need to keep it for no longer than necessary, be transparent about how long that is, minimise what's kept and keep it secure.
In practice, the best thing would be to provide a self-service delete capability. Log in, go to My Account, delete account. Personally I don't mind an email confirmation. Good companies don't try to trap customers, and if I can delete my account easily then I will leave with a positive experience and probably return later.
Failing that, if I have to email you asking you to remove my personal data, I would make the calculation that having my deletion request in your inbox is not as risky as having it in your main customer database, which will likely to be replicated to several other data processors as well. You could always send an email saying you've carried out the request and will then delete the email thread immediately after.
Not saying you should do any/all of the above but I hope it helps.
<hot-take> More programmer-focused, less UI/normal-folk focused. </hot-take>
Answer to a related question here: https://news.ycombinator.com/item?id=30393794
something like gridbase, gridrow, gridtable, gridlist, would have been better i think, even though they are very generic sounding