dsagal

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.

That should make it the format of choice for Chief Security Officers.

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.)

Big differentiators in Grist, in terms of features, are layouts, access rules, and formulas.

Incidentally, Grist runs on the desktop (Windows, Mac, Linux), see https://github.com/gristlabs/grist-electron.

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!

Founder of Grist here (https://www.getgrist.com/):

- focus on small teams and individuals

- open source (with community contributing!)

- can be run self-managed

- portable data (lossless export in SQLite format)

- full of great features (granular access rules, formulas with python, conditional formatting, webhooks, etc etc)

If it's little-known, it's because we spend too much time building, not enough time selling.

Grist doesn't have a mobile app, but has pretty decent UI on mobile browsers.

(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."

It's not quite type safety, it's all about order, and it's definitely not specific to Javascript. Here's Python3:

  >>> sorted([10, 2, math.nan])
  [2, 10, nan]
  >>> sorted([10, math.nan, 2])
  [10, nan, 2]

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).

Thank you!

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.

Grist Labs | Software Engineer | New York, NY or REMOTE (US) | Full Time | https://www.getgrist.com/jobs-engineer

We are building Grist, the evolution of spreadsheets, an easy-to-use platform for individuals and small businesses to organize their data better.

Grist (https://www.getgrist.com) gives non-technical people the power of a relational database, versatile data layouts, real-time sharing, access control rules, and much more. Our more technical users appreciate Python formulas and API support. On top of all that, Grist is open-source (https://www.getgrist.com/blog).

* Software Engineer: 4+ years of software engineering experience.

* Tech: TypeScript, Node.JS, SQL, Python.

* Fun puzzle: https://bank-puzzle.getgrist.com/ is encouraged as part of the application process. Or apply by emailing your resume to jobs@getgrist.com.

Where do the form responses go? Is it easy to connect them to get pushed to another system?

Column-wide formulas are an example of Grist data being more structured than a traditional spreadsheet. In a spreadsheet, one might type over a cell because it's an exception. In Grist, you'd need to think what makes it special, and change the formula to reflect that. E.g. `=$Price - $Discount if $Status != 'Comped' else 0`. But once that exception is turned into a rule, it applies to all records. Which is a good thing.

Founder here :)

While working at Google years ago, I co-founded a nonprofit for math enrichment classes. I ran it in my spare time, using Google Sheets, until the spreadsheet setup grew too unwieldy, time-consuming, and frustrating. Back then, I bit the bullet, and rebuilt it using Django. It took months of my evenings and weekends — just to recreate a database version of what I almost had with a spreadsheet.

That got me thinking what made spreadsheets my tool of choice to start with, and what made me switch to a database, and if we can have the best of both worlds. So we built Grist to be a “relational spreadsheet” — most of what a spreadsheet has, but with more structure, linking between records, and a flexible UI on top.

I’ve been using Grist daily, it’s now my tool of choice. I’d love to know what uses you put it to as well!

OK, got far enough through the first tip -- seems useful, although a bit abstract of course.

Is there any help from Please on building TypeScript projects faster?

Which is why I'll hand-write HTML until I have more than a handful of posts.

Banner on top of https://status.aws.amazon.com/ just has an update from 8:36AM PST -- just removed -- even thought it's only 7:42AM PST. I guess it's really manual firefighting there.

I had much hope for project references with --incremental and --watch mode to be quicker than using external tools, but they still seem to recompile a lot (and so take a long time). Or maybe just because I am some tsc versions behind?

This is really cool. The original post is great in putting it in terms of a concrete example. It would be cool (challenging but possible) to have a 3D visualization of collapsing f(x)·g(y) like you describe in the context of that same example.

It's certainly a useful mental model.