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.
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 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.)
Any particular reason why knowing how useful it would be you’ve not implemented some kind of Newtonian iterator to solve circular references numerically?
formulas are a big part of coda and so much easier and safer than excel. I don’t know what layouts and access rules are in grist, but there are similar sounding features in Coda as well.
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.
