[HN Gopher] Grist is a modern, relational spreadsheet
___________________________________________________________________
Grist is a modern, relational spreadsheet
Author : protontypes
Score : 451 points
Date : 2023-10-31 06:20 UTC (2 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| kamphey wrote:
| This looks promising! I've been asked a lot about embeding google
| sheets into websites. Always been using a work around but this
| seems like it could be pretty special: "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. "
| protontypes wrote:
| That's exactly why I'm also very interested in using Grist.
| Embedding spreadsheets into web pages has never satisfied me
| and has resulted in unacceptable load times.
| melih1im wrote:
| Embedding spreadsheets especially with iframes seems alien in
| websites. I've used retable.io feature to get the data in
| json or html. It works great with wordpress
|
| https://go.retable.io/view4dvhJpM6LVTtjBG7/html
| techn00 wrote:
| open-core*
| sneak wrote:
| Yes; I missed that. Thank you.
|
| 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._
| notyoutube wrote:
| I tried the `grist-labs/grist-core` docker install: it's
| quite easy to set up and most of the useful features are
| there (I think it's mostly snapshots missing). I don't think
| "free software cosplay" is totally fair in this case.
|
| 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!
| paulfitz wrote:
| Snapshots are there, but you need to configure an s3-like
| store to enable them, e.g. MinIO (or S3 itself). [Grist
| employee]
| vviers wrote:
| Can confirm that we're self-hosting a couple instances
| with snapshots enabled (using Scaleway's S3 buckets)
| notyoutube wrote:
| Noted, but can't edit my comment. Thanks!
| sneak wrote:
| Free software is an ideology based on respect for the four
| software freedoms. If you run an organization that sells
| proprietary software that also releases free software, you
| demonstrably don't believe in the fundamental importance of
| the four software freedoms for users, otherwise you
| wouldn't use copyright enforcement mechanisms to deny them
| to your non-customers.
|
| 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.
| evan54 wrote:
| What are the usecases for non standard spreadsheets? Ie when does
| one of libre office, google sheets or excel not suffice that
| people spend time developing a new spreadsheet software? Honest
| question..
| sneak wrote:
| Libreoffice is missing huge swaths of features that Excel has,
| and isn't very good. Google Sheet is a cloud service packed
| with surveillance, not software. Excel is proprietary and
| expensive and has invasive spyware.
|
| There is definitely a market for a good free software
| featureful spreadsheet tool.
| pbhjpbhj wrote:
| What would you say the most important [to you] features are
| that LO is missing?
| atoav wrote:
| I am curious about that as well, because I heard that one
| often and whenever I ask: "Like what?" it is either some
| obscure function that you could build yourself with a few
| lines or it is crickets and a: "Don't know, I just like it
| better".
|
| 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).
| 2pie wrote:
| I would make a difference between "design" and "a lot of
| small and convenient functionalities that makes your life
| easier".
|
| 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".
| asoneth wrote:
| I agree that design (rather than functionality) holds
| Calc back, but chalking it up to personal preference may
| prevent the Libre Office team from increasing their user
| base.
|
| 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.
| actuallyalys wrote:
| I'm not the person you asked, but a feature I miss in
| LibreOffice Calc is the ability to define tables. You can
| add manually emulate some of the features by adding filters
| and formatting (which could become a macro) but you can't
| do structured references to include parts of the table in
| an organized way.
|
| This discussion covers it in more detail:
| https://ask.libreoffice.org/t/how-to-create-format-as-
| table-....
| masfoobar wrote:
| You hit the nail on the head, here.
|
| 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.
| asqueella wrote:
| Grist is more like Airtable, a spreadsheet/database hybrid.
|
| 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".
| SoftTalker wrote:
| > You can say it's a type of no-code tool, enabling you to
| build a CRUD app with a spreadsheet-like interface.
|
| Sounds like Microsoft Access
| ibejoeb wrote:
| Access was an amazing product. It was quick to a hit a
| performance wall, but damn it was amazing for business
| applications. Imagine replacing its rdbms engine with
| sqlite...
| bombcar wrote:
| It really was and really is something that we're missing,
| the "next step up from Excel".
|
| Since code is too hard, most people just abuse Excel, but
| Access was truly a "no code" solution for many database
| problems.
| icegreentea2 wrote:
| There aren't many reasons to create a freeform spreadsheet
| editor to compete with Excel or gsheet as standalone
| applications.
|
| 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.
| genericacct wrote:
| Sometimes you want something cloudy but you want to keep all
| the data inhouse. Sometimes you want to integrate it into a
| product offering. You want to use a tablet as a spreadsheet
| monitoring machine.
| solarkraft wrote:
| I dislike the UX of Libre Office (the way it scrolls alone
| drives me mad) and Excel and Google Sheets are proprietary and
| SaaS-y.
|
| 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.
| crdrost wrote:
| Wow! You got a lot of responses!
|
| 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)
|
| Note that this is basically an accounting journal, stuff is
| flowing from one account to another account, the time of
| transactions might be backdated via this optional "when" or
| might just be whenever the spreadsheet was filled out. This is
| immediately enhanced with three calculated properties,
| rowID: number effectiveDate: date check:
| boolean
|
| The consistency check will highlight the row red if I said
| something that was clearly nonsense and needs to be manually
| corrected (one way this isn't an accounting ledger!) like
| formula coming from the "mama" account or going into the
| "freezer".
|
| 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.
| melesian wrote:
| I help run a small non-profit that has managed data in a number
| of spreadsheets. Grist made it v simple to pull the data into a
| web site linking it together with a variety of different
| scrollable views. Came across it while looking for lo- and no-
| code solutions and quickly stopped looking. It was just the
| ticket.
| notyoutube wrote:
| Could you expand on how the linking is done:
|
| * 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!
| melesian wrote:
| Not self-hosting. Linking by identifying key fields.
| Currently just using password login.
| wood_spirit wrote:
| I always get excited about these databases-that-look-like-
| spreadsheets and then get frustrated when they stop me doing
| spreadsheety things.
|
| 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.
| pbhjpbhj wrote:
| Yes, what I'd want is like a Jupyter notebook for spreadsheets.
|
| 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.
| alexmojaki wrote:
| You can embed an integrated Jupyter notebook into a Grist
| spreadsheet: https://github.com/gristlabs/jupyterlite-
| widget/blob/main/US...
| FredPret wrote:
| I think Apple Numbers work like this
| twelvechairs wrote:
| Yes the joy of a spreadsheet is the blank slate - you can just
| start writing random things in random boxes.
|
| 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
| laingc wrote:
| Doesn't Airtable more or less do this?
| RyEgswuCsn wrote:
| Excel already does this except for the variable column width.
|
| 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!
| klysm wrote:
| But I still can't write joins as formulas
| smokefoot wrote:
| Can you do this in grist or Airtable?
|
| 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.
| paulfitz wrote:
| In Grist, reference columns let you do a lot of what you
| can do with a join https://support.getgrist.com/col-refs/
| while still having spreadsheet-style immediate updates
| when underlying data changes.
|
| 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]
| klysm wrote:
| I've never used grist and know nothing, but if we have
| foreign keys why can't we write join expressions?
| e12e wrote:
| I'm sure you could hack it up in scheme-in-a-grid?
|
| http://siag.nu/siag/
| klysm wrote:
| hacking it up is something I can do in most spreadsheet
| thingies, but I just want to be able to type join and
| have it Just Work
| pjmlp wrote:
| I guess it would be possible using lambdas or powerquery.
| klysm wrote:
| Power query is a pretty terrible UX imo. You have to
| manually sync everything
| nhinck2 wrote:
| It depends on the join you want to do but it is definitely
| possible to do joins as formulas in excel.
| klysm wrote:
| Yes that's true but you have to jump through a lot of
| hoops. I want to be able to write like a sql style join
| on tables with named columns
| alok-g wrote:
| Interesting. I just tried. This part is not working for me as
| yet -- "Modifying the formula in one cell will also update
| all the cells in the same columns."
| RyEgswuCsn wrote:
| It works for me unless I manually introduce inconsistencies
| in the formulas.
| harinijan wrote:
| You can checkout opensource project
| Rowyhttps://github.com/rowyio/rowy - it a spreadsheet UI for
| database and can do databasy things like you said!
|
| 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 :)
| spaniard89277 wrote:
| This one is very interesting, thanks for sharing.
| samanator wrote:
| I remember rowy from a while ago. It said then that other
| databases (aside from Firestore) are coming soon. Any news on
| that? I'm looking for a Postgres frontend.
| mgummelt wrote:
| Shameless plug, but Plato (https://plato.io) is a PG
| frontend.
|
| Email me if you don't find what you need:
| mgummelt@plato.io.
| PurpleRamen wrote:
| Yes, it's kinda annoying when people call something
| spreadsheet, when it's really just a richful WYSIWYG-interface
| for a relational database. Not that it's bad to have a good
| Database-Interface, but the flawed communication will make a
| poor impression with those who really want a real excel-like
| spreadsheet, and then got something else. This will probably
| more harmful than beneficial in the long run.
| paulfitz wrote:
| The motivation for calling Grist a spreadsheet is that it has
| formulas, and cell values get updated automatically when
| something they depend on gets updated. Agree there is scope
| for misunderstanding here, maybe there's a better word?
| [Grist employee]
| ulucs wrote:
| You might want to look into calculated columns
| PurpleRamen wrote:
| This is normally called a database-app.
| lovasoa wrote:
| Yes ! Maybe I'm old-fashioned, but I do still think that SQL is
| a better interface to databases than excel formulas, and
| classical spreadsheet UIs are a better interface for, well,
| spreadsheets.
|
| 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.
|
| [1] https://sql.ophir.dev/
| coldcode wrote:
| I built
| https://en.wikipedia.org/wiki/Trapeze_(spreadsheet_program) in
| 1987 which is the spritual ancestor to a lot of alternative
| spreadsheets. We were killed by having to compete with Excel
| with something not a row and column spreadsheet (it's named
| block-oriented). If it hadn't died in 1989, a lot of what
| people are doing today would have been possible over time, but
| decades ago. Some of the recent attempts were aware of Trapeze,
| but it's been so far in the past I have no idea about these
| folks.
| freedomben wrote:
| I've long suspected that excels early dominance killed a lot
| of innovation. Glad it's finally happening now, but a bit sad
| on what could have been.
|
| 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
| CWuestefeld wrote:
| Back then, I worked on an office suite called Enable,
| specifically on the spreadsheet module. I can confirm that
| this is what killed us.
|
| 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.
| coldcode wrote:
| At one point I found it, but since its gotten lost in
| various Mac transfers so I am not sure it still exists. I
| do remember it was uncompilable (ThinkC I believe from
| 1988). If I find it I will put it somewhere and mention it
| on my blog (https://thecodist.com). I also have the
| original manual, buried somewhere as well, which would be
| enough for someone to try recreating the engine).
| coldcode wrote:
| Yes, every single spreadsheet was killed by Excel being in
| Office. There were a lot of attempts to do something new,
| all failed.
| epistasis wrote:
| I still love this concept in Numbers.app, and usually develop
| new spreadsheet models there before moving it to Google
| Sheets to share with a wider audience, usually by replicating
| tons of sheets for the various data table.
|
| 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...
| antidnan wrote:
| Wow, Trapeze is cool! Never heard of it until now. And it
| basically is a spiritual ancestor to what I've been working
| on. A "block-based" spreadsheet that also preserves row/col
| style referencing where needed.
|
| And we're still competing with Excel almost 40 years later...
|
| Thanks for sharing!
| khobragade wrote:
| https://ultorg.com might be useful to you!
| hansonw wrote:
| Our startup is building https://arcwise.app, which allows you
| to embed full-fledged SQL tables inside Google Sheets! We're in
| the process of building out support for joins & subqueries,
| would be curious what people think.
| nusl wrote:
| Being tied to GSheets immediately disqualifies this for me,
| though there are millions of others happily using it
| prometheus76 wrote:
| Powerpivot within Excel and Power BI itself allows one to use
| SQL to pull data from an ERP or from a data warehouse, allows
| one to build a model with relationships between tables (instead
| of vlookup or index/match) and allows you to work with much
| larger tables than native Excel.
| zem wrote:
| i want exactly the opposite - something that does not try to be
| a spreadsheet, but gives me a grid view of a database table,
| with concurrent edits a la google sheets, _and_ lets me access
| the same data from my webapp backend.
|
| 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
| kgodey wrote:
| This is what we're trying to do with Mathesar
| (https://github.com/centerofci/mathesar). We probably don't
| meet your needs yet because we don't support real-time
| concurrent editing, but we're actively working on the project
| and it is early days.
| zem wrote:
| ooh nice, i'll star it and follow the progress with
| anticipation :)
| ar-jan wrote:
| Have you seen https://github.com/nocodb/nocodb? I'm not sure
| it supports concurrent editing, but seems like it might.
| zem wrote:
| I have, and it does not. I filed an issue asking if it was
| on their roadmap, but they said they didn't have plans for
| it.
| bsder wrote:
| Or, alternatively, I want a spreadsheet that can be driven by
| an external program.
|
| 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.
| zem wrote:
| in my case the killer feature is the collaborative editing,
| but yes, it would be great to have the spreadsheet just
| running in its own server and supporting web connections
| but also rpc calls from another process running on the same
| box. if grist supported that it would likely satisfy my use
| case completely.
| mgummelt wrote:
| Founder of https://plato.io here.
|
| We support concurrent editing, so you see updates from your
| teammates in realtime, but we just haven't built a frontend
| for it yet, so you don't get the visual indicators a la Figma
| of where your teammates are and what they're doing.
|
| Email me if you want to chat more: mgummelt@plato.io
| ale42 wrote:
| ... another Electron app? :-(
| lordofgibbons wrote:
| Honest question since I see a lot of similar comments on HN:
|
| 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..
| Alifatisk wrote:
| See it this way
|
| No application < Electron < Native app
| nvella wrote:
| From lived experience, creating a cross-platform application
| via abstracting the relevant native interfaces versus
| targeting web with all the _fun_ that entails are effectively
| equal levels of pain. Developing rich web apps isn't free
| either; I needn't go into the issues surrounding the
| revolving door of frameworks, contrived state management
| patterns that seem to change every year, the total lack of
| standard controls outside of built-in web elements that look
| awful which inevitably means that at some point, _you will_
| have to be doing DOM manipulation for something that is
| otherwise built-in on an OS's native toolkit, etc etc. And
| then when you put all of this together, you add yet another
| 500MB Chromium instance onto your user's desktop and the
| thing feels like a social networking app.
|
| 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.
| nolist_policy wrote:
| Yep, what's missing is a WebView standard for desktop, like
| Android and iOS provide. Where these apps are a thin
| wrapper around a system provided browser engine. And let
| the user choose the engine (gecko, blink, servo, ...).
| nvella wrote:
| The concern is not really around disk but memory, opening
| just a few Electron app instances is enough to bring a
| machine with 8GB of RAM to its knees. I'm almost
| convinced that this is some kind of a planned
| obsolescence plot.
|
| 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.
| nolist_policy wrote:
| You can solve that with such a standard. Like when you're
| selecting the gecko engine it'll always run a Firefox
| process in the background, serving not just the normal
| Firefox browser frontend but also these WebViews. Kind of
| like ChromeOS does it. Of course every app will get it's
| own isolated browser process, but that's already the case
| when you open multiple tabs and it performs great.
| pjmlp wrote:
| No you won't, because it will be the same complains from
| Electron folks that the provided Gecko isn't the version
| they actually care about, and how testing is soooo hard
| when caring for anything beyond shipping Chrome with
| their application.
| pjmlp wrote:
| If it is to be done with Web technologies, than embrace the
| Web.
|
| 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.
| db48x wrote:
| Did you guys read the web page? Specifically, the part
| where it says "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."?
| pjmlp wrote:
| I am replying to the remark _"... another Electron app?
| :-( "_, regardless of how this one was actually made.
| db48x wrote:
| You said "In this specific case, I rather use Google
| Sheets or Microsoft 365 on the browser, than yet another
| Electron app.". But right there in their README they tell
| you that you do not need to use an electron app; the
| spreadsheet can be completely contained in a webpage that
| you can use in your favorite browser.
| pjmlp wrote:
| Since you insist on the matter,
|
| " 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.
| db48x wrote:
| That quote just proves my point. If you don't want to use
| the electron app, use the web app. If you hate electron
| apps, then _ignore_ the electron app. Pretend it doesn't
| exist.
| pjmlp wrote:
| The Electron app shouldn't have been written in first
| place, the web suffices.
|
| No need to help Google take over the Web even further,
| besides the waste on local resources.
| CyberDildonics wrote:
| I agree, if it can be done in electron it should just be
| a web page. It will run faster be a tiny fraction of the
| size, and now that webasm exists, for the first time ever
| someone can compile native software to a generic form and
| run it in a JIT compiler on many different computers.
| viraptor wrote:
| This is a bit of a false dichotomy territory already. It's
| not Electron or fully native. It's Electron, or Qt QML, or
| Avalonia, or Swing, or ... There are good choices which will
| not look 100% native, but are massively better in resource
| usage than Electron. (which is not native looking either)
| With Avalonia for example you can cover 3 major desktop
| platforms.
|
| 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.
| qayxc wrote:
| > it doesn't matter if they exist, because I won't have
| resources to run them.
|
| 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).
| viraptor wrote:
| 16GB recent MBP. With browser, slack, spotify, vscode,
| terminal, etc. etc. all running on Electron and taking
| 11GB+, I started swapping when more demanding compilation
| kicked in. Ended up merging some of those into browser
| tabs and replacing others with lightweight alternatives -
| no more swapping.
|
| 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.
| PurpleRamen wrote:
| This is a server for self-hosting. The electron-app is just one
| way to use it, for those who want to run it offline on their
| desktop. You can also run it in docker and use your browser, or
| access it via the API with whatever you want.
| kleiba wrote:
| Another sign that I'm getting old: the editing of the video is
| way too fast-paced for me to understand anything what's going on.
| :(
| fragmede wrote:
| The corollary of YouTube/VLC/other programs being able to play
| videos back at 1.5x speed is that slowing videos down and
| playing them at half-speed is just a menu option away.
| kleiba wrote:
| That's a technical solution to a non-technical complaint,
| though :-)
| stronglikedan wrote:
| Unfortunately, all the videos on the landing page are
| embedded without such controls or links to external players.
| MalcolmDwyer wrote:
| I would say it's not your age, but I'm getting old too, so...
|
| 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).
| dgan wrote:
| I am not that old and after watching first 14 seconds : i have
| no idea what's going on
|
| Maybe because i don't use spreadsheets in daily job
| StevePerkins wrote:
| Even slowed down to 0.75x speed, it's like watching a street
| hustler shuffle three cups around with a little ball underneath
| one of them.
|
| When the narrator says, _" It's that easy!"_, I want to punch
| them in the face.
| burrish wrote:
| I am young and it was too fast for me too
| wazoox wrote:
| In fact with a passing familiarity of AirTable I immediately
| understand it but I think it's probably the intended
| audience...
| smcleod wrote:
| It was the annoying feel good backing music that got me.
| sachahjkl wrote:
| how about not using web technologies to make spreadsheet software
| ?
| bvan wrote:
| Yes, please.
| dsagal wrote:
| Incidentally, Grist runs on the desktop (Windows, Mac, Linux),
| see https://github.com/gristlabs/grist-electron.
| rrdharan wrote:
| ... using web technologies (it's an Electron app).
| wg0 wrote:
| I think web technologies have gone too far and too mature. The
| alternatives are not as much portable and approachable for some
| applications.
|
| 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.
| SoftTalker wrote:
| An application should not look identical on all platforms. It
| should instead follow the conventions of the platform.
| peheje wrote:
| Never understood this. I own Windows and Mac computers,
| Apple iPad and Android phone, and annoyed everytime
| software just doesn't look the same when I switch between
| platforms. Why must everything look different? That's why I
| love the web and web applications.
| vekker wrote:
| This is not immediately clear to me from the docs alone, but does
| this sync (in real-time) with a backend and support multi-user
| (with auth)?
|
| 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.
| notyoutube wrote:
| afaiu:
|
| * 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, ... ?)
| robbiejs wrote:
| Looks like a very complete, well-thought out spreadsheet
| solution. If anyone is looking for a simpler excel-like data grid
| component, have a look at DataGridXL (https://datagridxl.com), my
| product.
| freedomben wrote:
| Just some advice: If you want to plug your competing stuff on
| HN without getting down votes, you need to add some actual
| value in your comment.
|
| 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?
| robbiejs wrote:
| Thank you! Will keep that in mind next time
| gregwebs wrote:
| This is almost exactly the same as coda.io, which is much more
| polished, and I highly recommend for small data. Just looking at
| grist for the first time now it seems like it might not have
| commenting, which I find very useful sometimes for collaboration.
| Grist though is open source and seems to have an embeddable
| version.
| wslh wrote:
| But, is coda.io open source?
| mkl wrote:
| No.
| dsagal wrote:
| Big differentiators in Grist, in terms of features, are
| layouts, access rules, and formulas.
| ljosifov wrote:
| Another data point to the curious case of the unreasonable
| effectiveness of a 2D rows-columns rectangle of data. Looks like
| a 2D rows-columns structure is simple enough yet sufficient to
| cover 1) a matrix, 2) an Excel spreadsheet, 3) an SQL table, 4) a
| directed graph of nodes and edges.
| robertlagrant wrote:
| Just a small comment on your site: it shows examples of legal
| processes, and HR records, including people's pay.
|
| 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.
| anaisconce wrote:
| That's a great point. Grist employee here.
|
| 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).
| Terretta wrote:
| Not access controls by the user team governing the team,
| access controls governing you. For instance, most companies
| that "take your security very seriously" but also provide
| support let themselves browse customer data.
|
| 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.
| milkshakes wrote:
| this is a strange comment on a link to a github repo with
| extensive documentation, including a dedicated guide on how
| to set up self hosting: https://support.getgrist.com/self-
| managed/
| robertlagrant wrote:
| Thanks - I'm sure those exist, but I just meant from a first
| impressions from your website perspective.
|
| 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.
| totalhack wrote:
| Would this be embeddable in something like a custom chatgpt-style
| app? Say I wanted any tabular data that I'm interacting with to
| be a grist spreadsheet, for example. How many rows can it handle
| before the browser starts to feel sluggish? And how many grist
| tables in a single chat would start to cause issues?
| spandextwins wrote:
| Now that is something great! I wish more of this kind of stuff
| existed. Instead of coding I'm writing comments here. I need to
| get back to writing great code too!
| dang wrote:
| Related:
|
| _Grist - Open core alternative to Airtable and Google Sheets_ -
| https://news.ycombinator.com/item?id=30392227 - Feb 2022 (107
| comments)
| db48x wrote:
| Interesting product. The name reminds me of Homestuck, but I
| don't see any gushers...
| PurpleRamen wrote:
| Last time I tried this some months ago, it looked ok on paper,
| but a bit off in usage. Something about the interface and
| feature-set seems to lack polishing for me. It was also annoying
| that there was no easy way to add custom-widgets, despite having
| the ability for this. But I'm also no docker-wizard.
|
| A bonus was the desktop-app. Having the option to run it offline
| is a good choice.
| superb-owl wrote:
| I've been asking for something like this for a long time!
|
| 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!
| nilespotter wrote:
| A grist spreadsheet is an sqlite database:
|
| $ 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
| _boffin_ wrote:
| "Relational" spreadsheet... with v/h/xlookups, it's already
| relational. That, with dependent lists, there you go.
| vviers wrote:
| Happy (self-hosted) Grist user for almost 1.5 years here !
|
| 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 !
| qubex wrote:
| What I really want is a spreadsheet that separates formulas from
| data as Lotus Improv did, has a native understanding of tables as
| Apple Numbers has, and solves circular references as Microsoft
| Excel does.
| animal_spirits wrote:
| Apple Numbers has the most potential of any spreadsheet
| software in my opinion. It is so much easier to use than any of
| it's competitors, however the features are slow to come.
| qubex wrote:
| I agree, I use it intensively and extensively. I really wish
| it had circular solving functionality, as that is crucial for
| financial planning (in order to estimate debt on the balance
| sheet and interest payable on the profit and loss account you
| have to converge onto a solution), and it simply offers no
| ability to do that. So many other important features are
| missing to, from the ability to lock cells or sheets so
| others can't mess them up to statistical analysis and
| plugins.
|
| 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.
| WillAdams wrote:
| Well there's Flexisheet:
|
| 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.
| adamrezich wrote:
| for anyone who hasn't seen Lotus Improv before and is both
| curious about what it did differently from "standard"
| 1-2-3/Excel spreadsheet programs _and_ wistfully nostalgic for
| late 80s /early 90s corporate vibes, check out
| https://www.youtube.com/watch?v=rgGmKD87U3M
| dsagal wrote:
| [Grist founder here] On separating formulas from data, that's
| always been an important part of Grist.
|
| 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.)
| emmett wrote:
| Everything old is new again (FoxPro says hi
| https://www.altap.cz/images/salamander/features/database-vie...)
| speby wrote:
| This is true except FoxPro really was more of a 'normal'
| relational database model. It just had this 'tabular' view for
| its Database Viewer client front-end. FoxPro was certainly not
| a 'spreadsheet' product in the sense that Excel is.
| aidenn0 wrote:
| FoxPro was bundled with MS Office at one point, and it blew me
| away with how easy it was to make data-centric apps. It's the
| only thing I've experienced that comes close to a spreadsheet
| for enabling programming for those who would identify as non-
| programmers.
| spandextwins wrote:
| Oracle says "hi" too! I remember seeing ads in Infoworld for a
| product called SQL*Calc. As far as I know it was fully
| vaporware, Oracle never even did anything past a photoshop (or
| more likely ms-paint) advertisement for it, but somebody on
| usenet may have used it:
|
| https://www.orafaq.com/usenet/comp.databases.oracle.server/2...
| creer wrote:
| I'm looking for a "spreadsheet as text files" solution. Something
| that separates the programming, the data and the visualization.
| Any pointers?
|
| 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.
| benrutter wrote:
| A while back [this project (grid
| studio)](https://github.com/ricklamers/gridstudio) looked
| interesting but I don't think its being maintained.
|
| 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.
| antidnan wrote:
| Quadratic is pretty similar to Grid studio and still being
| actively developed (https://www.quadratichq.com/)
|
| But re:parent comment, I'm not sure I understand how you
| could handle the visualization independently
| creer wrote:
| It would not need to be particularly elegant. If the
| program-spreadsheet exports the right data, it can be
| rendered or GUI-ed separately - even by a program that
| watches for export file changes. Even by a spreadsheet
| viewer for the people who insist.
|
| A notebook lets you use various libraries or outside
| programs to do the rendering.
| creer wrote:
| If have also done this with graphical objects (think
| postscript). The program is on one side and generates and
| composes primitives into useful blocks and arrangements. A
| - for example - postscript viewer is on the side, watches
| for updates and re-renders the thing. You now have graphics
| as programming, with synchronous-enough rendering.
| creer wrote:
| For many years now, I have handled that by writing my own.
| For the right applications, you can use your favorite
| programming language and "simply" restrict yourself to
| working on named cells and cell arrays (instead of all the
| possible data structures that are normally available.) But -
| of course - that leaves you having to re-implement
| spreadsheet features on your own. When it's a long life
| program, that's still worth it.
|
| CPAN has a few modules in these general directions...
| Spreadsheet::Engine, Spreadsheet::Perl, Spreadsheet::Edit -
| some independent, some acting on a spreadsheet file.
| ollien wrote:
| heh - a bit off topic, but Grist was the first place I ever
| applied for a software job. I was a high school student looking
| for a summer internship. I remember bombing that phone interview
| (I was asked about some JS semantics, and then I badly described
| what a hash table was). They also had a code challenge that you
| had to email the output to to some hiring address; was a cool way
| to do it.
|
| Nice to see they're still around, 8 years later.
| arilotter wrote:
| oh my god I just spend the last 6 months building something
| exactly like this as an internal tool because i couldn't find
| ANYTHING open-source that was remotely powerful enouhh for what i
| needed. this fits basically every single use case i had, i would
| only have to write a custom storage format to make data git-
| trackable.
|
| i'm gonna go cry now.
|
| please don't tell me this has been out for a while and i missed
| it.
| nusl wrote:
| I've been using Grist for quite some time now. It has its
| limitations but overall it's amazing and, for many things, better
| than Airtable and effectively any competitor. Being able to write
| Python with their decent docs is also pretty great.
| gnarlouse wrote:
| Looks like a neat product, really happy to see it is open source
| bartekedgenode wrote:
| Its rare to find a product that is flexible, powerful and well
| developed. Grist is all of those. There is a lot of resources
| available so you can move through problems quickly, and on top of
| that you can connect pretty easily with knowledgeable grist staff
| to get answers and help. Grist is the best!
___________________________________________________________________
(page generated 2023-11-02 23:01 UTC)