i'm gonna go cry now.
please don't tell me this has been out for a while and i missed it.
Nice to see they're still around, 8 years later.
The main reason is being able to see and edit the programming / formulas as overall text, rather than the usual fragmented cell by fragmented cell view. I love named cells and "ranges". I love the concepts of replicating rows or adding a column to a calculation - that's all good. But programming (or editing data) in the small, cell by cell, just doesn't compute.
"Notebook"-style programming comes close. Ideally, I'd prefer if the visualization was handled independently - freely choosing the embedded capabilities if any, or the mountains of visualization software that already exists.
Improv and Spreadsheet 2000 seem to have gone in that direction - but they are still primarily GUI programs.
Shame, as I agree that something like that would solve a lot of problems.
At the moment, excel and spreadsheet solutions as a whole are so different from any actual programming/data work that goes on, that business logic has to be completely rewritten (e.g.) a team of excel based analysts pass something over to developers to integrate into data pipelines.
Would be great if tools kept people at least in the same ballpark.
CPAN has a few modules in these general directions... Spreadsheet::Engine, Spreadsheet::Perl, Spreadsheet::Edit - some independent, some acting on a spreadsheet file.
But re:parent comment, I'm not sure I understand how you could handle the visualization independently
A notebook lets you use various libraries or outside programs to do the rendering.
https://www.orafaq.com/usenet/comp.databases.oracle.server/2...
In Grist, check out the "Code View" page in the left-side panel -- it shows all the logic (i.e. formulas) of the document along with the Python data model (i.e. all the column names and types).
Also, you can save or download a copy of the document without the data, but keeping all the formulas. So you can get all the logic (and formatting, layouts, etc), and use it for different data.
(No support for solving circular references though.)
https://sourceforge.net/projects/flexisheet/
but getting it compiled/working is left as an exercise for the reader.
I miss it, book, and a bunch of other cool stuff from early Mac OS X days.
I really adored the old versions that had the sidebar with sheet and table lists.
But yeah, it definitely has enormous potential. They just keep adding features that are pretty useless, such as the ability to annotate with a Pencil or various realtime collaboration features. That’s all pretty pointless. They have a potential winner on their hands and they don’t even bother implementing the stuff power users need. Keynote clearly benefitted from Steve’s intensive use of it. Somebody in the C-suite really needs to settle into using Numbers as their main spreadsheet and then growl at developers to implement the features they find themselves wanting.
Working for a government agency, self-hosting was an absolute must for my team and we're just loving the product so far — and have been contributing a lot to it in return (they are very serious about really playing the open-source game!)
What I love the most is that the way it's build makes it easy for anyone familiar with spreadsheets to get started while making virtually anything possible for a more technical person through custom widgets (basically a web app that integrates with any table and is displayed within Grist) and python formulas !
Am I right that everything is stored as-code, and that code and UI live in a 1:1 relationship? Seems like maybe the data and the code are separate?
I would _love_ to see (a) version control built in (i.e. a github integration) and (b) support for testing!
$ file 2V3g4e7Xc6SYNPokEP8W5Q.grist
2V3g4e7Xc6SYNPokEP8W5Q.grist: SQLite 3.x database, user version 8, last written using SQLite version 3040000, file counter 6089, database pages 1059, 1st free page 927, free pages 139, cookie 0x355, schema 4, UTF-8, version-valid-for 6089
A bonus was the desktop-app. Having the option to run it offline is a good choice.
Grist – Open core alternative to Airtable and Google Sheets - https://news.ycombinator.com/item?id=30392227 - Feb 2022 (107 comments)
I understand this is just an example, but anyone who wants to actually use it for that is going to want a lot more marketing collateral up front explaining how this very sensitive data is going to be locked down.
Grist has access rules which give the document owners the ability to set rules that limit who can see or edit what, down to each table, column, or cell. Rules can be based on user attributes, including attributes defined by the document owner (e.g. roles within a company), and based on values in cells (e.g. if a row's boolean field is true or false).
On the document thing - this is still a little tricky, as e.g. IT should probably be in charge of assigning permissions, but they shouldn't be able to see salaries.
Here's a strong form to help threat model: are you warrant-proof?
If authorities demand customer data, can you give it to them?
In general, if the answer is yes, then not just the government warrants but your own insider threat is also a threat to your customers.
It may be that self-managed hosting is your answer, with the inevitable "call us" pricing: https://www.getgrist.com/product/self-managed/
But as most companies will be putting data in a spreadsheet that has laws around it whether they consider themselves "regulated" or not, all firms should be interested in the warrant-proof answer.
What makes you think it's well thought out? What do you like about it? What do you not like? What is it missing? How does your product fill that need?
Since it stores the data in SQLite, it would be nice to integrate e.g. ElectricSQL to sync with a self-hosted central Postgres db.
* it doesn't sync with anything but has its own data store, built around sqlite, and you can indeed download "documents", which are just sqlite files. (I looked at how they encode summary tables, and it's not as views, so the grist<->sqlite translation is not as shallow/isomorphic as one might hope)
* authentication is not taken care of by grist-core itself, but they provide different integration methods (saml, forwarded headers, … ?)
For instance, Win32 API/Swift UI/GTK would be the surface area for a cross platform application. I am not counting Qt/wxWdigets. You can tell a Qt application from a mile away.
And making an application look identical on all platforms is downright impossible. There would be noticeable differences.
When the narrator says, "It's that easy!", I want to punch them in the face.
Maybe because i don't use spreadsheets in daily job
Anyway, suggestion to the developers:
Your intro video needs work. A little context setting would go a long way in those first few examples. Five seconds in and I'm thinking, "wait, what?"
Also, the audio sounds very amateur (bad mic in an echoey room).
Would you rather not have this application exist at all? Because doing this with native UI frameworks is such a massively larger amount of work, it's not even comparable. Speaking from not-so-fond memories of working with Qt..
But specifically addressing "Would you rather not have this application exist at all?" - with more apps starting to go that way, it doesn't matter if they exist, because I won't have resources to run them. I've already dropped some electron apps for objectively worse alternatives, because I have actual work to do and 10 different Chrome processes cause swapping which prevents me from doing it.
Honest question: what kind of hardware are you using? I run Electron apps on a 12 year old dual core laptop with HT disabled and 8GB of RAM and never had any issues. So I'm curious to learn what kind of hardware would prevent one from running an Electron app, while still being able to run the online equivalent (i.e. any modern web browser with scripting enabled).
The CPU doesn't really matter here that much and older hardware with 32GB would do better - it's the memory that gets impacted the most. Running "an Electron app" is not a problem. Running the 8th Electron app is.
In this specific case, I rather use Google Sheets or Microsoft 365 on the browser, than yet another Electron app.
VSCode is one of the few that get a pass on my private computer, as some languages are only properly supported there, e.g. Powershell and Azure tooling.
" If you wish to view and edit spreadsheets stored locally, another option is to use the grist-electron desktop app for Linux, Mac, and Windows. And to show Grist spreadsheets on a website without any special back-end support, your options include grist-static, a fully in-browser build of Grist."
This should never have been done, PWAs do exist.
Also there on the same readme.
No need to help Google take over the Web even further, besides the waste on local resources.
I’m not going to pretend that there’s currently a better solution because for the current set of constraints everything sucks. .NET has a few up-and-coming frameworks for cross-platform UI but nothing mature like WPF was. Java still produces noticeably slow applications. React Native could perhaps get part of the way there, but as far as I’m aware that mostly targets mobile.
A standard interface for web views would be great, I’d love to force everything onto a consistent version of Gecko, but really we need a new native cross-platform batteries-included framework with controls and layouts for 90% of standard business scenarios.
No application < Electron < Native app
I want it to work the other way around: a spreadsheet with more databasy features I can choose to use:
In the same way that the chart wizard can do a good job of spotting the “table” of data that the current cell is in, the spreadsheet could auto-detect natural tables and make it easy to create and manage named ranges etc. And then allow formulas to offer better ergonomics than vlookup etc and even allow sql etc?
Things like allowing column widths to change for different rows in the same column etc would also be awesome. And offering an insert-column that automatically only inserts for the current table etc.
i have been searching for this for literally years, all the time maintaining an app as a google sheets script, because much as i would prefer something self-hosted and customisable, that collaborative grid view is the ideal user interface from my users' point of view. so far nothing has fit the bill - basetool (https://github.com/basetool-io/basetool) might have but it's discontinued and underdocumented, and i'm not really a web developer so i don't feel up to the challenge of getting it running and integrated into an app.
grist actually came really close from a ui perspective, but it was too focused on being a spreadsheet and doing computation in the frontend. i filed an issue that explains my use case in more detail: https://github.com/gristlabs/grist-core/issues/422
I finally sat down and wrote a simple terminal program to manipulate tabular data just so I could drive it from Python, Zig, Rust, etc.
At various meetups, I have discovered that quite a few of us have written a "shitty limited spreadsheet" because you can't drive the spreadsheets programatically.
And we're still competing with Excel almost 40 years later...
Thanks for sharing!
So, thank you very much for your invention, and I'm glad it lives on!
I would prefer RShiny, but the intended audience can't modify that...
Still have the code? You should open source it! Probably nothing comes off it, but that's guaranteed to be the outcome of keeping it closed
And for the time, Enable's ss had some interesting innovation. One was the integration through the whole suite. But most interesting to me, on the ss team, was the 3D nature of the app.
Excel liked to bill itself as 3D, but it's not really: their tabs aren't a true third dimension. But Enable's was, so any range could be specified with a Z-dimension if you chose. This allowed interesting patterns like a report with an XY plane for each month, with the top one being a summary, implemented by summing (or whatever operation is appropriate) that 1x1 cell down through the Z range.
Another contemporary one I liked to play with also claimed to be 3D and wasn't but in an interesting way. Lucid 3D was actually hierarchical, such that any sheet could expose a single value to be consumed by a single cell in a parent container sheet, recursively.
I am building an open-source tool that allows quickly building web user interfaces on top of relational databases [1]. Among users are many people without a CS background, and without prior knowledge of SQL. And from the feedback I get, the pain point for getting started is very rarely learning SQL. Spreadsheet formulas are often much more complicated than the basic SQL queries that cover 90% of what everyone needs.
formulas but in JS/TS, on data change trigger of serverless cloud functions, assign default values for database columns, granular permission controls, store files/assets images to cloud storage, bulk deletes and more.
Disclaimer, I am one of the makers :)
Email me if you don't find what you need: mgummelt@plato.io.
One can select a cell inside a table-like range and click "Format as a Table" to have Excel automatically infer the range of the table (including the headers) and enhance it with database-like features. One can then refer to columns in formulas using references like so: `=[@[first column]] + [@second_column]`. Modifying the formula in one cell will also update all the cells in the same columns. The table object becomes accessible using labels (e.g. `Table1`)
Very useful!
Building join tables with calculated fields is a missing feature in all spreadsheet-like solutions as far as I know.
Also I concur with the parent that I often get frustrated by my inability to do spreadsheety things in these tools.
Also, if you just want to do queries and don't care about instant updates, you can do any SQL you like including joins with a SQL endpoint or a custom widget https://twitter.com/getgrist/status/1710018836836077967
[Grist employee]
What I'd like is something you can do both. Start writing random things but then slowly formalise - define columns as specific types for consistency etc. And if you do this enough end up with a structured database. But not force only one or the other
Drag a box to define a new table, intersperse whitespace with text/images/graphs/formulae (two cells) that aren't locked to a grid based on a upper-left table.
Auto-recognise the first line in a table as a title, second line as column headings.
LibreOffice already allows SQL on spreadsheets; but SQL formulae would be cool.
* Are you self-hosting?
* What auth method are you using?
* How is the linking done? I presume API (or are you just using widgets?), but that means you need users to copy/paste their API key by hand?
Thanks!
For me I think it's just the sheer time investment, personally. Spreadsheets give a very easy programming language, no compiler, via Google sheets my phone can run it and my browser can run at and I can link it to someone... All great pros! But then it takes so long to be effective with them.
Give you an example of the last big app that I wrote for a spreadsheet: I have a 2-year-old, she was born a bit underweight with lip/tongue ties that gave her trouble latching, so we chose to do a hybrid breastfeeding/formula approach; we'd use bottles of pumped milk where we could, but if she was too frustrated to latch and we'd already used up the pumped milk we'd break out the baby formula.
But, we knew this was a risk: milk production is in response to demand, when it goes dry you activate more tissues that make more milk later. So I wanted to be able to answer my wife's questions of “is my milk supply getting stronger or drying up, what percentage of her diet was formula, etc.” and my own questions of “did I enter all of yesterday's stuff properly?”
So the spreadsheet is, a Google Form first dumps {
timestamp: date
what: enum('milk', 'formula')
from: enum('mama', 'enfamil', 'costco', 'bottle', 'freezer')
to: enum('waste', 'kid', 'bottle', 'freezer')
oz: decimal
when: nullable(date)
rowID: number
effectiveDate: date
check: boolean
These then get sorted on a following page and chunked by day. Another page allows me to track “how much milk is currently in bottles, how much formula is currently in bottles, how much milk is in the freezer," and an enhanced version on the next page shows me all of the account balances by date. Why these? So that I can answer “did I forget to input some of this milk/formula in my sleep addled state?”. A lot of this tracking was done by using my phone to just take a picture of an amount in a bottle and then piece together what had happened that day later. So it had to be checkable, “this says I have X ounces in the fridge, do I have that?”
The next page just has plain text, these are derivations of mathematical formulas, explanations of the modeling I wanted to do, thinking out loud so that the formula is showing up on the next page are not out of context when I later go to change them.
From the daily balances finally we get the models. Some ways I do this are to use a binomial distribution to smooth the data that I've got, with noisy data that can be a little bit easier than independent data points. I also tried some autoregression modeling to try and predict, with error bars, “today, tomorrow, the day after” for the binomial smoothing. I wanted to do this for three series which ended up being "total fluids kid has consumed, total milk pumped into either bottles or freezer bags, and formula: consumed milk ratio.” but this required a lot of iteration over different things that I might have wanted to try to graph before I could answer the questions that I really wanted to.
So I then like to plot line graphs where the data points are little X's, there are two dotted fit lines, one with the error from the model added, the other with the error from the model subtracted, so you get this kind of snake of error envelope that is just a running average in the middle but “opens its mouth” at the end, so that I am not telling a story that is not supported by the error bars given only the past couple days' data. If the entire snakehead is pointing up then yes, “your supply looks to be getting stronger this week!” but otherwise “it's still a bit early to say but here's what the story was three or four days ago.”
When I describe this to you it doesn't sound like a very complicated app, right? But writing it in a spreadsheet, which I needed so that I could input data or correct it from my phone at 3am, made this a very slow process, hours and hours were sunk into this tracking spreadsheets to get them where I needed them to be. And that's the big problem is that spreadsheets are kind of an “assembly language” level of solution where you have individual cells/registers that you have to track and update and coordinate, but the system doesn't connect everything together semantically so you have to express every single relationship yourself and then auto fill columns and whatever else to make it work.
One thing that actually has pretty great UX is Apple's Pages (mainly the concept of fine-grained table creation), I'd love it if someone copied that.
The two areas where it makes sense to compete are:
a) Embedding a spreadsheet like (to varying levels of featurefullness) interfaces into other applications or workflows. A minimal feature set probably doesn't even involve formulas, just the UI affordances of a typical spreadsheet (ie it needs to copy and paste like a spreadsheet).
b) You are building something that acts like ms access (or airtable), just aiming for different blends of functionality/freeformness/end user fiddliness.
Regular spreadsheets give you a number of independently configured cells, which gives you maximum flexibility, but becomes inconvenient when you want tables instead: have a fixed structure, enforce column types and validations, implement row-level access control, or join them together.
You can say it’s a type of no-code tool, enabling you to build a CRUD app with a spreadsheet-like interface. Their website even features demos like “lightweight CRM” and “class enrollment”.
Sounds like Microsoft Access
Since code is too hard, most people just abuse Excel, but Access was truly a "no code" solution for many database problems.
There is definitely a market for a good free software featureful spreadsheet tool.
While there is a market for more spreadsheet tools to which I welcome... sadly, it is not just about spreadsheets, it is about Suite/Office tools.
In order for a new spreadsheet killer to stand a chance, it needs to be alongside an Access alternative, Word alternative, etc. Without this, I dont think it will catch up with Microsoft/Google Suites no matter how good it is.
This is why LibreOffice will stick around for quite some time.
I do like LibreOffice and appreciated the work done on it. From memory, it has improved a lot since it branched off OpenOffice. Admittedly, it is not comparable to MS Office.
Focusing on Spreadsheets... MS Excel, compared to LibreOffice Calc, is a smoother experience and easier to use. I would not be suprised if it has more features. I can say the same thing for MS Word vs LibreOffice Writer. I have not used LibreOffice Base but I would not expect it to be as good as MS Access. I dont use them so cannot comment further.
Personally, I would love to see a Spreadsheet program which enables you to write Scheme code behind it, rather than some Excels VBA-like language. Easy to code and extend and automate.
This discussion covers it in more detail: https://ask.libreoffice.org/t/how-to-create-format-as-table-....
Note: I am not saying there are no true and valid differences one or another person could really rely on. But having worked in IT-support I know that not few people like to give pseudo-rational reasons, when in fact it is often more about feelings. I don't say that feelings/look/design is irrelevant: "I like the design of Excel more", is a totally valid reason for choosing it over Libreoffice. But in the end many people pretend there is more to it. I have yet to encounter a situation that I couldn't resolve using Libreoffice Calcs features (ignoring insane scenarios where writing a well tested script or using an actual database would be the rational option).
Like others, I am having trouble putting my finger on the reason, the best I can do is to say that in Calc my attention was often on the software itself rather than the data. To use Heideggerian terminology, Calc often feels "present-at-hand" whereas with some experience other spreadsheet tools feel "ready-to-hand".
I initially assumed I simply had more experience with Excel and would find Calc just as easy if I spent more time with it. But then I tried Google Sheets and to a lesser extent Apple Numbers and was able to quickly transition from thinking about the tool (present-at-hand) to thinking about my content and tasks (ready-to-hand).
I still have to drop out of my task flow when using an unfamiliar feature in Excel, Sheets, or Numbers but these feel like momentary digressions with the majority of my time spent thinking about the content. With Calc the ratio felt reversed, with the most of my time spent thinking about the tool. (Though I'll admit I have not tried it in several years -- perhaps it has improved since then.)
I wish I could provide more actionable feedback, but I suspect that the best way to pay down some of their design debt would be for Libre Office to conduct usability tests.
People prefer gsheet to calc not because of one big missing functionality, because as you say, you can always find a way. It's more that excel/gsheet makes your life way easier, and saves you a lot of time.
I use both gsheet (for work) and calc (for personal stuff). I really want to give calc a chance so I accept the excess time it takes me to use it, but I understand that some people don't. And I would not say that it's related to "feelings", it's more a problem of "ease of use" and "doing things fast".
More free software cosplay. :(
> Grist Labs is an open-core company. We offer Grist hosting as a service, with free and paid plans. We also develop and sell features related to Grist using a proprietary license, targeted at the needs of enterprises with large self-managed installations. We see data portability and autonomy as a key value Grist can bring to our users, and grist-core as an essential means to deliver that. We are committed to maintaining and improving the grist-core codebase, and to be thoughtful about how proprietary offerings impact data portability and autonomy.
And compared to the alternatives (nocodb, mathesar, baserow) they seem to provide the best self-hosted/open source solution in terms of polish and features.
*Edit* I've been looking for a while for a similar software stack for the organisation of a coop I'm a member of, and have not found anything better as of now, though open to alternatives!
It’s like a factory that respects human rights for 95% of its employees; such a factory can’t be said to respect human rights.
Microsoft releases a lot of free software, too. This is just a proprietary software vendor that wants to come off as a cool open source company; that’s all open core is: a marketing bullet point. I believe the term “open source cosplay” is appropriate.
If you aren’t faking a personal respect for software freedoms, you consequently release 100% of all software you produce as free software.
It’s okay to be a proprietary software vendor. Not everyone agrees on the four software freedoms being important. It’s just misleading and inconsistent to brand yourself with the ideology, and then not live up to that.