I'd say if you know React or Vue or another framework and it fits your project well, then no. If you are learning though, there is arguably much less to learn (in particular, not having to juggle 3 languages). And if you are building something very serious, it's suitable: nearly all of Grist frontend is GrainJS, and it's a very big performant real-time collaborative long-lived single-page app.
It enables much of what a large framework like React enables, but with a much simpler implementation, less tooling need to use it, and (some may argue) more convenient usage.
It makes sense for a successful product that’s being hurt by competitors packaging it up and selling as a paid service. My advice: for a younger product, keep it actually open-source (FOSS).
With either Sentry’s FSL license or FOSS, you as a user can run your own. If you want a paid managed service, you can pay Sentry. With FOSS, there can be competitors who offer such service using the same exact up-to-date version, and undercut Sentry on price (since they aren't paying developers). With FSL, they’d have to run a 2-year old version. That’s a disincentive to competitors.
BUT: even with FOSS, a similar disincentive exists, because the maker of the FOSS software could decide to change license, forcing competitors to run a stale version or invest into their own development, or pay up for licensing.
Seems if you are small enough, pure FOSS is better for this reason (the option to release future changes under a different license is always there). But if you are big enough to have competitors, and you can’t convince enough competitors to pay or revenue share (e.g. through support agreements), then FSL can be a way to twist their arms without hurting most other users too much. (It does hurt to some extent, as the many arguments in this discussion point out.)
[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.)
Shhh, don't tell them about SQLite! It's the secret sauce behind Grist (I am a founder), and we are sort of competitors. Wouldn't want Monday.com knowing about our competitive advantage!
(Grist cofounder here.) "Co-code" first became popular with developers in the form of Github Copilot (and now others), adding productivity. But for spreadsheet users it makes an even bigger difference, enabling them to do what they didn't know to be possible.
This is especially true in case of Grist, which puts the power of Python in the hands of spreadsheet users. So much more is possible, but most users will need some assistance to unlock that.
It's a spreadsheet, Excel was always our primary competition! :) The more Excel follows us, the better for everyone. Python is a start, but they have a way to go. Imagine proper relational data, self-hosting for cloud Excel, open-source, access rules....
Grist is a spreadsheet with Python support (I am a founder). Python does make some formulas far easier. Nice to see Excel has data science libraries included from the start, that's something we've had our eyes on for a while. On the other hand, Grist is open source and can be run locally.
There is overlap! I've spent the last 8 years working on Grist, which tries very hard to improve on Excel while keep its best aspects, and is open source.
Grist is it, in fact "GSheets + Airtable" is how people often see it. From https://blog.appsumo.com/airtable-alternatives/#3_Grist: "Grist has been described as if Google Sheets + Microsoft Excel + Airtable had a beautiful baby."
Ooh, excited to see mention of Grist (I am a cofounder). Python code and structured data are a great combination, and are particularly good for AI. We did an experiment where AI was quite impressive in writing Python formulas in Grist based on simple prompts: https://news.ycombinator.com/item?id=33809111
I suppose it's similar to rows.com's ASK_OPENAI("write a spreadsheet formula that..."). Most impressive is that it knows relationships between tables, and can construct correct lookup formulas, and do useful things with their results.
That's what I wonder about too. I imagine that a slow calculation would be fine if done once when the data is first loaded into the system. Once the results are in memory, any new data should only affect smallish subsets of cells.
This is the approach our product Grist (https://www.getgrist.com) takes for its calculation engine.
Keeping track of dependencies slows it down for the initial load, but beyond that, it only needs to calculate what's needed, so most updates are fast. Even though the engine literally evaluates user-defined Python code for every cell.
For someone who has only ever dipped one toe into "crypto", this is super informative. Especially good to read the constructive advice at the end (all the way until the bit about software-building burden, which felt rather random).
Looks great, and I like that there is a lot of overlap with Grist: https://news.ycombinator.com/item?id=25257521, https://www.getgrist.com (of which I am a founder). The differences are interesting: rows.com seems more focused on external integrations; Grist has API but is more focused on powerful formulas and layouts for working within the data.
I imagine the overlap will only increase. I take it as confirmation that these are good ideas to pursue.