The Wisdom of No Escape

I am using both Coda and Notion. (If I had found Coda first, I might not have gone to Notion at all.)

But whichever one of Coda, Notion and Fluid provides meaningful integration with traditional documents will have a massive advantage. But I don’t even want to think about the complexity that would be involved.

Fluid could be interesting, but seems to be pure vapourware at the moment. And with MS’s recent track record on Windows 10 updates, the changes and backtracking on OneNote, the various versions of all their products, I unfortunately do not hold out much hope for Fluid.

And just in general - I love these new tools, but in the major organisations that I have worked with, people still send out spreadsheets, have them collated, and then posted onto Sharepoint, or Box…

I am not sure how one goes about improving uptake…

@David.Greenwood @Piet_Strydom I’m pretty surprised to hear that one’d have problems with doing a balance sheet of financial planning in Coda.

It takes some effort to start thinking the Coda way (in organized records and not simple two-dimensional sheets with freeform cells), but in the end you’ll be gratified with a solid model, and not something that is a table simply because with all the cell formatting it looks like a table.

There are some shortcomings in display: e.g. Coda doesn’t look as compact, and you cannot organize records horizontally (i.e. have a transposed table where properties go top to bottom and entries go left to right) without compromising your model. But I hope those get addressed eventually.

I have nearly 150 rows in my current balance sheet… Now you want me to turn that on its side, display it in less than optimal sizing, so that I can be “gratified with a solid model” ?

It’s good to be positive about a product, but too much optimism can be just as damaging as being pessimistic. Excel is jut better at some things, than what Coda is. Doesn’t make Coda bad.


I don’t want anyone do anything :slight_smile: I’m only saying that quite often the frustration for Coda comes out of misunderstanding its approach to data design. It’s much closer to databases (think Access, SQL, Airtable lastly) than spreadsheets. It’s venturing into software engineering territory sometimes (or maybe that’s just me). That’s my idea from hanging around for more than a year in this community and with Coda in general.

And yes, for some uses spreadsheets are often a much better choice. Fewer constraints, easier to get from zero to problem solved.

P.S. I’ve been working as a Coda expert for hire on some of the most complicated financial docs. Think of the setup where each row not just contained what could be a simple cell’s value in Excel, but it also had a table where each row described each of those other rows and how they should be calculated. A super easy feat in spreadsheets became a very complicated setup in Coda. Yet the client wanted it done specifically in Coda because he believed in the tech and how in the long run it would be better than running those calculations in spreadsheets.


Anyone thinking Coda or Airtable or Notion are apps that are going to kill spreadsheets are laboring under some serious misinformation and misplaced perceptions.

Databases and spreadsheets are two very different animals despite there being some overlap, more so in recent years than in the early incarnations of each. Coda and its like applications are database (read row and record) centric whereas spreadsheets are predominantly cell centric.

If anything, spreadsheet development is moving more towards incorporating elements of database design and operation than databases are moving towards spreadsheets.

Spreadsheets for personal computers have existed alongside databases since the late 70s when VisiCalc and DBase, both of which I used in the first decade after their release, became the first practical incarnation of each on microcomputers. And there were database and spreadsheet like applications on mainframes before that. Each of these categories have developed significantly since then with neither one showing signs of fading away.

I can see no change to this scenario in the foreseeable future but that is not to say that development down the track will not see that happen. Maybe at some stage in the future a savvy and skilled development team will be able to effectively combine the features of both into one application and provide a user with the ability to switch between the two capabilities as required merely by changing a setting, even possibly down to an individual cell level. Nothing should be ruled out.

Until then there is a definitive space for the two applications and each has elements which the other cannot duplicate to anywhere near the same degree, or even at all.


Yes you are correct, I think the excitement here is that spreadsheets have been high-access low barrier to use, whereas databases have been low access high barrier to use. As such, many functions that would have been better suited to database use were shoe-horned into spreadsheets. What we are now seeing is a huge portion of spreadsheet share migrating to the more appropriate easier-to-use database tools.


I’m trying to think, but what can’t be done in Coda | a database format that can be done in spreadsheets?

Seems to me that dbs are a strict superset (with perhaps some performance costs when calculating things like running totals).

Help me understand what I’m missing

There is so much that spreadsheets, particularly an application like Excel, can do that is simply not possible in a database.

Addressing individuals cells cannot be done in a database. Or if there is a workaround, which I am not aware of, it will generally sacrifice something in the process.

The sheer number of functions in Excel compared to Coda or Notion or Airtable puts its capabilities way ahead in terms of fit for purpose. You don’t use a screwdriver to drive a nail although you possibly could in some scenarios! However, the outcome will not be ideal!

Excel and similar spreadsheet applications effectively have their own programming language built in which can be used to extend capabilities far beyond the basic capabilities that many users, even perhaps the majority of users, are content with and which I defy anyone to be able to fully replicate in Coda, Notion or Airtable.

I have seen almost full blown accounting applications designed in Excel and whilst this may be possible to some extent in Coda, Notion, Airtable and the like, again, I defy anyone to produce results comparable to what can be achieved using Excel.

Also, producing output in report form that would be suitable for dissemination to internal managers and externally to clients, banks, investors or other interested parties is easily possible in Excel but not currently in applications like Coda, Notion and Airtable. At least not without the use of a third party application linked via an API.

I have been working with personal computers since the 70s when I bought my first computer, a Commodore VIC 20, and have yet to see an application that can claim to make all other applications redundant. It has not happened despite some claims to the contrary.

A properly designed and purpose built application will beat a “jack of all trades” application hands down every time in terms of capability, performance and results. To program the capability to outperform purpose built applications into an “all you will ever need” application would likely bog down that second application to the extent that it would be unusable in most scenarios.

That is not to say that it will not one day happen but until it does then it is a case of horses for courses in terms of using software that is fit for purpose in both design and capabilities.

I could list the many, many instances where spreadsheets are THE go to tool that cannot currently be surpassed but such information is readily available from reputable websites and space here does not really suit that analysis.

I encourage anyone thinking of dropping spreadsheets to look beyond the hype, and there is a lot of that around the new breed of apps like Coda, Notion and Airtable.

1 Like

Hi @Peter_Wills,

I believe that - like most of the times - the overall topic relies in the “and”, rather than “or”.

Totally quoting @Piet_Strydom’s post:

Any solution, by nature, is optimal within certain boundaries.
I agree that many excel solutions could be done in a relational perspective, but it’s not necessarily better or easier.

My idea an my experience suggest that more often than not, the spreadsheet approach is the screwdriver.
Sometimes a more structured oriented approach would be really simpler.

Anyway, the campaign is not: “Let’s translate every spreadsheet into Coda”.
Rather, how a data-driven application can benefit of a solution that aggregates collaboration, document editing, automation and interaction.

After all, Microsoft - with Fluid - and Google - with Tables - are themselves implementing similar approaches in order to add such capabilities.

Let’s enjoy and be part of this.


Interesting conversation. I had zero knowledge of Excel (beyond Cell A1+A2), I don’t know what Pivot table is, never done any Coding in my life and don’t understand Databases (most of the above is a foreign language to me). Nut, it’s interesting that some of my Coda challenges that I’ve overcome are things that even the Coda support told me are not possible to do in Coda. It’s so intuitive, I always find a way to get that “not possible” thing working (thanks to in part spending hours watching @Paul_Danyliuk’s and other’s YouTube videos over an over - thank Paul! You’re a madman!). So my 2 cents, I do think it can be a huge financial tool. I’ve done those tables that are 100+ columns wide and some 10K+ rows. I now use it to run my entire business including finance with zero integrations (I’m not there YET), CRM, etc. I live in Coda vs. bouncing around (Not sure I should say this, but I don’t even use DropBox anymore - shhhhhhh). I know I’m speaking out of my league, but for a non- technical person, it’s the only tool I’ve EVER used that has enabled me to create the likes of enterprise software and I’m 100% in control of all changes, additions and my interface. Each update feels more and more that they are going in a direction that will hopefully be a full alternative to Microsoft (not that I have anything against them). Thanks for sharing in this community and jumping into your convo. You guys are the equivalent of a college course!


This exactly. People are used to the mental model and flexibility of spreadsheets, so the world is shoehorned into a spreadsheet.

Turns out, everything can be done in tables. There are tradeoffs, but they trade consistently in favor of table data models in the context of most tasks.

Spreadsheets are essentially a directed acyclic graph under the hood. The advantage is that they are very flexible at the outset, the disadvantage is that they are brittle if you ever have to make changes.

I’m down for the challenge :slight_smile: Coda is Turing complete, so it is as expressive as any possible programming language. It’s also much more elegant and understandable.


Reading this I almost gave into the urge to make a bet :laughing:

Of course there are things that you can do on Excel that you cannot do on Coda, such as:

  • connect to Windows API (COM objects) through VBA
  • play MIDI files
  • interact with your filesystem, devices, drivers
  • make a 3D shooter game on it (although I tried lol)
  • manipulate doc schema (that’s a real bummer yeah; one of the reasons why I didn’t gave in. Although in many cases one could work around that with some smart schema design)

You have to do these with VBA though, which is an un-nice language to learn. Or hire $200+/hr consultants to code those for you without a slightest chance of you being able to maintain it yourself ¯_(ツ)_/¯

(it would be fair to say here that I’m myself a $200+/hr consultant on Coda, albeit I share a lot openly, and some more with patrons.)

@Brandt_Smith1 thanks for the shoutout!


Ok yes, those are some things Coda cannot do. Also, Coda is terrible for training neural networks. Though a fun exercise :slight_smile: Maybe one day I’ll build a neural network doc to share.

Oh, a few more things I should mention as well.

  1. I’m actually very pragmatic and that means Coda as well. I would dissuade a customer to use it where it’s not a good fit. I actually don’t care about losing profits there, I think about providing care first.

  2. I don’t support that whole “no code” hype. Tools are tools, each fit for its purpose. Platforms like Coda solve some pains really well, whereas some things are much better done traditionally. Truth is, serious customers don’t care if it’s code or no code — they want their pains solved as fast as possible with as few pains emerging eventually as possible. Mindlessly pushing airtable/coda/zaps/webflow/bubble/name-your-nocode-tool is blatant fanaticism and short-sightedness


100% agree.

I think even that the terms “No Code” and “Low Code” are a little bit disingenuous.

The reality is that if you learn Coda (or some other tools like Bubble, FileMakerPro, perhaps others) you really have learned how to code!

Lots of companies seem to want to shy away from that. I’d guess it’s because they want to make it seem easier. The reality is that:

  1. Sometimes building what you want is hard. That’s ok.
  2. Learning a programming language | new paradigm is frustrating and sometimes discouraging. That’s ok, too.

I see it as a different sort of opportunity. Thanks to Coda’s amazing language design and your great videos, @Paul_Danyliuk, @Brandt_Smith1 can learn to code! It’s a skill eventually everyone will learn, just like reading and writing.

And perhaps like reading and writing, there was a time when it had to be done painstakingly and couldn’t easily be shared, and as technology has progressed it’s now much easier for anyone to create and share.

This is why I like Coda’s Maker framing (not Low-Coders). Because the point isn’t that it’s simple (as you’ve noted @Paul_Danyliuk, sometimes it’s not, and @Peter_Wills you’ve pointed out that some things are impossible in Coda) but it’s incredibly fast to develop.

That part is cool. Perhaps after you’ve built a proof of concept in Coda, you’ll be forced to build the final thing in C++ for performance. But Coda is a wonderful tool to think and explore with, and when that’s the case many things end up being completely built there (see python).

1 Like

Exactly! I couldn’t agree more. I could compile many examples of things I do in a spreadsheet that may or may not be possible in Coda, Notion or Airtable but it would take hours/days and would likely not convince the “anything a spreadsheet can do Coda can do” fraternity so I choose not to waste time on that exercise.

I repeat, I have used spreadsheets and databases since the late 70s, read VisiCalc and dBase, and Coda and Notion over the past 2 years or so and I do have an inkling of what I am talking about.

Hi @Paul_Danyliuk and others,

Now that I have some Coda brains, the balance between what I would do in Coda and in Spreadsheets has changed quite a bit, towards the Coda side.

It requires a bit more thinking and planning, but I am at the moment busy doing a financial planning forecast, and doing so in Coda.

I want it it to be able to do scenario planning:

  • what happens when I retire (So an arbitrary number of years into the future based on the user’s age)
  • what happens if I die,
  • get retrenched,
  • get ill tomorrow
  • etc

I started doing that in Excel, a while ago, but when I now restarted the project, I did so in Coda. I think I have the solution for a MVP in my head, and is now busy making it.

There are some bits that I hope is still either on the Coda development list, or I can implement a workaround - e.g. how to get several people getting to use the functionality with confidentiality. There are a couple of existing ways I can think of, but they all have drawbacks. Another topic is more formulas…

Still learning, still rambling

1 Like

is Coda builted-on Fluid Framework of Microsoft?

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.