Always overlooked point in these pro/anti-spreadsheet discussions:
A spreadsheet gives you a DB, a quickly and easily customized UI, and iterative / easy-to-debug data processing all in a package that everyone in the working world already understands. AND with a freedom that allows the creator to do it however they want. AND it's fairly portable.
You can build incredible things in spreadsheets. I remain convinced that it's the most creative and powerful piece of software we have available, especially so for people who can't code.
With that power and freedom comes downsides, sure; and we can debate the merits of it being online, or whether this or that vendor is preferable; but my deep appreciation for spreadsheets remains undiminished by these mere trifles.
It's the best authoring tool we've ever devised.
EDIT TO ADD: the only other thing that seems to 'rhyme' with spreadsheets in the same way is: HyperCard. Flexible workbench that let you stitch together applications, data, UX, etc. RIP HyperCard, may you be never forgotten.
Right? Spreadsheets have such a low barrier of entry. I use Google Sheets in a middle of a farm field to enter plant growing records on my cell phone. I don't even have good reception at times so the sheets are in offline mode; they'll synch when I get back to the house.
Crappy, crummy records are oftentimes better than no records. Farming is data-heavy and data-starved at the same. A learning cycle is a year, and one year is not like the other one.
And for those who can, Appscript gives your spreadsheet super powers.
For those who don't know, you are not stuck with writing JS in the Appscript integrated web IDE that comes with Google sheets (though honestly it's not too bad itself).
Using clasp, you can develop your code locally in an IDE of your choice, in typescript and have a build step compile those to js, and have clasp push it to spreadsheet.
Once you have the tool chain set up the DX is quite nice.
I spent some time with Apps Script a few weeks ago. It has some strange design decisions:
1) Everything runs on the server, including triggers and even custom functions! This means every script call requires a roundtrip, every cell using a custom function requires a roundtrip on each change, and it feels much slower than the rest of the UI.
2) You can't put a change trigger on a cell or subset of cells, only on the whole sheet. So you have to manually check which cell the trigger happened on.
3) Reading and writing cell values is so slow (can be a second or more per read or write) that the semi-official guidance is to do all reads in a bunch, then all writes in a bunch. And it's still slow then.
4) A lot of functionality, like adding custom menus, silently doesn't work on mobile. If your client wants to use Sheets on mobile, get ready to use silly workarounds, like using checkboxes as buttons to trigger scripts and hoping the user doesn't delete them.
Overall I got the feeling that Google never tried to "self host" any functionality of core Sheets using Apps Script. If they tried, it'd be much faster and more complete.
> 2) You can't put a change trigger on a cell or subset of cells, only on the whole sheet. So you have to manually check which cell the trigger happened on.
This is true of MS Excel's scripting language (VBA) as well. Worksheets are objects with events; cells are objects without (VBA-accessible) events.
But Google Sheets remote procedure calls are vastly slower than local OLE/COM dispatching. (And VBA/Excel presumably uses the optimized tighter COM interface binding instead of the slower high level COM IDispatch. Sure there's some overhead but it's nothing compared to Google Sheet's network overhead.)
Not only is scripting Google Sheets indeterminently and syrupy slow, it also imposes an arbitrary limit on how long your code can run, making a lot of applications not just inefficient but impossible. Running your code in google's cloud doesn't make spreadsheet api calls any faster, it just limits how long you can run, them BAM!
To get anything non-trivial done, you have to use getSheetValues and ranges to read and write big batches of values as 2d arrays.
It's easier to just download the entire spreadsheet csv or layers and bang on that from whatever language you want, instead of trying to use google hosted spreadsheet scripts.
> Everything runs on the server, including triggers
I think that’s a consequence of the fact that multiple users can simultaneously edit a sheet. Yes, Google could special-case the “you are the single user of this sheet” case, but that’s extra work, and, I think, would be fairly complicated when handling edge cases where users frequently start and stop editing a sheet.
> I think that’s a consequence of the fact that multiple users can simultaneously edit a sheet.
No, it's not. Built-in functions like SUM recalculate instantly, and custom formatting rules (e.g. "color green if above zero") get applied instantly, even when there are multiple users editing a sheet. Running custom functions and triggers on the server is just a decision they made.
This reason doesn't make much sense to me. Let's say I write a non-idempotent custom function. It makes the spreadsheet behave weirdly: recalculating a cell twice leads to a different effect than recalculating it once. Does it matter whether the function runs on the server or the client? No, the spreadsheet will behave weirdly in either case, even with just one user.
Can we make a programming language that will save developers from that? Maybe, but that would be very hard and that's not what Apps Script is trying to do. It already allows non-idempotence, trusting developers to write idempotent code when they need to. So it could run on the client just fine.
Or use the API to program in anything you want. We use Google Sheets for our accounting system, loading data via bank APIs and a cron-driven python script. We used to use Xero, but it couldn't handle the different tax regimes we operate in.
That looks like a great usecase. Would you be able to write about the architecture. A lot of us would love to be able to do things like this in Sheets, I'm personally trying to integrate a forecast estimate into Sheets
I wish there was a better way to make spreadsheets use a database as a backend. Most of what people do with a spreadsheet would be better done in a database - but a database needs a lot more training to use (if you don't have the training you will make something worse than spreadsheet with your database!)
No because the datagrid in MS Access is too rigid and doesn't have the extensive slice-&-dice features of MS Excel. My first consulting gig was creating customized MS Access applications. Despite that experience, I use MS Excel today because I know that MS Access is too limiting.
>No because the datagrid in MS Access is too rigid and doesn't have the extensive slice-&-dice features of MS Excel.
i'm not saying it worked or worked well, but i'm pretty sure the point of Access in the office suite was so that you could access Access (get the clever marketing?) data from within Excel and then do all the excel things you were used to.
anyone know if that worked or didn't? DDE and all those other projects were always pursuing this as a dream
Access's database is fairly limited and prone to corruption, especially using in a (local) network setup. The better solution would be to have real backend database and use ODBC to sync in data to Excel and Access. Maybe back in 1995 it made more sense but that's before my time.
Access was pretty amazing on its own back in its day, ignoring its multi-user limitations. It glued together a relational database, visual query builder, GUI/Form Builder, and reporting. You could create forms with sub forms that linked tables together. Also had a datasheet view. All of this without touching VBA code, but VBA was there when you needed it.
I think it worked technically and I‘ve seen a few Access-based solutions to problems faced by people/groups without any real access to development resources. However, these solutions pretty much always came from people with rather technical mindsets and I think many of them involved tinkering in the evening and on weekends. So, my assumption would be that the demise of Access was more about UI/UX, complexity, familiarity and the like than it was about functionality.
It sounds as if Excel has grown to incorporate most database features.
Does it have atomic transactions yet? That's the main thing keeping me using small databases like Access even when a mere spreadsheet would do otherwise.
Microsoft Access requires more training (tables, foreign keys...) and from experience most of the people using Excel managed to bend it to do what they wanted.
The maintainability of the resulting systems was not great, but they did the job and worse is better I guess..
Add in to that: programming VBA for Excel spreadsheets is extremely trivial; programming in VBA for Access is second worst only to programming in Visio, MS Office's awful drawing program.
Hard agree here. The value of combining database + UX + logic into a workbench is like the app we've been reinventing over and over again. It's why Visual Basic still lives :-).
And yes, not the greatest way to proceed once you know what you want, but a heck of a way to iterate quickly and identify the actual requirements.
>>It's the best authoring tool we've ever devised.
100% agreed. Creating a spreadsheet is declarative programming, and Excel (and now Google Sheets) has made more developers than any other platform (probably by an order or two of magnitude).
I do not know a business that was not CRITICALLY dependent on Excel for actual business operations through the 90s and 00s...and the same is likely true today.
The Google suite of Apps was born multiuser. They perform better then Microsoft's apps when multiple people, even dozens of them, are bashing on a single shared document. Document sharing is more powerful than sharing a window or a desktop. It changes the way people work together.
I would not have agreed readily with that statement until three years ago, when I actually started working in GS as part of my job. I couldn't have imagined how seemless and well-implemented collaborative editing had become IRL.
yes, that's true. It also brings the issues related to that - it's easy to delete the whole org data, change things uncontrollably, corrupt the data, there entries in the tables are free-form (well, you have to do programming to make it more robust).
it works fine initially, but for long term it's usually more productive to have custom software.
> it's usually more productive to have custom software.
If you multiplied the custom software development effort and cost to the multitude of places and use cases people in an organization are using spreadsheets I think you’d quickly find that it’s infeasible. And that’s not even taking into account how much value the adhoc-ability of spreadsheets adds to the equation. Most spreadsheets can be completely refactored or thrown away in a rather trivial manner. The sprint nature of software development screens out most things that could be spreadsheets. I’ll build it in an hour instead of waiting 2 weeks to get on the next sprint.
The software development process is too rigid for rapidly changing business needs. Having to spec out requirements and such is often an unknown and something you’re doing live in the moment when creating the spreadsheet itself.
I've long wondered why there's not a more incremental transition path from spreadsheets to a full blown database with a custom UI. It just seems like spreadsheets are right on the cusp of being able to fill that that role but lack just a few key features which might make it viable (structured data, native SQL query support, custom UI elements, IDE integration, etc).
At my old gig, all of our content generation was in Google sheets or Airtable.
Anything we made would have _never_ been as good a UI and would have stopped us from being able to publish new content. The other nice thing about them is you can scale the integration effort. You can download a sheet from GS as a CSV then upload that in an admin page and you can probably ship that feature today. A tiny bit more effort and you can add a 3rd dimension to the data by finding an XSLX library and exporting the page as an Excel workbook. Eventually you can do something with their API where you just click "reload data from the master sheet" and you can generate all the data you need to preview the changes on the frontend. That's what our Airtable integration looked like. Airtable was very "pull this in via API" native and had a better way of expressing higher dimensional data in cells which matched nicely with Postgres storing arrays in cells.
I didn't realize it at the time, but I my first encounter with the "solves every problem with a spreadsheet" user type came very early in my career.
I worked in a computer lab in college, ca. 1989. One of my colleagues was in the mechanical engineering program, and had a bias generally for "solve the problem" over "elegant solution" or "appropriate tool" concerns. (I love the guy to this day, to be clear.)
When he first came to work at the lab, he was the only guy to have installed FORTRAN on his workstation. It didn't work well.
Then he discovered Lotus 1-2-3 and its macro language. He DELIGHTED in making the rest of horrified by creating all sorts of boundary-pushing utilities in Lotus macros. To be clear, he was at least 50% "doing a bit", and leaning into the "engineer only knows one tool" gag we'd all been riffing on. But he was still doing absurd stuff in Lotus that would've been better built in, say, Turbo Pascal or Turbo C.
I had no idea back then that this pattern would become so prevalent.
I worked at a law firm where the chief accountant (not the accounting manager, but the guy who made most of it work) did everything in Excel...including writing memos and other documents. I think the only other program he used was Outlook, and he probably drafted email in Excel.
As of this writing, there are twenty-two comments on this thread about airtable. All but four are either you or responding to you bringing it up.
I think it’s fair to say that whatever its advantages may be, it is relatively unknown, and therefore a higher-overhead entree into programming than straight up spreadsheets.
Just learning about it or finding fit for purpose takes more time than diving into a spreadsheet. And as always the argument is not that spreadsheets are more powerful or better, but that they are much easier and more incremental to learn and start with.
You are absolutely right and it makes sense to start with a spreadsheet. As I said elsewhere, you have to reach a pain threshold in order to look for alternatives to Excel. And how soon you reach the pain threshold depends on how big your data is and how many users are trying to modify the same data at the same time.
SQL and to an extent R were both created under the assumption that most people were not inclined to learn to program the computer. They could be expected to speak English and understand relational algebra, but they couldn't be expected to learn an imperative programming language. The existence of SQL stands as proof that at least some people 50 years ago thought there were multiple classes of user.
nothing makes it impossible, but they already have Excel installed on their computer and they learned how to use it. Depending on where they work they may not be able to install Python or R or a database.
Most people who have access to a spreadsheet don't have access to a compiler or interpreter, or the desire or time to learn them if they do. Most people learn what they need to do their jobs, and then go home and forget about it until the next day.
Why? We expect huge swaths of non-programmers to learn R to work with data. Seems like it just depends on the field. If Excel was an integrated Python environment (or VBA or whatever pick your language) then I bet users would have learned it all the same. Twenty years later I bet HN would be full of complaints about how people have a hard time transitioning to "real" Python because they learned the Excel flavor.
> We expect huge swaths of non-programmers to learn R to work with data.
I’ve worked in academics and industry around biologists, chemists, physicists, statisticians, bioinformaticians, and all varieties of engineers.
I’ve never seen “huge swaths” of anyone expected to learn R for anything outside of a few niche areas in statistics and bioinformatics.
What people are expected to know is how to use a spreadsheet. What people are often given is Microsoft Excel, and essentially nothing else. A lot of companies wouldn’t dream of letting random employees install or use R or Python.
It’s not ideal. But some battles can’t be won and aren’t worth fighting. Which is why people use Excel for so many things.
Because they don't know it's programming. Seriously. I dated a woman for five years who was an accountant and a spreadsheet wizard. I told her that doing what she did with Excel, she was just as much a programmer as me, and she flat-out refused to believe that she had the mental capabilities required to be a programmer.
Years after we broke up, a new company she joined required her to take a VBA training course, and she texted me and told me I was right, VBA was easy and her biggest challenge was being patient while the other students struggled.
Discoverability is a big one. People really underestimate the value of having a menu, an actual fucking menu, listing all the functions you can use. Typing and getting autocomplete is a poor substitute, and you don't get even that in SQL, Python, or R by default - there are products that can provide that for you, but only after an expert has set them up.
I agree. However, so many of my use cases include a one-to-many relationship that I was outgrowing excel/sheets too quickly. Once a project added a VLOOKUP, it hit an inflection point in complexity.
I spun up a local Grist instance in my org, using SAML with our org's email authentication. It's intuitive enough that I've replaced a few shared spreadsheets with it (now with rowwise permissions) and powerful enough that I've also replaced a few internal CRUD apps.
While Grist is a brilliant product, I really dislike the spreadsheet marketing they use.
It's not in any way a spreadsheet, you can't use rows correctly and everything is stuck in columns. Not to mention the forms you use for input are not user friendly compared to a simple understandable coloured cell
The gap in conceptual complexity to switch to databases is just way too high for most people. One lets them accomplish the business goal, the other does not.
To expand on the overlooked point: it gives you a DB and a programming environment (however challenged) that you can use without needing sign-off from IT. In any moderately sizeable organization, getting approval to use anything but standard software is slow and painful.
Nobody wants to explain to IT that they need to install Python on their machine, or drivers for sqlite, or - god forbid - get a proper database. Because that requires sign-off from several people, a proper justification, and so on.
> It's the best authoring tool we've ever devised.
It is also a very bad co-authoring tool imo unless you have a very tight team and processes of how to use spreadsheets. I would not mind if I was using it alone. But spreadsheets encourage a certain naive "visual" approach to structuring data in them that can become an issue if you want to import the data to actually process it somewhere and your coworkers don't really understand this well.
Spreadsheets can be useful, however:
1. Speaking about excel in particular, localisation issues are an absolute nightmare if you happen to live in the wrong country (commas vs dots for decimal points) especially while importing CSV files (which is already unnecessarily complicated in excel). If somehow you don't notice these issues, you end up with wrong data without understanding there the error came from.
2. If your coworkers do not really understand very well how spreadsheets work, you quickly get to become really frustrated with issues coming up when you have to import a spreadsheet for actual processing. Datetimes with different forms, coloured boxes being meaningful, mixtures of text and numbers and whatnot.
Yes a big part of it is "people problem" rather than "technology problem" but imo spreadsheet technology (excel, google sheets etc) encourages a variety of practices that make it less reliable. If the technology gives you the freedom to mess up too easily, imo it is not just a people problem.
I agree. It's extremely hard to learn to use someone else's spreadsheet unless they're sitting right there with you watching you fumble through it.
I have a couple of spreadsheets that I use on a weekly basis, and I found it easiest to build both of them from scratch, despite the tons of examples floating around for exactly my use cases, and despite it being my first time building anything with a spreadsheet in 10+ years.
On the bright side, after using these spreadsheets for a week, I lost all desire to write apps to do the same things. Google Sheets is a good-enough UI and solves sync across different computers and mobile.
i never loved nor hated hypercard. it was straightforward and clever but i really only used it for one thing: i made cardstock labels and liner notes for my audio cassette "rips" of albums (my 20mb hard disk (we didn't have MiBs then) wasn't going to hold many mp3's ;)
i might have used it for burned CDs too, I can't remember. at work i had access to burning CDs at scale back then, I just don't remember when the blanks became cheap enough that nobody would notice my pilfering and and whether i still used my mac. i did burn disk backups to CDs
Also what you're looking for is called Microsoft Excel. Every one else is doing webshit UIs which can't be world-class by definition, because they hardly scale to real workloads :).
They can emulate behaviour of databases; but the missing parts missing will haunt you. Spreadsheets are a jack of all trade, mastering nothing, haunting you with everything;.an amplifier for the Dunning–Kruger, where people are misguided about data-quality.
Spreadsheets are indeed a great tool, but the implementations we have today are bad, with too many booby traps, not enough safeguards, not even much comfort for those with higher demands.
Yeah a DB where any user can accidentally hit the spacebar and erase a formula, and never see any warning that their outputs are now horribly inaccurate.
Another oft overlooked point is that anti-spreadsheet people aren't actually against using spreadsheets, we just want our coworkers to stop placing mission critical operations in an enormous, half-baked spreadsheet that exists only in some long-since retired users home directory.
As someone who has been to multiple trade shows to show off our own spreadsheet product that solves some of these problems (https://rowzero.io/home), I can tell you there are a bunch of data engineers and their managers who have a visceral hatred of spreadsheets but have trouble articulating any reason for it.
Feels a bit like the no-code paradox though. When you make a sufficiently advanced no-code (or no-database) tool it becomes equivalent to code (or a database) and even though it does entice a novice to start using it, a complex system made in it is still complex code (or a complex database) and ends up requiring a competent programmer (or db admin) to maintain it, who wishes it was written the normal way to begin with.
I have no doubt that the stories of complex spreadsheet models as the beating heart of a business are true. But those models are likely the sole survivor from a thousand dead and gone spreadsheets that people extracted value from for a time, but just didn't have the ongoing utility or wide enough audience to merit being turned into a dashboard or web app. It would be a mistake to insist that all of those spreadsheets should have started life as something else, just in case maintenance should someday become necessary.
In other words, one of the core use cases for a spreadsheet is that it empowers a broad swathe of users (broader than Tableau or PowerBI) to quickly extract insights from their data to fill immediate needs.
Or at least, that's a core use case if you can get your data into a spreadsheet without too much trouble.
And then the attached part of this that you mentioned is that the cursed survivors have essentially outcompeted their peers for survival. They're winners of a genetic algorithm whose basis is company data. They have close contact with actual reality, and have been beaten carefully into shape by it. I have kind of a grudging respect for these because of that, actually.
> It would be a mistake to insist that all of those spreadsheets should have started life as something else, just in case maintenance should someday become necessary.
The problem corporate IT/Dev folks face isn't that an idea started as a low-code tool, but rather that the low-code solution is often dumped on them with no budget or desire to improve it to be more reliable and maintainable.
At least until something fails... and usually in dramatic fashion that then wakes leadership up to the idea that maybe we should invest more into this critical business process. If the company didn't go under in the meantime.
I imagine that's because it's not really a technical problem, but an issue with how the whole organization (mis)handles complexity, and we collectively [1] still struggle to model/name a lot of those problems.
[1] Yeah yeah, I see you there in the back, you excited cyberneticist bubbling with enthusiasm to share... but I mean as a practical widespread matter.
I've always suspected if someone were to make a spreadsheet app that solves most spreadsheet problems it would collapse most companies.
As I see it the limitations of spreadsheets are what keep them from becoming the official way of doing things. At some point most of the stuff in the spreadsheets has data provenance in a properly managed IT system somewhere. If companies could get rid of this part of IT they would suddenly find themselves in a trillion dollar pit of lost money/inventory, As the spreadsheet mess spiraled out of control with no source of truth.
I love spreadsheets for casual stuff, but my concerns with using them for anything heavy duty are twofold: change management and correctness testing.
Other software that I use and write is version controlled and has tests to catch errors, mistakes, typos. Those tests regularly find and prevent problems! Likewise version control.
Could we get the same with spreadsheets? Seems difficult but not conceptually impossible, particularly with LLM assistance.
Imagine if people used Emacs the way they use Spreadsheets. "Hey I made a way to simplify our workflow, it has forms, buttons, gizmos we need" then you go to their desk, and its some custom Elisp abomination. I have to imagine this is how most people who hate spreadsheets see them. It still works, but it's a quirky solution.
Also I remember Row Zero the demo on your home page was impressive. You guys were S3 engineers too, good to know your project took off. :)
One of the surprising things about working inside of $MegaCorp is that if you knock on enough doors, you'll eventually find that each org has, like, one dude* with a spread sheet that powers everything else. Teams will get spun up to try to "automate" this spreadsheet, but, on a long enough time horizon, the spreadsheet wins.
Similar to the author’s cases:
I’ve sat through several presentations of small teams who worked for 6-10 weeks to create a web app that does something (the details vary slightly from case to case) where at the end of the presentation, my first thought is “what a waste of effort and money; that would have taken 2-4 hours if they’d just used a spreadsheet”.
This speaks more to the complexity of web and web development than as a pro of spreadsheets.
You can create a super quick Python app with visualization and whatnot in about the same time as a spreadsheet. But then it's not online. And it's not best practice.
Web is just a fucking beast and then developers go in and add additional complexity.
It would probably be a much simpler web app if you made it just, like, a bunch of PHP scripts thrown in a folder. But they won't do that.
I see these complaints on HN a lot, and maybe it’s anecdotal, but I just don’t see this in the real world these days.
If someone shares a sheet with me, it’s for the intended purpose of sharing data and/or visualizations of that data.
I’ve always been a huge fan of spreadsheets, and the rare times I’ve encountered them being misused, it was a long time ago, and not near enough to make me an “anti-spreadsheet” person.
It sounds like these anti-spreadsheet people need to find a new place to work and/or new coworkers.
Either way people shouldn’t be anti-spreadsheets because some people misuse them. That doesn’t change the fact that they’re a great tool for tracking/sharing/visualizing data.
> I see these complaints on HN a lot, and maybe it’s anecdotal, but I just don’t see this in the real world these days.
It happens all the time where I work. I don't want to be specific, but we have lots of examples here. In some cases people don't like the core software, so they work around it by tracking things on a spreadsheet. And sometimes that spreadsheet disappears (in one case, it was being kept on an XLSX on a USB thumb drive, but the thumb drive got corrupted and we lost some very important data.)
This is anecdotal bias even now. The number of these monster spreadsheets running organizations that should be more sophisticated than they are would most likely keep anyone here up at night.
I was part of a team helping a Fortune 500 company whose inventory system was basically a master spreadsheet that maybe 8 people in the company actually had write access to. Everyone reported numbers up to them and the spreadsheet had read only views for purchase order projections.
To say that it was a nightmare was an understatement. They were willing to dump vast sums of money to get something better, but they'd homebrewed so many human processes to deal with the spreadsheet that they struggled to adapt to a more conventional way of doing things.
This depends a lot on what you do. Try working with a decision analyst sometime. The entire economic model with a decision tree and monte carlo analysis of cost overruns, etc for a multi-trillion dollar decision will literally be a arcanely-complex spreadsheet or two on someone's laptop.
With that said, it's still a great tool for the job because the different stakeholders can inspect it.
>I just don’t see this in the real world these days
Lol. Go to literally any bank. They all have a legion of accountant,analyists that's sole job is to maintain their little fiefdom of spreadsheets that only they understand.
If most people knew just how held together by string,tape and gum the banking industry is there would be a run on the banks.
There is also always some 75+yo part time guy that maintains some sort of critical system. He always says, "I want to retire but they keep throwing more money at me"
You need to give them a tool that's as easy to use as a spreadsheet, and yet stores data in a relational database. There are plenty of spreadsheet-database hybrids in the market.
Using any tool but Excel has the same problem as finding programmers who are willing to use some obscure proprietary programming language. They're going to worry about career lock if they're not developing portable skills.
Even though Excel is proprietary too, it's ubiquitous enough that people don't have to worry about it.
What about a tool that tracks updates to shared Excel spreadsheet and replicate them in a SQL database?
And then, if somebody makes a change in the database, a trigger will update the spreadsheet
Such a two-way binding makes it possible to continue relying on spreadsheets for UX, all the while the data is not locked in there and we can also have other processes handling the data (a web app, some cron job, etc)
I don't use Excel much, but I do the analogous kinds of things with Python and Jupyter notebooks. The problem is that adding some kind of layer requires the involvement of corporate IT, which blows away the advantages of DIY'ing things.
That's true, nothing is as ubiquitous as Excel. But Excel is not designed for multiple people simultaneously updating data. At some point you need a database.
It's not perfect, but Excel can track changes by multiple users. Excel files shared on OneDrive/SharePoint allow multiple people to simultaneously update the data, and it tracks each individual change by each user.
I would say Airtable is. Or if your users are slightly more technical you can try https://visualdb.com/ because it lets you use your own Postgres instance as the backend db.
I feel quite comfortable in Excel - used various tools like Power Pivot, Power Query, OLEDB, created my own functions, Python within Excel, etc. - but Airtable felt so confusing and limiting. Other former colleagues also struggled with Airtable; maybe it was not explained to us correctly.
I’ve used Airtable a bit. I think it’s really cool and would like more people to use it. However, it’s a lot more clicks and key presses to get things done - especially data entry - than in Excel. This also makes it better, since you can put constraints on tables, for instance.
You are absolutely right about needing more clicks and key strokes in Airtable. You have to reach the pain threshold in order to look for alternatives to Excel. And how soon you reach the pain threshold depends on how big your data is and how many users are trying to modify the same data at the same time.
NocoDB is also a self-hosted option. I used it to power a family project that required regular API access, but without the rate limits of Google Sheets.
As opposed to placing the mission critical operations in some huge enterprise Java deployment which has been touched by thousands of contractors, all of whom have only a very rudimentary understanding of the actual business logic.
I think even a complicated spreadsheet that can be directly edited and modified by the actual business stakeholders is preferred.
The main problem is that a complex spreadsheet is just code. Its a bundle of logic and data. That's code.
If the business stakeholders can edit said spreadsheet, they can code. Not well probably, but they can.
So, theoretically, they should be able to open a python script or whatever and hack away. A lot of calculations are actually much easier and straightforward in a real language as opposed to Excel.
But they won't, partially because developers would never let them.
Poe's law.
If you use a spreadsheet as a DB for any sort of application, you should be tarred and feathered, and never infect any engineering team ever.
Your 'trifles' are the biggest screw-ups from functionality to INFOSEC.
MS Excel is much much much much more accessible to the normal office worker than MS Access. It's not even close. As a kid, most of us intuitively picked up Excel but Access was a mystery even with a teacher in computer class trying to teach us the basics. Later I learned SQL to create websites, and graduated with a good CS degree, but the learning curve is uncomparable.
Reminds me of "Ask HN: Is the world run by badly updated Excel sheets?" [0]
You need experience to see the shorcomings of spreadsheets. No version control. No tests. In general it's good for things that don't need to evolve, but stay the same (most likely because they're short lived).
[EDIT] An example of a comment from that thread pointing in this direction:
> In general, you adapt to the excel owner's quirks, not vice versa. If you don't like it you should create an excel sheet of your own and copy/paste, which people also do.
> I knew a project manager who's job seemed to be reconciling multiple versions of a spreadsheet with different authors.
Well yes, starting as a coder in the 2000s in the US, I always thought of my job as turning tortured spreadsheets sitting on a Windows network drive that have to be constantly babied by an underappreciated office staffer into web apps. But I do recognize that a lot of businesses have been run on spreadsheets and run well. There’s a scaling problem and when it hits, ideally you know and can move to an app, but perfect is the enemy of done.
You can use version control with Excel spreadsheets, though it's not very good. It's called "track changes" and even has a limited capacity to approve/reject changes from other people.
Very few people uses that feature, especially not the people who have built a Rube Goldberg machine to run their business processes, but you could do it if you wanted to.
That's not the only version control through - if you use Excel connected to Onedrive or Sharepoint (like most major orgs in my country), then you have version history built-in tracking every edit going back months.
The people who have "built a Rube Goldberg machine to run their business processes" should have used a database not a spreadsheet. Though they likely don't have enough training in database design and so if they had their result would be worse - but that is the fault of their lack of training. To be fair, database training is not something they should have in their position
It’s tricky because a lot of these spreadsheet “apps” are made when the business is young. Specifically non-tech companies who don’t have IT departments let alone any developers. They hire an MSP, get office, and go to town in Excel.
By the time they do get big enough to hire internal IT, the Rube Goldberg system is entrenched. Then by the time they get big enough again to need an internal dev team because off the shelf SaaS no longer cuts it, it’s too late. It’d take too many dev resources too much time and money to fix the spreadsheets, design databases, and start popping out web apps.
Plus the software development process is too rigid for how fast business requirements can change. The accounting department will just do it in Excel in an afternoon instead of being willing to wait 2+ weeks for the next sprint.
So we end up at a place in big enterprises where only some things get successfully moved to something more robust but there just isn’t enough resources (or will to allocate those resources) to tackle every spreadsheet, and so there are always key parts of the business that will forever run on Excel.
You can't track who changed what rows that way. Excel has native support for that.
If all you want is to see previous versions, just make the files read-only after saving them and increment a number in the file name every time you change something.
I've mostly seen the problem manifest when information is spread across a multitude of spreadsheets all stored in different places. The people involved don't know which spreadsheets contain what information and which are supposed to. Sometimes they end up having conflicting data purely because they don't realise that someone else thinks the primary source is spreadsheet A while they're only making changes to spreadsheet B.
Any flaws with Excel haven't been due to the actual program or data, but just how the files are managed within projects. Labyrinthian sharepoints, files being forgotten about on network storage, etc.
> To cut things short, always use the easiest solution to solve a particular problem and once that solution does not work for the business anymore reassess what the new requirements are and either try enhance the current solution or find an alternative that better solve the problem.
When solving a problem, solve the problem you have, not the problem you think you might have in the future, or the problem you wish you had. Your solution will prove inadequate in the future, but you are unlikely to correctly predict in what way your solution will be inadequate.
> you are unlikely to correctly predict in what way your solution will be inadequate
but you can choose a current solution that does not block nor inhibit a future solution. As they say, always keep your options open, and don't vendor lock-in yourself into a corner.
> Your solution will prove inadequate in the future, but you are unlikely to correctly predict in what way your solution will be inadequate.
One inadequacy could be complete dependency on a vendor who accidentally locks you out of all your services or starts scalping you with ever higher fees. That one is quite predictable here.
But: if it is not more work, you can solve your problem by solving a family of problems around your problem in the problem space, making the solution robust, as small changes in the problem definition can easily be catached by small changes in your solution.
That should, with no extra work, solve future problems.
Xoogler here. For my five years we only used Sheets (called Trix internally) for everything from project management, CRM, quarterly planning, reporting, interviewing, finances and so on.
This was not because it was a Google product (we used plenty of competitors' products) but because it is so easy to make them good enough for the task that you can move on to getting the job done instead of administrating getting the job done.
I can say that even now lots of machine learning datasets are kept as rows in gSheets and processed by Python running in Colab. In our team, all our evaluations: read input data from gSheet, run model inference, store outputs in gSheet for manual review if needed, process outputs to compute metrics and plot graphs in Colab. It is great because evaluation logic frequently changes, and without Colab you would sit and wait days each time for code reviews and stupid readability approvals.
And then, of course, if you want reproducibility, you just check in Colab notebooks into the source control.
Chat supports rooms with chat threads without autodisappear. Everyone is in various rooms for their local team, broader team, org, and cross functional stuff. The net effect is Slack-like.
There's also the ticket system. Sheets are commonly used by various PMs and TPMs for high level tracking, but IC eng stick with the tickets.
Right or wrong, it takes a certain amount of chutzpah to put forth such a definite opinion after less than a year in the workforce.
What OP probably misses is the "there ain't nothing so permanent as a temporary solution" thing. I too embrace quick and dirty solutions but only if I have total control over the lifetime of that solution. If someone's going to ask me to deliver it immediately and then build a castle on top of it... I might insist on using a tool that has more up front cost.
Not saying the author isn't onto something: using the simplest tool that will get your job done -- and bonus points if you can reasonably use the same tool for several things -- is a decent principle to live by. Using an existing tool is great, when it meets your needs without too many difficult trade offs.
And where they work, it seems like business requirements are scrapped and rewritten every couple months, so the whole "temporary-haha-yeah-right solution" problem doesn't really rear its head.
The rest of us have to deal with the difficult mess several years down the line, because "we'll throw it away and write a new thing once we need to scale" is something that very rarely actually happens.
Of course, the author has no experience of a year down the line, let alone several years down the line.
'zactly :D I don't want to be too harsh though; I definitely think the attitude of rolling out something simple that works is a solid approach when compared with the gold-plated second-system-syndrome thinking that's terribly easy to fall into. They're not wrong wrong, but there's a bit more nuance to be had once you've seen the monsters that can grown out of a hasty prototype.
I work for an American mega corporation that you’ve definitely heard of - my department relies heavily on a couple of spread sheets. They have survived 3 times of corporate buy out of my factory.
The spreadsheets looked dated when I started working here, 7 years ago.
2 years ago, my latest manager tried to move the department off these spread sheets to the corporation wide system. Another corporate wide system is set to replace the system we still aren’t using by the end of 2026.
I suspect we’ll still rely on our spread sheets in 2027.
I use Google Sheets for all my finances, it's great.
I have an Expense Tracker UI within Google Sheets that allows me to submit expenses to the main sheet (currently just over 5000 rows of expenses over the last few years)
I only just recently vibe coded a web UI tool that uses a Google Service Account to add expenses to this Google Sheet for me, and then created a Progressive Web App from that so I could do everything on my phone.
In summary, Google Sheets is sometimes all you need instead of a database for very simple applications (and built for an audience of one)
I've done the same for a long time. I've tried so many purpose-built alternatives, and always come back to my solution. (Funny enough, Microsoft Money from 20+ years ago is closer to what I'd like than anything available today)
Not to say there aren't features I wish I could easily have. I could of course build it, and I've "started" so many times, but after a few hours of the typical boilerplate code you have to deal with, I'd always give up and go back to my surefire solution.
(This was before vibe coding, so I may take a stab at that)
And it all started with Visicalc. The spreadsheet and the word processor are the most important computer programs ever created. No wonder Google and Microsoft still make billions from these two.
Yep they were the original "killer apps" and still are. They are the reason that PCs gained traction in businesses in the 1980s. I helped my chemistry teacher in High School back then to use Visicalc on a TRS-80 as a gradebook. Almost anyone who has used a computer for work has used a spreadsheet for something, whether managing simple lists, or something much more complicated.
One thing I would add is, sometimes when you need some extra complexity that's too difficult to express or build in Google Sheets, one step above it is Google Colab (or any other Jupyter notebook).
Before building a full blown app, I always ask myself: 1. can this just be a spreadsheet? If not, 2. can this just be a Jupyter notebook?
And yes, the integration between Sheets and Colab is great.
IMO Jupyter notebook is a big step up in complexity from just writing a python script. You can put block comments in python script just fine. "let me spin up a local web server to view my comments and run my code in serial in an object oriented fashion" no thanks from me.
how do you upgrade some existing "thing" from a google sheet to a colab notebook?
I know of the gspread package for python... but I can't see how that gives you anything but the raw data from the sheet. any graphs and interaction (!) and such you would have to redo in jupyter.
For those who hated the unmaintainable mega spreadsheet of death, MS Access was actually a quite decent solution. It allowed you to sprinkle some structure and maintainability onto a spreadsheet without losing the accessibility and ease of development.
You could whip up really functional UIs without much coding knowledge. 20 years later and I still don't know what the replacement for Access is in today's world...
Amen. IMHO the equivalent nowadays would be AirTable - big fan of this, especially now they’ve added Interfaces which is the equivalent of the MS Access UI layer.
"Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."
- Donald Knuth
Start with a gsheet, when it breaks build something else.
True story - I know a guy who built an application using Excel for tracking toll charges for car rentals back in the early 2000's. Over time he built out a team and an application. Piece by piece he automated things, but he initially did everything by hand, tracked it in Excel and printed it in PDFs out to his customers for reconciliation.
He sold the business for $400M. No outside capital, he was the only owner.
Anecdotal, my previous employer had a contract once for a gas storage / exchange, for years their whole business relied on an Excel sheet (basically tracking gas storage transactions from various customers). I don't remember why but they decided to migrate that to a proper application, I think it took a full development team two years to build in all.
But it's likely that, as these things go, they added much more features and visualizations on top instead of just a like-for-like replacement.
TL;DR that company was bootstrapped successfully on just a spreadsheet.
> Start with a gsheet, when it breaks build something else.
Absolutely don't. The one who built the spreadsheet will have changed companies and the "business logic" and the knowledge will be gone with them. You're now stuck with a blackbox that no ones knows the specs of but everybody depends on.
If the sky doesn't fall the sky doesn't fall. Buddy of mine in sales is using some old DOS software from the 90s to control inventory and quotes. I bet there are absolutely zero people who know how it works in that company today. But, it works.
Turns out when you make relatively simple software, it doesn't really need maintenance. How often do you need to maintain a function like f(x)= mx + b? If it works it works.
It is kind of interesting seeing the fear developers have over "everything in finance is on excel." It kind of reeks of armchairism where one assumes the worst immediately and assumes this assumption has somehow not been realized by the domain experts in this space who are in fact also smart spend all their time on the thing.
To an accountant, excel spreadsheet is a source of truth. There is no undetermined behavior. They can look at the calculations underlying the spreadsheet and understand what is happening, no different than a developer looking at source code. They do in fact have their own forms of unit tests considering these data are audited in a far more rigorous fashion than most any code that ships with unit tests.
A spreadsheet doesn't scale, is easily lost or corrupted or stolen, doesn't have security and people that tend to use it don't add data validation and don't care about atomic properties or data consistency.
These are different reasons than given previously. Regardless, Google Sheets are automatically versioned and have extensive access controls, both at the document level, and cell level. Further still, these types of documents are not black boxes, since anyone with access can inspect the data themselves. Arguments regarding scale and atomic operations/properties/consistency are fine, though I do not believe all business logic is necessarily beholden to these qualities.
Let's qualify spreadsheets as software: critical software should not be made by a non-technical person that doesn't know software engineering principles.
I guess Google Sheets invalidates some of my arguments, but Excel certainly does not. And, even if the feature is there, I've never seen them applied.
Google Sheets was phenomenal for prototyping apps and getting quick feedback from users back when I used it in 2015-2020. Back then they had this janky implementation of Mozilla Rhino underpinning their "Apps Script" engine and it still beat the pants off of anything else you could use for free.
Certainly you can shoot your feet with the various spreadsheet-isms but if you're diligent about keeping raw data pure (preferably in a completely different sheet inaccessible to users) it does a bangup job of quickly shoving a UI in front of users and letting them realize what they want and iterate on it before calcifying it into a more rigid system.
Exactly this. Worked for a startup that had dogmatic leaders on 'using the best tool' 'spreadsheets are bad' (a trope they just got from people, not having used it themselves). Ended up spending thousands on consultants to build reporting etc that ended up needing to be changed after 6 months because of business/personnel changes.
Spreadsheets are the best tool to quickly spin up and make changes to data.
I've always thought about a tool to make a 'front-end' version of spreadsheets that end users use, where the layout can be a bit more freeform (i.e. build reports and dashboards in spreadsheet, then 'select' these reports and paste them into a front end WYSIWYG tool).
One thing I've learned: Never (ever) make yourself reliant/dependent on Google products. If you do get banned / locked out, it is the most AI-Kafkaesque process imaginable to regain access. And you could stay locked out for years.
I use Google sheets myself from time to time, but I regularly do backups of the sheets I'm working on, or anything important I have access to. I've been in the hole before, for reasons I still do not understand, and it was one of the most frustrating "customer support" processes I've ever experienced, and it took years.
I keep telling people to make backups of "cloud" services ever since Grooveshark died from one day to the next
Maybe Spotify won't be taken down overnight, but they can lock me out for various reasons such as misdetecting an IP address (Google wouldn't let me log in at all when they thought I was in Russia, when I was at 31C3 in Hamburg, Germany, a conference where they afaik use some temporary IP space — I don't know what consequences that would have nowadays)
Hacker News also: if there are things here you want to keep, store them yourself
Facebook chats, Signal, etc.: download the data in a format you can decode if there's anything you want to keep. Make sure you can decode this Signal backup format if your phone dies
> I keep telling people to make backups of "cloud" services
The usual rule when making backups is that you need 3 copies, one of them offsite. A cloud storage service counts as an offsite copy, but you still need two more, typically one on your computer and one in cold storage (ex: external hard drive).
Treat cloud storage like you treat your hard drive, it can fail at any time. The failure modes are different: mechanical failure vs losing access to your account, but the end result is the same: the system is unreliable and you have to engineer around it.
I think applying these traditional schemes to SaaS environments (now called cloud) can be misleading
When people want off-site backups, the server owner can say they've already taken care of that. I'd say that having a copy under your own control is a separate checkbox we should include!
Good advice. Though I’d say you can count the cloud storage as 2 copies. They typically replicate the data to three drives, that covers all the typical failure modes you’d normally get when running a drive yourself. Then with a simple click you can even get a replica in another region.
The third backup being in a decoupled system on site is what you now count as your ”offsite” backup. Having this last copy is non-negotiable, no matter how many 9s S3 claim to have.
How do I get it out of their cloud? It works as a backup to my phone, but I'd still want another copy that I can access regardless of whether I've got access to that phone number right now. Sorting that out with the carrier can take a while
What's (to me) much more exciting to me is the incremental local backups they're working on. I've iirc looked into how to decode these big backup files, and copy them off my phone semi-regularly, but this being rsyncable will make the process much faster
I assume the process is basically to restore from cloud on device and then export a local backup. But I don't recall them saying anything specific about that. The incremental backups do sound really nice.
That sounds like it'll require access to the phone number to set it up on a new device, and that's assuming the user promptly has the funds for a new device
Even if it works for desktop clients also, that still needs to be set up using a data matrix scanned by the mobile device (or if that's already done before you lost the origin device, you can "simply" extract the faux-encrypted sqlite format that the desktop client uses, albeit with having to recompile this encryption extension for Sqlite manually — ask me how I know..)
> even with Grooveshark being down it still works!
Wait what, how does (did?) that work?
And more importantly (I can find the opus files myself): can/could it retrieve my account data to know which songs to download?
I've been able to partially reconstruct my music from localStorage, downloaded songs on my phone (yay for having root and access to that data folder), and memory, but it's still incomplete
Fwiw, here's my own little contribution to getting song data from Grooveshark, in my first blog post: https://lgms.nl/blog-1 (not my first blog site though). Happy to meet other fans :D
This probably doesn't qualify as a non-tech type answer, but I have a Synology NAS which includes a feature (CloudSync?) to automatically download Google Drive documents in docx, xlsx, etc. format.
There's sadly no silver bullet, especially for non-techies. To me it's like buying vegan products where available: I can't trivially become vegan with no effort, but I can affect market forces by preferentially buying things that align with that ideal. People could at least apply this where possible and buy products where they're in control somehow
For storage platforms like Dropbox or Onedrive, it can be as simple as ctrl+c'ing the data out of there every now and then
For Spotify, you can do the GDPR export and check that you can open it somehow. Even if it's not super readable, you can figure that out (with a tech friend or LLM perhaps) if you turn out to ever need it
For Signal, I've got no idea. The format is hard to work with for hardcore techies. They really really don't want you, ahem, attackers to get that data in the clear. (Two-sided coin). Make sure to turn on the backups, write down the passphrase, and take them off your phone every now and then, and hope there's a restore method when you need it
Perhaps there's a market for this. An automated or semi-automated backup of many cloud services. It could probably be as simple as doing a gdpr request in some cases.
That's not necessarily simple though, because some companies are shady and ass about it. And then if you want to pursue the matter, be ready to face significant effort needed to file a proper complaint in the correct channels for that.
Fwiw, GDPR has a forgotten clause that data exports need to also be provided in machine-readable format for easy service migrations and promoting competition / reducing vendor lock-in
The only reason I can imagine why nobody implements this, is that they like the status quo where it's hard to switch to their service, but equally hard to switch away. Once this becomes commonplace (e.g. because vendor A makes users aware it's a thing by implementing it for migrating from vendor B), vendor B will "retaliate" and A will have to truly be better than vendor B to retain said users
That is all to say, this might yet totally be a viable and legally unblockable business avenue for a third party to initiate. I'm just not sure there's enough demand to warrant (read: pay for) the effort involved. Maybe if you can have an LLM read the api docs of the service where you want to do the import and autogenerate a mostly-working version?
It is, but I think most people would care to at least have the song list, even if they'd need to go out and buy the corresponding data if they stop using the streaming service, or manually enter it into another streaming service
I can't tell whether I'm being super paranoid but I've been burned by Google so many times on product sunsets that I've just removed all of my data from them.
I managed to set up private self-hosted versions of an email client, photo viewing app, and barebones alternative to Docs and Sheets. Switched from Google to Kagi, and Chrome to Brave, but generally keep my own bookmarks of sites to use rather than using search engines.
I still run a skeleton Pixel, but the storage is almost exclusively just a very limited range of apps I use. I managed to get Google One storage from about 700GB to about 700Mb over the course of the last month or so.
Sounds like you're not using something like Nextcloud (which should cover all your bases it seems). Any particular reason, any experiences you want to share?
I just sort of wanted to learn how to build (rudimentary) versions of the same apps I've always used made by other companies/people, and like the idea of the data being as clean as possible. I'm a bit of a data purist, so I store all of my photos unedited, and keep all of my text documents as simple as possible (minimal formatting, data-heavy).
I'm also wary of just moving from one product to another, with the hassle of transferring things over constantly, security breaches, product sunsetting and all of those sorts of things.
I'm on a similar page. I try to set things up so that as many things as possible are regular files in my folder structure, which I then sync across devices. In my experience those are the only files I can rely on being able to retrieve long-term. Eg I don't use a photo app at all, I just have a folder with sub-folders (where I copy them manually). I don't know (yet) how Nextcloud fits with that, but it has several features that look really interesting in general (eg video calls).
Sheets is the one thing I haven't found a good self-hosted alternative to.
I tried Nextcloud a couple of years ago but found it really buggy and slow. Even the basic notes editor on Android was absolutely terrible. Absolutely no comparison to what I'm using now, Obsidian with Syncthing.
Can anyone recommend a good sheets alternative other than Nextcloud?
I'm working on De-Googling. I now have a Mac and an iPhone instead of Windows/Android, but switching from Drive to iCloud seems a fairly parallel move.
I also set up my first home server with RAID NAS. It's on my list to spin up an OpenOffice container or something I can use to replace Google Sheets. That will let me delete my Drive data; next is Google Photos and eventually Gmail.
It took about a week for me to completely de-Google from scratch.
Drive was easy enough to download everything off, but the real pain in the arse was Google Photos. I had something like 250 individual 2GB zip files and the supplementary metadata was separated off of the image files themselves. I had to put together some Python scripts to clean up all the different file naming formats over the years (PIXL_YYYYMMDD, IMG_YYYYMMDD) into just YYYYMMDDD, and reattach the metadata, and then check through that everything was safely downloaded before deleting the Google Photos.
Google Photos had some weird caching issues where it kept showing images I'd deleted and emptied from the bin, which was a little concerning. They were only appearing on my phone and persisted multiple times after clearing the cache. I couldn't find them anywhere in the phones internal storage.
That was Google Takeout! Although in retrospect I did find larger ZIP size options after doing the original export. But it filled Google Drive with 700GB of folders, so I just stuck with downloading the 2GB ones.
Is your home server LAN only or have you configured it in some way to be accessible and secure on the internet? I'm interested in setting up a fileserver myself but I'm not sure what the latest is on security.
I definitely don't open a bunch of ports to the internet! I use Wireguard to VPN back into my home network from my mobile devices. Wireguard only responds to packets that contain a valid preconfigured crypto key, so while the WG port is technically "open" it doesn't respond to a port scanner.
Tailscale is a great place to start. It uses a VPN to access your servers while outside of your LAN while avoiding the security risk of them being wide open to the internet.
So the way I understand Tailscale is that it's built on top of Wireguard; Tailscale claims it's "easier to use" but I haven't found Wireguard to be difficult to configure at all. Are there any extra benefits to using Tailscale that I'm overlooking?
Yes, Tailscale uses Wireguard. If you can use Wireguard, that is great. That is not an option for many people who are behind a CGNAT and/or do not have the ability to setup port forwarding. Tailscale also makes it easier for sharing access with other users.
Through my kDrive subscription, I get access to their own instance of OnlyOffice
It looks a bit dated like MS Office, but it does the job and since it used MS Office formats, I can edit the documents with Libre Office or other sofwares.
And using the API, I can programatically access those files.
I just developed a webapp for it. I only used Docs for personal reasons, so my own version is basically just a really stripped down rich text editor. A lot of things I just save to .txt files.
It saves (both locally and to self-hosting) to JSON and, exports to PDF and HTML. And then I wrote a script to convert docx files over when I migrated from Google.
I assume you're talking about the free consumer tier?
Nothing like that should happen if you're paying for even an individual Workspace plan. You get a phone number for customer support, and it works.
Google shuts down free accounts when it believes they're being used for fraud/spam. And because scammers and spammers create them at virtually zero cost, and will fake activity to build account credibility until using them for nefarious purposes, that does mean legitimate free accounts occasionally get caught.
Regular backups are important no matter what though. Obviously Takeout exists, but there are lots of third-party automated backup solutions as well that will automatically convert Sheets files to .xlsx as part of the backup process. I use one that backs up nightly to my NAS.
> Nothing like that should happen if you're paying for even an individual Workspace plan. You get a phone number for customer support, and it works.
Last I was a workspace Admin, you had to login to get the phone number and the code to dial once you called.
It certainly did get you to a human. Unfortunately, they were not empowered to actually help with any of the things I needed help with, even when it would just be filing a enhancement request with the product team (they just tell you to post in the unmonitored product forum)
I've seen several believable tales of Kafkaesque billing issues leading to Workspace accounts being suspended. It took months to get them to do invoice billing.
>You get a phone number for customer support, and it works.
I don't believe this after decades of past experience with them trying to find any human to contact. Have you seen the phone number yourself? Normally they just give you the runaround trying to navigate a maze of support pages.
The worst customer support experiences of my life have been from Google, both while using Google Fi personally and GCP while working at Replit in its early days. Thankfully I'm no longer using either of those products now.
Plenty of reports of people getting locked out of their Workspace accounts. Google even occasionally burns developers they have deals and working relationships with.
Just don't use any Google services. Not free, not paid (why would you send them money???!?!). Not for personal stuff, not for work projects. Not for throwaway data, not for important data.
That's a feature of any SaaS. Adobe frequently shuts down ETLA customers due their own invoice processing failures. I can think of three significant government subdivisions that were unable to access any M365 service for 1-10 days as a result of a reseller change.
The real lesson here is that you need to understand the failure domains of the technology your business depends on. Your business is as good as the contracts you rely on. We're relatively good at preparing for IT failure, but not so much the other stuff. For small businesses, key revenue generation could be stopped by an employee doing something dumb with a corporate card.
The real lesson here is that almost all modern SaaS applications have massively under invested in customer support in order to appear more profitable or sustainable than they really are. One of the major factors behind LLM development is trying to solve this problem before the house of cards falls down. Companies were enticed by the recurring revenue of SaaS, but don't want to pay for the level of support required when you are responsible for all your customers data as well as their access to the service.
> Plenty of reports of people getting locked out of their Workspace accounts
None substantiating the "most AI-kafkaesque process imaginable to regain access" upthread though. I mean, I don't know what you're citing specifically, but yes, obviously: business relationships like everything else get tangled up sometimes. People's electricity gets shut off incorrectly, people's Doordash orders arrive with the wrong stuff, phone bills arrive without the promised discounts; everything sucks, kinda.
But if you're paying the solution is to call your support contact and have them sort it out. And that works at Google the same way it does everywhere else.
You're right about google's track record but at heart yours is a comment about third-party cloud dependency, not google. As you mention, offline storage solves this and another commenter mentioned msft will ban you also (but you dont hear about it because...offline storage)
Track record is a factor that you should consider.
When companies buy services from others they often ensure that the contract has protection from things like this. They have clauses that the data belongs to them. They have clauses about what happens if the company is sold. They have clauses about abandoning the product. They have a number of other things added that I'm not aware of.
You as a single individual (and often as a small business) don't have the power to get that into a contract. However you still should read the fine print - you should go elsewhere if it the fine print is against you.
We bought a Google Workspace subscription for a building I help manage and I was shocked when I found out that you can't archive emails for discovery/legal purposes unless you buy a more expensive subscription that has access to the "vault."
I've never heard a rant about people being banned, but i can think of a half dozen people who have lost their icloud accounts due to the combo of inexplicably not remembering or writing down their passwords and selling or losing a phone.
That's the opposite than ban by Apple. And also for this people can go to an apple store or call support right? unless they enable the most nuclear e2e option.
My dad got a Trojan and they took over his msft account to buy some Xbox cards. They banned him as well but he took them to small claims in the EU. As usual they didn't show up and he got a ruling to reinstate his account. Was under 100 bucks and he got his account back. If the account is really important I would do the same. There is a 90% chance they won't show.
just as a point of interest, in US small claims courts, the judge can award monetary damages, but cannot order somebody to do something (like turn your account on) i'm not sure if this varies by state.
This comment prompted me to go look at the various spreadsheet software available, since I was only familiar with the usual Excel / GS / Libre. There is also GNOME's Gnumeric, KDE's Calligra, Apple's Numbers, an online variant of LibreOffice called Collabora, an Excel clone made by a German company called PlanMaker, a Latvian effort called OnlyOffice, and then probably the most unusual variant, but somehow it isn't surprising that somebody made a spreadsheet based on Python:
This is a very interesting read, we are building Cursor for Google Sheets and the variance of use-cases we see is insane.
1. A lot of people are creating dashboards / CRMs - either they don't have any one selling them verticalized Software or its too expensive.
2. Some people have verticalized Software and they use Sheets so that they can share data with others without paying for per seat SaaS while not worrying about what the new members can read/write into
3. Lots of financial modeling and planning - From a chain of Cafe's in Laos, to Startups raising funding.
4. Lots of teachers trying to do scheduling for their school while ensuring that the teachers get enough of a break. We have seen this in Colombia, the US and Italy
5. A lot of market research and enrichment
A Spreadsheet really is the IDE of a billion people. You can try us here https://tabtabtab.ai/
The world is not binary, nor black & white. There is an entire spectrum of solutions between a spreadsheet and a highly-structured app. Sure, you can use a spreadsheet for anything, it's quick, and provides nearly no structure. You can also use a specialized application, tailored for the particular processes at hand, that does error checking on input, validates data integrity, and does not let you break data structures. And there is a whole spectrum in between.
One thing to note is that a spreadsheet (OPs insistence on calling it "Google Sheet" is amusing after years of hearing people call it "excel", it's a spreadsheet, people!) is a poor-man's relational database, with most spreadsheets having a single table, or multiple tables but modeling no relations. And you can't model relations in a spreadsheet in any meaningful way (imposing constraints, checking integrity, etc).
Written from the perspective of someone who makes a living providing a SaaS for (among others) inventory control, for which a spreadsheet is a direct competitor. Also, from the perspective of someone who has seen a lot of customer spreadsheets with inventory, not one of them in any way correct or containing good data.
I’ve mostly used LibreOffice for personal use and other cases where I don’t want to use Big Tech, but you could try OnlyOffice. I’ve also been interested in Grist, which is more like AirTable but programmed in Python and (relevant to your request) self-hostable.
Edit: Depending on your reasons for avoiding big tech, you may want to research the owner of Only Office, which was a Russian company but apparently isn’t anymore? You might want to also try CryptPad, which is based off of OnlyOffice and recommended elsewhere in the comments (which reminded me).
What's cool about CryptPad is all the data is encrypted behind the # tag key which never gets sent to server. So even the server admin don't have access to the user docs. It has being easy to migrate from server to server.
A truly shining example to google doc alternative.
It would be great to have some kind of syncthing <-> cryptpad drive, then it can be very nice alternative to even dropbox. Not sure what the development is ATM.
Baserow is in the same realm of Airtable/Monday.com/SmartSheet/etc, which are all effectively visual DBs. These tools shine with structured data & rich field types. The core assumption that unlocks their power is that every row of data in a given tab has the exact same schema.
While powerful, this assumption also creates rigidity that a pure spreadsheet doesn't have. You can't, for example, do some quick scratchpad analysis off to the side of your data, or quickly subtotal a few rows with an adhoc formula. For that type of flexibility, you need a pure spreadsheet, which is the camp that Row Zero falls in (along with Excel & Sheets).
So, to answer your question - they're solving different problems. Some spreadsheet usage may be better served by a visual (or actual) database, which is why that sector has exploded in the last decade. But not all use-cases fit that criteria - the flexibility of the pure spreadsheet remains an incredibly powerful thing.
One of the biggest problems in business automation is the gaps between such low-effort
“shadow” IT, low code platforms, and fully fledged out “proper” projects. The gap between “let’s make a google form” and “let’s build a react app with proper design, ci/cd, testing, cdn and so on” is too wide. There should be a bunch of intermediate steps there with a sensible migration path, but there are none, there are only walled garden alternatives that aren’t compatible with either.
I've long argued that spreadsheets are essentially a structured programming tool for people that would never imagine they could or would program. And maybe even a gateway drug in a proportion of cases?
The problem is that spreadsheets are an unstructured programming tool. It's like BASIC with all its GOTOs, index-only loops, etc vs C with proper functions and control structures. You can have a structured spreadsheet but it requires discipline that almost no person (and certainly no organization) has.
Huh, this is a really fascinating article! I really like how she articulates common myths in software development. However, it feels like her remarks are more targeted at the academic CS community, because I think a lot of her critiques (such as lack of integration thinking) are already internalized by project leads of modern software systems.
The HN perennial video, "You Suck at Excel" by Joel Spolsky [1] really changed my view on spreadsheets. I had never bothered to learn them enough to utilize naming or any of the features that make spreadsheets much more comprehensible. I was very happy to see Google Sheets added named tables recently, too.
I've recently been experimenting in Apps Script to write my own (physical) book collection record system with a USB barcode scanner. So far I have nothing polished enough to show, but it is a very cool platform. I found it a bit frustrating that I couldn't just import NPM packages, but at the same time it's a good excuse to embrace simplicity and skip a library like Axios, and rely on its built-in fetch()-like API.
1: The original YouTube video has since been taken down, but you can still view it through the Wayback Machine:
- My own rough business accounting (download all bank statements and do some pivots and graphing. Real accountants do the real thing, but I like to have a version that makes sense to me and that is up to date)
- Personal accounting finance tracking for sharing expenses and tracking living costs over time
- Consolidated asset tracking across different projects/accounts etc, just a quick summary that's not perfect but spending 10 minutes a month manually updating it helps keep it in my head too.
- A lot of project management (we also have real PM tools, but I keep my own sheets because it's easy and it makes sense to me)
- A bunch of quick analytics (I also use metabase, but sometimes it's just faster to create a graph in sheets)
Most of the time the sheet is not the _main_ tool I use, but it is the easiest and most useful one, while the others have better integrations, safety mechanisms (I often end up with +500 or whatever in a copy-paste formula error and sometimes don't catch it), and collaborative measures (if you have 2+ people editing the same sheet you're usually going to have a bad time)
I feel this deeply. I only use Google Sheets, too.
It sounds crazy, but it’s the best tool for so many random things, and here’s why I stick with it:
It Just Works: There's zero fuss. I don't need to install anything, I don't need to save it, and I don't need to worry about the format. It's always there, and it saves automatically.
It's Simple to Share: If I need to show something to my spouse, a coworker, or anyone, I just send a link. No one needs to sign up or download some special app. Everyone can open it right away.
It's the Perfect Checklist: For managing my own stuff—like a budget, a travel plan, or even just tracking a personal project—a sheet is faster than any fancy app. I can make columns that say "Done," "To Do," or "Waiting," and that's all I need.
For most of my personal data and quick shared work, trying to use a dedicated software package is just overkill. Sheets is the easiest way to organize information in a clear, digital table. It's the ultimate low-tech solution to high-tech problems.
Sharing is the killer feature. Not that you can't share with Office 360 these days, but many of us were sharing Google Sheets years ago when the rest of the world was still sending Excel files as email attachments, and there hasn't been much reason to switch.
Probably not used by many, but if you need to break out of basic functions, some may find working in Javascript preferable to VBA.
I love excel and use it daily in my bullshit admin job.
But google sheets is so much easier if you have more than one person interacting with the data. It just works, easily, every time. Even with 365 or whatever for MS products, they're more cumbersome.
> Doing the smallest and easiest solution to a problem as a way to get to know the full scope and then iterating after that if needs be is by far the best solution (for me).
100% -- this is YAGNI (or you-aint-gonna-need-it) and should be among the first things you think about when starting a new project.
I suppose the issue here is trusting Google with your personal and business data. Mining that information for targeting advertising aside, it's not unheard of Google locking people out of their accounts with no reasons or obvious recourse.
I wonder what the best non-mega corp solution there is for this.
Why not use an open source spreadsheet in javascript and html that you can host yourself?
You can whip up whatever you want now with an LLM. And with JS it will save whatever you want in indexeddb or pouchdb and export to whatever formats like csv. Why lock into google?
For those who currently find themselves unable to use any spreadsheet because they are all based on algebraic notation, you might find the site below interesting. It's a spreadsheet for you that works with only arithmetic in two dimenstions. Be sure and try the first two short videos. You will never have seen anything like it.
http://www.tmaker.site
I get the appeal — Sheets is insanely flexible and quick to hack together workflows. I’ve seen entire businesses basically run on it. The tradeoff I’ve noticed is that as client work scales, you start spending more time managing the sheet than the actual work. Curious — do you use it mainly for tracking, or are you also handling things like scheduling/invoicing inside Sheets too? I’ve always wondered where the tipping point is between ‘this is efficient’ vs ‘this is duct tape holding everything together’
I’m about to leave Google Sheets because I keep very long spreadsheets about my life and everything I do and it refuses to open at anything but right at the top. So every time I have to scroll and scroll to get to the bottom. Does anyone have a fix for this? Last time I googled all I found was some dingleberry on a Google thread saying that’s how spreadsheets should open. I moved to Google Sheets from Excel online that did that right at least. I moved away from Excel online because it has requirements for small file sizes and the images I would paste in the spreadsheet filled them up to the limit too fast.
Doesn't ctrl-end jump to the bottom row of the spreadsheet? Ctrl-down arrow will jump to the last cell in the current column. On a Mac it's cmd rather than ctrl I believe.
I coach people for powerlifting and create their programs in Google Sheets. I even have functions setup for converting a given weight to their plate breakdowns (for example 455lb squat would be broken down as: bar, 4x45lb plates, 1x25lb plate). My athletes can enter their current one rep maxes and the sheet auto updates the numbers for each training session. They can record notes about how each set went, how many reps they got etc. and then I can review them. It's all super convenient.
I like what the author is writing. For the listed use cases, grist might be the better tool. It would also return control over your data back to you if you self-hist it (which is easy).
That’s what I thought almost thirty years ago: That MS Access is the solution to all problems in an office environment. I‘d model the domain and create a full working app with database backend in days.
And five years later I consulted companies who had business critical solutions built in MS Access that were not scaling anymore (concurrent users, faster database etc)
Applied to this article: Yes, you can use Google Sheets for all sorts of tasks, but eventually you will need to move on to a more robust solution.
I worked on creating a card game with a couple of my friends. We kept all of the cards in a Google Sheet, allowing everyone to easily edit or create new cards. Then, I wrote a script to compile the sheet into a card atlas so that it could be consumed by Tabletop Simulator. It worked amazingly well.
The only issue was that I had to run the script myself, since my friends were less technical. I'd probably see if I could setup a workflow in Github Actions to do it for me if I were to do this again.
Everyone wants something like a local version of Airtable, but the issue is anyone that tries immediately turns it into a cloud product. Nocodb is better, but is still severely restricted & tries to think too much in terms of replicating Excel functions, rather than making it easy to create your own using JS/TS.
I've recently removed the fancytooling out of my pipeline, and re-done Jira on LibreOffice's Calc.
And with native python it has, I can query snapshots from Jira, add inputs etc.
So much simpler, you open Calc's window and just hop faaaast through sheets. Rather than opening your browser, typing URL, entering Jira, getting into correct board etc.
Need a to-do list? There too, just another sheet. Need to track your deployments? Just pull it into yet another sheet.
Only tangentially on-topic, but I do all the financial modeling for the past several (early stage) startups I've worked for in Google Sheets.
The ease, collaboration/sharing, and array formulas win out over the faster speed for calculations, better shortcuts, cross-workbook linking, and customization in Excel.
That said, it's been a few years since I've tried Excel so would love to hear someone convince me to try it again.
I'm using the MS suite for the first time in over a decade...and the collaborative aspects are still nowhere near Google's. I routinely get problems when multiple people are editing the same content (Word doc, spreadsheet, or PowerPoint). And sometimes the thick client works best, sometimes browser editing works fine...but it's inconsistent.
For all of them, Microsoft has a more complete feature set...but for 99% of things (and anything with lots of collaboration), I prefer Google Work Suite or whatever it's called this month.
I used to work in a really big bank. One of our primary responsibility is to "convert" trade algorithm from spreadsheet to an actual production program/code. The usability of spreadsheet to show a concept quickly is great. But it is a nightmare to have to understand and debug during the conversion.
My new discovered superpower for Google sheet is using Gemini, not the integrated functionality, but using Gemini to spit out some very specific use case into app script which I plug into my sheet. Majority of the time the code works without any issue on first try with Gemini Pro.
Funny, I recently departed from the google ecosystem to proton, self hosted nextcloud, kagi, Libreoffice, and Apple Maps. Am I giving up some ease of use? Absolutely! Can I live with it? Absolutely! Can google go fuck itself? Hell yea. Libre office is like missing a limb, but with practice it can do anything I want it to.
Google, Excel, Numbers, LibreOffice, close enough as makes no difference for what the vast majority of people do with spreadsheets. And even for more complex use cases, any of them will most likely be fine. Google probably has the edge if you need real-time sharing with multiple people.
Does Google Sheet allow fine grained filtering like "allow customers to see only their own requests" or "allow submissions to be edited within 1 hour"?
It’s embarrassing. Back when Zillow was trying to be a real estate broker, they had a pipeline for salespeople to track the progress of flipped houses. I was brought in with oh maybe 50 other devs to code the more extensible replacement.
The existing workflow was all down in google sheets, and it scaled to at least 10 states. There were growing pains, sure, but it seems like a monumental waste to spend an hundred years of dev effort replacing an existing working system that cost the price of a Google enterprise installation.
I often wished for a Google Sheets like service that had an easier to use API and a bit more control over the schema. A cross between sheets and a headless CMS.
Reminder that anything you put into Google for storage is you voluntarily disclosing such information to the United States federal government without a warrant requirement.
Due to both the third party doctrine as well as FAA702, the feds do not require warrants to access, copy, process, and store indefinitely all information you provide to Google.
this is what got me excited about NOtion in the early days - they nailed that notion ( he he ) about just providing a nice view for databases, which you can design yourself
and of course Google sheets with its synchronous use model is doing the same
> "I spent 2 months designing and making an admin panel "
Why? It's easy and quick to code complicated things these days. It's nice having custom dashboards and functionality that fits exactly with what you need. Way more professional.
I'm sure Google Sheets are fine. But I've been seen truly ugly Google Sheets with way too many tabs and horizontal scrolling. Clunky cells that seem to expand and have their own scrolling universe with different laws to everything else. Why can't I simply click the cell to copy it all, nope, let's try double-clicking the cell, I just want to grab the contents to the clipboard, nope. Now it expands and I'm scrolling the whole sheet and have lost my place because Google Sheets tries to snap to rows or something. Damn I hate this memory of navigating someone's horrible Google sheet.
This is honestly one of the things I really like about Notion Databases, at the core they are an online collaborative spreadsheet. But then it can also be given multiple views and different forms such as a calendar, Kanban board, timeline, image gallery, etc., wish more apps would allow something like this, e.g. Obsidian Bases are a great first step.
I haven't used Google sheets for maybe 2 years, didn't have the need, but week ago I needed to send customer a table that will be updated every couple of days. I was surprised how slow it is. Table has 40 lines and 8 columns, static text only, and it takes 12s until I can edit it. For what it is (adding sentence every 3 day) it's ok but if I had to actually use it for myself on a daily basis it would drive me mad.
I run my household budgetting off google sheets - a clean load of 8 sheets, wth 20-200 rows and 20-50 columns including some simple cross-sheet formulas is fully loaded and interactive in less than 2 seconds. My work's sharepoint based Excel roadmap doc is 40 rows of 8 columns and takes about 15 seconds from clicking the link to actually being readable, for comparison.
It should be lightning fast for what you're describing.
All I can guess is you have some browser extension interfering? Maybe one that is blocking certain calls Google uses and the sheet doesn't load until they time out?
If you're running an adblocker or blocking trackers or anything like that, try disabling those to see if that makes a difference. Otherwise check the network tab of the dev console to see what seems to be slow.
I manage all the information for every parcel in my city in Google Sheets. It is > 29k rows x dozens of columns and it is instantly interactive when I visit the bookmarked URL.
ya there is no way this isn't some local issue for something that small to take 12 seconds. my last job i force updated sheets with thousands of rows every 5 mins and it would just be like a quick 1 second blink to totally clear and replace all those rows with fresh data.
Always overlooked point in these pro/anti-spreadsheet discussions:
A spreadsheet gives you a DB, a quickly and easily customized UI, and iterative / easy-to-debug data processing all in a package that everyone in the working world already understands. AND with a freedom that allows the creator to do it however they want. AND it's fairly portable.
You can build incredible things in spreadsheets. I remain convinced that it's the most creative and powerful piece of software we have available, especially so for people who can't code.
With that power and freedom comes downsides, sure; and we can debate the merits of it being online, or whether this or that vendor is preferable; but my deep appreciation for spreadsheets remains undiminished by these mere trifles.
It's the best authoring tool we've ever devised.
EDIT TO ADD: the only other thing that seems to 'rhyme' with spreadsheets in the same way is: HyperCard. Flexible workbench that let you stitch together applications, data, UX, etc. RIP HyperCard, may you be never forgotten.
Right? Spreadsheets have such a low barrier of entry. I use Google Sheets in a middle of a farm field to enter plant growing records on my cell phone. I don't even have good reception at times so the sheets are in offline mode; they'll synch when I get back to the house. Crappy, crummy records are oftentimes better than no records. Farming is data-heavy and data-starved at the same. A learning cycle is a year, and one year is not like the other one.
> especially so for people who can't code.
And for those who can, Appscript gives your spreadsheet super powers.
For those who don't know, you are not stuck with writing JS in the Appscript integrated web IDE that comes with Google sheets (though honestly it's not too bad itself).
Using clasp, you can develop your code locally in an IDE of your choice, in typescript and have a build step compile those to js, and have clasp push it to spreadsheet.
Once you have the tool chain set up the DX is quite nice.
I spent some time with Apps Script a few weeks ago. It has some strange design decisions:
1) Everything runs on the server, including triggers and even custom functions! This means every script call requires a roundtrip, every cell using a custom function requires a roundtrip on each change, and it feels much slower than the rest of the UI.
2) You can't put a change trigger on a cell or subset of cells, only on the whole sheet. So you have to manually check which cell the trigger happened on.
3) Reading and writing cell values is so slow (can be a second or more per read or write) that the semi-official guidance is to do all reads in a bunch, then all writes in a bunch. And it's still slow then.
4) A lot of functionality, like adding custom menus, silently doesn't work on mobile. If your client wants to use Sheets on mobile, get ready to use silly workarounds, like using checkboxes as buttons to trigger scripts and hoping the user doesn't delete them.
Overall I got the feeling that Google never tried to "self host" any functionality of core Sheets using Apps Script. If they tried, it'd be much faster and more complete.
> 2) You can't put a change trigger on a cell or subset of cells, only on the whole sheet. So you have to manually check which cell the trigger happened on.
This is true of MS Excel's scripting language (VBA) as well. Worksheets are objects with events; cells are objects without (VBA-accessible) events.
It may be an issue with scaling and efficiency.
But Google Sheets remote procedure calls are vastly slower than local OLE/COM dispatching. (And VBA/Excel presumably uses the optimized tighter COM interface binding instead of the slower high level COM IDispatch. Sure there's some overhead but it's nothing compared to Google Sheet's network overhead.)
Not only is scripting Google Sheets indeterminently and syrupy slow, it also imposes an arbitrary limit on how long your code can run, making a lot of applications not just inefficient but impossible. Running your code in google's cloud doesn't make spreadsheet api calls any faster, it just limits how long you can run, them BAM!
To get anything non-trivial done, you have to use getSheetValues and ranges to read and write big batches of values as 2d arrays.
https://developers.google.com/apps-script/reference/spreadsh...
It's easier to just download the entire spreadsheet csv or layers and bang on that from whatever language you want, instead of trying to use google hosted spreadsheet scripts.
> Everything runs on the server, including triggers
I think that’s a consequence of the fact that multiple users can simultaneously edit a sheet. Yes, Google could special-case the “you are the single user of this sheet” case, but that’s extra work, and, I think, would be fairly complicated when handling edge cases where users frequently start and stop editing a sheet.
> I think that’s a consequence of the fact that multiple users can simultaneously edit a sheet.
No, it's not. Built-in functions like SUM recalculate instantly, and custom formatting rules (e.g. "color green if above zero") get applied instantly, even when there are multiple users editing a sheet. Running custom functions and triggers on the server is just a decision they made.
Sum and custom formatting are idempotent. It doesn’t matter whether that gets run once, twice, or a hundred times.
Arbitrary AppScript isn’t guaranteed to be idempotent. You have to run it only once.
This reason doesn't make much sense to me. Let's say I write a non-idempotent custom function. It makes the spreadsheet behave weirdly: recalculating a cell twice leads to a different effect than recalculating it once. Does it matter whether the function runs on the server or the client? No, the spreadsheet will behave weirdly in either case, even with just one user.
Can we make a programming language that will save developers from that? Maybe, but that would be very hard and that's not what Apps Script is trying to do. It already allows non-idempotence, trusting developers to write idempotent code when they need to. So it could run on the client just fine.
This is exactly the issue. I don't want server-side scripts, what I want with Sheets is the ability to run custom JS from the page itself.
Or use the API to program in anything you want. We use Google Sheets for our accounting system, loading data via bank APIs and a cron-driven python script. We used to use Xero, but it couldn't handle the different tax regimes we operate in.
That looks like a great usecase. Would you be able to write about the architecture. A lot of us would love to be able to do things like this in Sheets, I'm personally trying to integrate a forecast estimate into Sheets
Ah, thank you for that. I want to write an extremely basic transform on my spreadsheet, and Googling failed to turn up how one did that.
I wish there was a better way to make spreadsheets use a database as a backend. Most of what people do with a spreadsheet would be better done in a database - but a database needs a lot more training to use (if you don't have the training you will make something worse than spreadsheet with your database!)
Wasn't Microsoft Access basically that? There's also Google's AppSheet, which may be that too.
>Wasn't Microsoft Access basically that?
No because the datagrid in MS Access is too rigid and doesn't have the extensive slice-&-dice features of MS Excel. My first consulting gig was creating customized MS Access applications. Despite that experience, I use MS Excel today because I know that MS Access is too limiting.
>>Wasn't Microsoft Access basically that?
>No because the datagrid in MS Access is too rigid and doesn't have the extensive slice-&-dice features of MS Excel.
i'm not saying it worked or worked well, but i'm pretty sure the point of Access in the office suite was so that you could access Access (get the clever marketing?) data from within Excel and then do all the excel things you were used to.
anyone know if that worked or didn't? DDE and all those other projects were always pursuing this as a dream
Access's database is fairly limited and prone to corruption, especially using in a (local) network setup. The better solution would be to have real backend database and use ODBC to sync in data to Excel and Access. Maybe back in 1995 it made more sense but that's before my time.
Access was pretty amazing on its own back in its day, ignoring its multi-user limitations. It glued together a relational database, visual query builder, GUI/Form Builder, and reporting. You could create forms with sub forms that linked tables together. Also had a datasheet view. All of this without touching VBA code, but VBA was there when you needed it.
dbase II offered similar capabilities on 8 bit CPM workstation in the early 80s.
I think it worked technically and I‘ve seen a few Access-based solutions to problems faced by people/groups without any real access to development resources. However, these solutions pretty much always came from people with rather technical mindsets and I think many of them involved tinkering in the evening and on weekends. So, my assumption would be that the demise of Access was more about UI/UX, complexity, familiarity and the like than it was about functionality.
It sounds as if Excel has grown to incorporate most database features.
Does it have atomic transactions yet? That's the main thing keeping me using small databases like Access even when a mere spreadsheet would do otherwise.
Have you tried Airtable? It works like a spreadsheet but is a database underneath.
Microsoft Access requires more training (tables, foreign keys...) and from experience most of the people using Excel managed to bend it to do what they wanted.
The maintainability of the resulting systems was not great, but they did the job and worse is better I guess..
Add in to that: programming VBA for Excel spreadsheets is extremely trivial; programming in VBA for Access is second worst only to programming in Visio, MS Office's awful drawing program.
You know, I used Retool a lot, and it made me think that I'd actually really like a modern Microsoft Access.
Kind of an open source Google Forms/ Access where you could deploy front ends very quickly and have it hit a DB
Here's a modern Microsoft Access: https://visualdb.com/
Or try Airtable.
> I wish there was a better way to make spreadsheets use a database as a backend.
Here you go: https://visualdb.com/
Years ago I used Excel (VBA) as a CRUD interface on a database with minimal validation, it didn't take too long.
Pretty sure something fairly similar is built-in these days.
Hard agree here. The value of combining database + UX + logic into a workbench is like the app we've been reinventing over and over again. It's why Visual Basic still lives :-).
And yes, not the greatest way to proceed once you know what you want, but a heck of a way to iterate quickly and identify the actual requirements.
>>It's the best authoring tool we've ever devised.
100% agreed. Creating a spreadsheet is declarative programming, and Excel (and now Google Sheets) has made more developers than any other platform (probably by an order or two of magnitude).
I do not know a business that was not CRITICALLY dependent on Excel for actual business operations through the 90s and 00s...and the same is likely true today.
The Google suite of Apps was born multiuser. They perform better then Microsoft's apps when multiple people, even dozens of them, are bashing on a single shared document. Document sharing is more powerful than sharing a window or a desktop. It changes the way people work together.
I would not have agreed readily with that statement until three years ago, when I actually started working in GS as part of my job. I couldn't have imagined how seemless and well-implemented collaborative editing had become IRL.
yes, that's true. It also brings the issues related to that - it's easy to delete the whole org data, change things uncontrollably, corrupt the data, there entries in the tables are free-form (well, you have to do programming to make it more robust).
it works fine initially, but for long term it's usually more productive to have custom software.
> it's usually more productive to have custom software.
If you multiplied the custom software development effort and cost to the multitude of places and use cases people in an organization are using spreadsheets I think you’d quickly find that it’s infeasible. And that’s not even taking into account how much value the adhoc-ability of spreadsheets adds to the equation. Most spreadsheets can be completely refactored or thrown away in a rather trivial manner. The sprint nature of software development screens out most things that could be spreadsheets. I’ll build it in an hour instead of waiting 2 weeks to get on the next sprint.
The software development process is too rigid for rapidly changing business needs. Having to spec out requirements and such is often an unknown and something you’re doing live in the moment when creating the spreadsheet itself.
Google Workspace apps all (?) have versioning.
I've long wondered why there's not a more incremental transition path from spreadsheets to a full blown database with a custom UI. It just seems like spreadsheets are right on the cusp of being able to fill that that role but lack just a few key features which might make it viable (structured data, native SQL query support, custom UI elements, IDE integration, etc).
> incremental transition path from spreadsheets to a full blown database
There are plenty of tools for that. Airtable comes to mind, or if you want to use your own database try: https://visualdb.com/
At my old gig, all of our content generation was in Google sheets or Airtable.
Anything we made would have _never_ been as good a UI and would have stopped us from being able to publish new content. The other nice thing about them is you can scale the integration effort. You can download a sheet from GS as a CSV then upload that in an admin page and you can probably ship that feature today. A tiny bit more effort and you can add a 3rd dimension to the data by finding an XSLX library and exporting the page as an Excel workbook. Eventually you can do something with their API where you just click "reload data from the master sheet" and you can generate all the data you need to preview the changes on the frontend. That's what our Airtable integration looked like. Airtable was very "pull this in via API" native and had a better way of expressing higher dimensional data in cells which matched nicely with Postgres storing arrays in cells.
Btw, anyone ever used Mathesar ? I saw it on the hn frontpage but I haven't tried it yet
I didn't realize it at the time, but I my first encounter with the "solves every problem with a spreadsheet" user type came very early in my career.
I worked in a computer lab in college, ca. 1989. One of my colleagues was in the mechanical engineering program, and had a bias generally for "solve the problem" over "elegant solution" or "appropriate tool" concerns. (I love the guy to this day, to be clear.)
When he first came to work at the lab, he was the only guy to have installed FORTRAN on his workstation. It didn't work well.
Then he discovered Lotus 1-2-3 and its macro language. He DELIGHTED in making the rest of horrified by creating all sorts of boundary-pushing utilities in Lotus macros. To be clear, he was at least 50% "doing a bit", and leaning into the "engineer only knows one tool" gag we'd all been riffing on. But he was still doing absurd stuff in Lotus that would've been better built in, say, Turbo Pascal or Turbo C.
I had no idea back then that this pattern would become so prevalent.
I worked at a law firm where the chief accountant (not the accounting manager, but the guy who made most of it work) did everything in Excel...including writing memos and other documents. I think the only other program he used was Outlook, and he probably drafted email in Excel.
It is far easier to work your way into programming via spreadsheets than via sql.
One day you are writing ‘sum(a2:a201)’ the next you do some conditional formatting and so the complexity builds up very slowly with your needs.
With sql, day one:
‘SELECT SUM(Column) AS Total FROM Table;‘
Way more complicated. Way more powerful too, but most people don’t need the power until much later.
And you have to work in the console which is an unfamiliar ui for many.
It’s not impossible, but very high overhead in comparison.
That's not true, you can use Airtable to get the ease of use of a spreadsheet with the robustness of a database.
And now you have two problems. It’s not just SQL that you have to learn, but airtable. Which probably isn’t installed anywhere.
Not true. You can't use SQL in Airtable even if you want to, it just doesn't support it. Also, Airtable is SaaS, you can't install it.
s/install/somehow obtain access/
Doesn’t really change the point.
As of this writing, there are twenty-two comments on this thread about airtable. All but four are either you or responding to you bringing it up.
I think it’s fair to say that whatever its advantages may be, it is relatively unknown, and therefore a higher-overhead entree into programming than straight up spreadsheets.
Just learning about it or finding fit for purpose takes more time than diving into a spreadsheet. And as always the argument is not that spreadsheets are more powerful or better, but that they are much easier and more incremental to learn and start with.
You are absolutely right and it makes sense to start with a spreadsheet. As I said elsewhere, you have to reach a pain threshold in order to look for alternatives to Excel. And how soon you reach the pain threshold depends on how big your data is and how many users are trying to modify the same data at the same time.
Google Sheets has the =QUERY() function which does some very limited SQL.
Spreadsheet formulas have a very simple grammar: expression = reference | exp1 op exp2 | function(exp1, ..., expN)
That's it. It's the math notation from high school, plus cell references, which can be inserted by clicking a cell.
SQL and to an extent R were both created under the assumption that most people were not inclined to learn to program the computer. They could be expected to speak English and understand relational algebra, but they couldn't be expected to learn an imperative programming language. The existence of SQL stands as proof that at least some people 50 years ago thought there were multiple classes of user.
nothing makes it impossible, but they already have Excel installed on their computer and they learned how to use it. Depending on where they work they may not be able to install Python or R or a database.
Most people who have access to a spreadsheet don't have access to a compiler or interpreter, or the desire or time to learn them if they do. Most people learn what they need to do their jobs, and then go home and forget about it until the next day.
Telling everyone to learn Python to solve all of their problems is not a legitimate or realistic suggestion or solution.
Why? We expect huge swaths of non-programmers to learn R to work with data. Seems like it just depends on the field. If Excel was an integrated Python environment (or VBA or whatever pick your language) then I bet users would have learned it all the same. Twenty years later I bet HN would be full of complaints about how people have a hard time transitioning to "real" Python because they learned the Excel flavor.
> We expect huge swaths of non-programmers to learn R to work with data.
I’ve worked in academics and industry around biologists, chemists, physicists, statisticians, bioinformaticians, and all varieties of engineers.
I’ve never seen “huge swaths” of anyone expected to learn R for anything outside of a few niche areas in statistics and bioinformatics.
What people are expected to know is how to use a spreadsheet. What people are often given is Microsoft Excel, and essentially nothing else. A lot of companies wouldn’t dream of letting random employees install or use R or Python.
It’s not ideal. But some battles can’t be won and aren’t worth fighting. Which is why people use Excel for so many things.
Do we?
I never seen R being used, when Excel doesn't work out, it is something like Tableau instead.
Because they don't know it's programming. Seriously. I dated a woman for five years who was an accountant and a spreadsheet wizard. I told her that doing what she did with Excel, she was just as much a programmer as me, and she flat-out refused to believe that she had the mental capabilities required to be a programmer.
Years after we broke up, a new company she joined required her to take a VBA training course, and she texted me and told me I was right, VBA was easy and her biggest challenge was being patient while the other students struggled.
Discoverability is a big one. People really underestimate the value of having a menu, an actual fucking menu, listing all the functions you can use. Typing and getting autocomplete is a poor substitute, and you don't get even that in SQL, Python, or R by default - there are products that can provide that for you, but only after an expert has set them up.
I agree. However, so many of my use cases include a one-to-many relationship that I was outgrowing excel/sheets too quickly. Once a project added a VLOOKUP, it hit an inflection point in complexity.
I spun up a local Grist instance in my org, using SAML with our org's email authentication. It's intuitive enough that I've replaced a few shared spreadsheets with it (now with rowwise permissions) and powerful enough that I've also replaced a few internal CRUD apps.
https://github.com/gristlabs/grist-core
While Grist is a brilliant product, I really dislike the spreadsheet marketing they use.
It's not in any way a spreadsheet, you can't use rows correctly and everything is stuck in columns. Not to mention the forms you use for input are not user friendly compared to a simple understandable coloured cell
>> especially so for people who can't code
Minor point, but I would say that people who can construct formulas, are indeed coding.
I agree spreadsheets are amazing, but they are not databases. Much grief has been caused by trying to make them be one.
The gap in conceptual complexity to switch to databases is just way too high for most people. One lets them accomplish the business goal, the other does not.
Have you not heard of spreadsheet-database hybrids? Like Airtable? Or if you want to use Postgres: https://visualdb.com
And yet...they are often used as databases, successfully.
To expand on the overlooked point: it gives you a DB and a programming environment (however challenged) that you can use without needing sign-off from IT. In any moderately sizeable organization, getting approval to use anything but standard software is slow and painful.
Nobody wants to explain to IT that they need to install Python on their machine, or drivers for sqlite, or - god forbid - get a proper database. Because that requires sign-off from several people, a proper justification, and so on.
> RIP HyperCard, may you be never forgotten.
There's Decker https://beyondloom.com/decker/
> It's the best authoring tool we've ever devised.
It is also a very bad co-authoring tool imo unless you have a very tight team and processes of how to use spreadsheets. I would not mind if I was using it alone. But spreadsheets encourage a certain naive "visual" approach to structuring data in them that can become an issue if you want to import the data to actually process it somewhere and your coworkers don't really understand this well.
Spreadsheets can be useful, however:
1. Speaking about excel in particular, localisation issues are an absolute nightmare if you happen to live in the wrong country (commas vs dots for decimal points) especially while importing CSV files (which is already unnecessarily complicated in excel). If somehow you don't notice these issues, you end up with wrong data without understanding there the error came from.
2. If your coworkers do not really understand very well how spreadsheets work, you quickly get to become really frustrated with issues coming up when you have to import a spreadsheet for actual processing. Datetimes with different forms, coloured boxes being meaningful, mixtures of text and numbers and whatnot.
Yes a big part of it is "people problem" rather than "technology problem" but imo spreadsheet technology (excel, google sheets etc) encourages a variety of practices that make it less reliable. If the technology gives you the freedom to mess up too easily, imo it is not just a people problem.
I agree. It's extremely hard to learn to use someone else's spreadsheet unless they're sitting right there with you watching you fumble through it.
I have a couple of spreadsheets that I use on a weekly basis, and I found it easiest to build both of them from scratch, despite the tons of examples floating around for exactly my use cases, and despite it being my first time building anything with a spreadsheet in 10+ years.
On the bright side, after using these spreadsheets for a week, I lost all desire to write apps to do the same things. Google Sheets is a good-enough UI and solves sync across different computers and mobile.
Having worked on Lotus Notes, I am acutely aware that groupware wasn't the answer either.
i never loved nor hated hypercard. it was straightforward and clever but i really only used it for one thing: i made cardstock labels and liner notes for my audio cassette "rips" of albums (my 20mb hard disk (we didn't have MiBs then) wasn't going to hold many mp3's ;)
i might have used it for burned CDs too, I can't remember. at work i had access to burning CDs at scale back then, I just don't remember when the blanks became cheap enough that nobody would notice my pilfering and and whether i still used my mac. i did burn disk backups to CDs
I would agree with you except the UI is so horrible.
Give me a spreadsheet with a world cksss user interface and then you’ll have something!
Spreadsheet is the user interface.
Also what you're looking for is called Microsoft Excel. Every one else is doing webshit UIs which can't be world-class by definition, because they hardly scale to real workloads :).
And not to forget, you can run Doom and Tetris in them.
In both GS and XL, actually.
Excel used to have its own video game as an Easter egg.
> A spreadsheet gives you a DB
They can emulate behaviour of databases; but the missing parts missing will haunt you. Spreadsheets are a jack of all trade, mastering nothing, haunting you with everything;.an amplifier for the Dunning–Kruger, where people are misguided about data-quality.
Spreadsheets are indeed a great tool, but the implementations we have today are bad, with too many booby traps, not enough safeguards, not even much comfort for those with higher demands.
> spreadsheet gives you a DB
Yeah a DB where any user can accidentally hit the spacebar and erase a formula, and never see any warning that their outputs are now horribly inaccurate.
Data > Protect sheets and ranges, choose Protect range or Protect sheet, and then click Set permissions to customize who can edit them.
What Problem?
and they save versions every edit or every few minutes too. It's free version control that you cannot forget to turn on
Huge contrast with MS approach to this
MS approach is the same these days actually, people even complain about it.
When was last time you used Onedrive or Sharepoint connected Excel? That's also how it works nowadays.
I am anal about doing this at the range level, but few people are.
Another oft overlooked point is that anti-spreadsheet people aren't actually against using spreadsheets, we just want our coworkers to stop placing mission critical operations in an enormous, half-baked spreadsheet that exists only in some long-since retired users home directory.
As someone who has been to multiple trade shows to show off our own spreadsheet product that solves some of these problems (https://rowzero.io/home), I can tell you there are a bunch of data engineers and their managers who have a visceral hatred of spreadsheets but have trouble articulating any reason for it.
Feels a bit like the no-code paradox though. When you make a sufficiently advanced no-code (or no-database) tool it becomes equivalent to code (or a database) and even though it does entice a novice to start using it, a complex system made in it is still complex code (or a complex database) and ends up requiring a competent programmer (or db admin) to maintain it, who wishes it was written the normal way to begin with.
I have no doubt that the stories of complex spreadsheet models as the beating heart of a business are true. But those models are likely the sole survivor from a thousand dead and gone spreadsheets that people extracted value from for a time, but just didn't have the ongoing utility or wide enough audience to merit being turned into a dashboard or web app. It would be a mistake to insist that all of those spreadsheets should have started life as something else, just in case maintenance should someday become necessary.
In other words, one of the core use cases for a spreadsheet is that it empowers a broad swathe of users (broader than Tableau or PowerBI) to quickly extract insights from their data to fill immediate needs.
Or at least, that's a core use case if you can get your data into a spreadsheet without too much trouble.
And then the attached part of this that you mentioned is that the cursed survivors have essentially outcompeted their peers for survival. They're winners of a genetic algorithm whose basis is company data. They have close contact with actual reality, and have been beaten carefully into shape by it. I have kind of a grudging respect for these because of that, actually.
> It would be a mistake to insist that all of those spreadsheets should have started life as something else, just in case maintenance should someday become necessary.
The problem corporate IT/Dev folks face isn't that an idea started as a low-code tool, but rather that the low-code solution is often dumped on them with no budget or desire to improve it to be more reliable and maintainable.
At least until something fails... and usually in dramatic fashion that then wakes leadership up to the idea that maybe we should invest more into this critical business process. If the company didn't go under in the meantime.
> but have trouble articulating
I imagine that's because it's not really a technical problem, but an issue with how the whole organization (mis)handles complexity, and we collectively [1] still struggle to model/name a lot of those problems.
[1] Yeah yeah, I see you there in the back, you excited cyberneticist bubbling with enthusiasm to share... but I mean as a practical widespread matter.
I've always suspected if someone were to make a spreadsheet app that solves most spreadsheet problems it would collapse most companies.
As I see it the limitations of spreadsheets are what keep them from becoming the official way of doing things. At some point most of the stuff in the spreadsheets has data provenance in a properly managed IT system somewhere. If companies could get rid of this part of IT they would suddenly find themselves in a trillion dollar pit of lost money/inventory, As the spreadsheet mess spiraled out of control with no source of truth.
I love spreadsheets for casual stuff, but my concerns with using them for anything heavy duty are twofold: change management and correctness testing.
Other software that I use and write is version controlled and has tests to catch errors, mistakes, typos. Those tests regularly find and prevent problems! Likewise version control.
Could we get the same with spreadsheets? Seems difficult but not conceptually impossible, particularly with LLM assistance.
Imagine if people used Emacs the way they use Spreadsheets. "Hey I made a way to simplify our workflow, it has forms, buttons, gizmos we need" then you go to their desk, and its some custom Elisp abomination. I have to imagine this is how most people who hate spreadsheets see them. It still works, but it's a quirky solution.
Also I remember Row Zero the demo on your home page was impressive. You guys were S3 engineers too, good to know your project took off. :)
One of the surprising things about working inside of $MegaCorp is that if you knock on enough doors, you'll eventually find that each org has, like, one dude* with a spread sheet that powers everything else. Teams will get spun up to try to "automate" this spreadsheet, but, on a long enough time horizon, the spreadsheet wins.
Similar to the author’s cases: I’ve sat through several presentations of small teams who worked for 6-10 weeks to create a web app that does something (the details vary slightly from case to case) where at the end of the presentation, my first thought is “what a waste of effort and money; that would have taken 2-4 hours if they’d just used a spreadsheet”.
This speaks more to the complexity of web and web development than as a pro of spreadsheets.
You can create a super quick Python app with visualization and whatnot in about the same time as a spreadsheet. But then it's not online. And it's not best practice.
Web is just a fucking beast and then developers go in and add additional complexity.
It would probably be a much simpler web app if you made it just, like, a bunch of PHP scripts thrown in a folder. But they won't do that.
And it was probably created without approval.
... and been changed 3 times in the weeks it took to deliver the app.
I see these complaints on HN a lot, and maybe it’s anecdotal, but I just don’t see this in the real world these days.
If someone shares a sheet with me, it’s for the intended purpose of sharing data and/or visualizations of that data.
I’ve always been a huge fan of spreadsheets, and the rare times I’ve encountered them being misused, it was a long time ago, and not near enough to make me an “anti-spreadsheet” person.
It sounds like these anti-spreadsheet people need to find a new place to work and/or new coworkers.
Either way people shouldn’t be anti-spreadsheets because some people misuse them. That doesn’t change the fact that they’re a great tool for tracking/sharing/visualizing data.
> I see these complaints on HN a lot, and maybe it’s anecdotal, but I just don’t see this in the real world these days.
It happens all the time where I work. I don't want to be specific, but we have lots of examples here. In some cases people don't like the core software, so they work around it by tracking things on a spreadsheet. And sometimes that spreadsheet disappears (in one case, it was being kept on an XLSX on a USB thumb drive, but the thumb drive got corrupted and we lost some very important data.)
The availability angle changes things quite a bit. Having a single source of truth online sheet is much different than a file that is passed around.
This is anecdotal bias even now. The number of these monster spreadsheets running organizations that should be more sophisticated than they are would most likely keep anyone here up at night.
I was part of a team helping a Fortune 500 company whose inventory system was basically a master spreadsheet that maybe 8 people in the company actually had write access to. Everyone reported numbers up to them and the spreadsheet had read only views for purchase order projections.
To say that it was a nightmare was an understatement. They were willing to dump vast sums of money to get something better, but they'd homebrewed so many human processes to deal with the spreadsheet that they struggled to adapt to a more conventional way of doing things.
Found the GAP employee.
And if you aren't this story could have come from one.
Not GAP, not even clothing, but still retail.
This depends a lot on what you do. Try working with a decision analyst sometime. The entire economic model with a decision tree and monte carlo analysis of cost overruns, etc for a multi-trillion dollar decision will literally be a arcanely-complex spreadsheet or two on someone's laptop.
With that said, it's still a great tool for the job because the different stakeholders can inspect it.
>I just don’t see this in the real world these days
Lol. Go to literally any bank. They all have a legion of accountant,analyists that's sole job is to maintain their little fiefdom of spreadsheets that only they understand.
If most people knew just how held together by string,tape and gum the banking industry is there would be a run on the banks.
There is also always some 75+yo part time guy that maintains some sort of critical system. He always says, "I want to retire but they keep throwing more money at me"
My big gripe with spreadsheets is just that there's a lot of bloat on top of the spreadsheet which makes large datasets difficult to work with.
Otherwise, I find them to be great deliverables.
How large are you talking about? Have you tried https://rowzero.io?
>but I just don’t see this in the real world these days
May be due to the fact you're a single datapoint and not omnipresent at every company. What a weird argument.
You need to give them a tool that's as easy to use as a spreadsheet, and yet stores data in a relational database. There are plenty of spreadsheet-database hybrids in the market.
Using any tool but Excel has the same problem as finding programmers who are willing to use some obscure proprietary programming language. They're going to worry about career lock if they're not developing portable skills.
Even though Excel is proprietary too, it's ubiquitous enough that people don't have to worry about it.
What about a tool that tracks updates to shared Excel spreadsheet and replicate them in a SQL database?
And then, if somebody makes a change in the database, a trigger will update the spreadsheet
Such a two-way binding makes it possible to continue relying on spreadsheets for UX, all the while the data is not locked in there and we can also have other processes handling the data (a web app, some cron job, etc)
Maybe market it as an API for excel or something
I don't use Excel much, but I do the analogous kinds of things with Python and Jupyter notebooks. The problem is that adding some kind of layer requires the involvement of corporate IT, which blows away the advantages of DIY'ing things.
That's true, nothing is as ubiquitous as Excel. But Excel is not designed for multiple people simultaneously updating data. At some point you need a database.
It's not perfect, but Excel can track changes by multiple users. Excel files shared on OneDrive/SharePoint allow multiple people to simultaneously update the data, and it tracks each individual change by each user.
Are any of them as easy to use as a spreadsheet?
I would say Airtable is. Or if your users are slightly more technical you can try https://visualdb.com/ because it lets you use your own Postgres instance as the backend db.
I feel quite comfortable in Excel - used various tools like Power Pivot, Power Query, OLEDB, created my own functions, Python within Excel, etc. - but Airtable felt so confusing and limiting. Other former colleagues also struggled with Airtable; maybe it was not explained to us correctly.
I’ve used Airtable a bit. I think it’s really cool and would like more people to use it. However, it’s a lot more clicks and key presses to get things done - especially data entry - than in Excel. This also makes it better, since you can put constraints on tables, for instance.
You are absolutely right about needing more clicks and key strokes in Airtable. You have to reach the pain threshold in order to look for alternatives to Excel. And how soon you reach the pain threshold depends on how big your data is and how many users are trying to modify the same data at the same time.
See here to understand what you are missing out by not using a database: https://visualdb.com/comparison/#integrity
NocoDB is also a self-hosted option. I used it to power a family project that required regular API access, but without the rate limits of Google Sheets.
so true - as the spreadsheet "guru" at most of my employers - most of the issues with spreadsheets is misuse which is very common sadly
though, much programming is poor and often can be accomplished better in a spreadsheet given the situation and use case...
Excel, creating job security since 1997.
That's every company I've ever worked for, whether they have 100 employees or 300,000.
As opposed to placing the mission critical operations in some huge enterprise Java deployment which has been touched by thousands of contractors, all of whom have only a very rudimentary understanding of the actual business logic.
I think even a complicated spreadsheet that can be directly edited and modified by the actual business stakeholders is preferred.
The main problem is that a complex spreadsheet is just code. Its a bundle of logic and data. That's code.
If the business stakeholders can edit said spreadsheet, they can code. Not well probably, but they can.
So, theoretically, they should be able to open a python script or whatever and hack away. A lot of calculations are actually much easier and straightforward in a real language as opposed to Excel.
But they won't, partially because developers would never let them.
> even a complicated spreadsheet that can be directly edited and modified by the actual business stakeholders
You can do that in a spreadsheet-database hybrid such as Airtable.
Poe's law. If you use a spreadsheet as a DB for any sort of application, you should be tarred and feathered, and never infect any engineering team ever.
Your 'trifles' are the biggest screw-ups from functionality to INFOSEC.
MS Excel is much much much much more accessible to the normal office worker than MS Access. It's not even close. As a kid, most of us intuitively picked up Excel but Access was a mystery even with a teacher in computer class trying to teach us the basics. Later I learned SQL to create websites, and graduated with a good CS degree, but the learning curve is uncomparable.
Reminds me of "Ask HN: Is the world run by badly updated Excel sheets?" [0]
You need experience to see the shorcomings of spreadsheets. No version control. No tests. In general it's good for things that don't need to evolve, but stay the same (most likely because they're short lived).
[0] https://news.ycombinator.com/item?id=33611431
[EDIT] An example of a comment from that thread pointing in this direction:
> In general, you adapt to the excel owner's quirks, not vice versa. If you don't like it you should create an excel sheet of your own and copy/paste, which people also do.
> I knew a project manager who's job seemed to be reconciling multiple versions of a spreadsheet with different authors.
Well yes, starting as a coder in the 2000s in the US, I always thought of my job as turning tortured spreadsheets sitting on a Windows network drive that have to be constantly babied by an underappreciated office staffer into web apps. But I do recognize that a lot of businesses have been run on spreadsheets and run well. There’s a scaling problem and when it hits, ideally you know and can move to an app, but perfect is the enemy of done.
> No version control
You can use version control with Excel spreadsheets, though it's not very good. It's called "track changes" and even has a limited capacity to approve/reject changes from other people.
Very few people uses that feature, especially not the people who have built a Rube Goldberg machine to run their business processes, but you could do it if you wanted to.
That's not the only version control through - if you use Excel connected to Onedrive or Sharepoint (like most major orgs in my country), then you have version history built-in tracking every edit going back months.
The people who have "built a Rube Goldberg machine to run their business processes" should have used a database not a spreadsheet. Though they likely don't have enough training in database design and so if they had their result would be worse - but that is the fault of their lack of training. To be fair, database training is not something they should have in their position
It’s tricky because a lot of these spreadsheet “apps” are made when the business is young. Specifically non-tech companies who don’t have IT departments let alone any developers. They hire an MSP, get office, and go to town in Excel.
By the time they do get big enough to hire internal IT, the Rube Goldberg system is entrenched. Then by the time they get big enough again to need an internal dev team because off the shelf SaaS no longer cuts it, it’s too late. It’d take too many dev resources too much time and money to fix the spreadsheets, design databases, and start popping out web apps.
Plus the software development process is too rigid for how fast business requirements can change. The accounting department will just do it in Excel in an afternoon instead of being willing to wait 2+ weeks for the next sprint.
So we end up at a place in big enterprises where only some things get successfully moved to something more robust but there just isn’t enough resources (or will to allocate those resources) to tackle every spreadsheet, and so there are always key parts of the business that will forever run on Excel.
You can also just put the spreadsheet into a git repo. Done. Version control.
You can't track who changed what rows that way. Excel has native support for that.
If all you want is to see previous versions, just make the files read-only after saving them and increment a number in the file name every time you change something.
You can if you use csv. You will see the change in a diff and who pushed the commit.
I've mostly seen the problem manifest when information is spread across a multitude of spreadsheets all stored in different places. The people involved don't know which spreadsheets contain what information and which are supposed to. Sometimes they end up having conflicting data purely because they don't realise that someone else thinks the primary source is spreadsheet A while they're only making changes to spreadsheet B.
Any flaws with Excel haven't been due to the actual program or data, but just how the files are managed within projects. Labyrinthian sharepoints, files being forgotten about on network storage, etc.
> Any flaws with Excel haven't been due to the actual program or data, but just how the files are managed within projects.
Not sure of that. Examples:
https://www.sciencedirect.com/science/article/abs/pii/S01679...
https://link.springer.com/article/10.1186/1471-2105-5-80
> To cut things short, always use the easiest solution to solve a particular problem and once that solution does not work for the business anymore reassess what the new requirements are and either try enhance the current solution or find an alternative that better solve the problem.
When solving a problem, solve the problem you have, not the problem you think you might have in the future, or the problem you wish you had. Your solution will prove inadequate in the future, but you are unlikely to correctly predict in what way your solution will be inadequate.
> you are unlikely to correctly predict in what way your solution will be inadequate
but you can choose a current solution that does not block nor inhibit a future solution. As they say, always keep your options open, and don't vendor lock-in yourself into a corner.
> Your solution will prove inadequate in the future, but you are unlikely to correctly predict in what way your solution will be inadequate.
One inadequacy could be complete dependency on a vendor who accidentally locks you out of all your services or starts scalping you with ever higher fees. That one is quite predictable here.
But: if it is not more work, you can solve your problem by solving a family of problems around your problem in the problem space, making the solution robust, as small changes in the problem definition can easily be catached by small changes in your solution.
That should, with no extra work, solve future problems.
I think you are saying you should be structured well enough to change your system to solve future problems.
Like do you really need a dashboard on day 1? Or reports on day 2? Sometimes you just need a log of data. And the columns can grow and shrink.
Xoogler here. For my five years we only used Sheets (called Trix internally) for everything from project management, CRM, quarterly planning, reporting, interviewing, finances and so on.
This was not because it was a Google product (we used plenty of competitors' products) but because it is so easy to make them good enough for the task that you can move on to getting the job done instead of administrating getting the job done.
I can say that even now lots of machine learning datasets are kept as rows in gSheets and processed by Python running in Colab. In our team, all our evaluations: read input data from gSheet, run model inference, store outputs in gSheet for manual review if needed, process outputs to compute metrics and plot graphs in Colab. It is great because evaluation logic frequently changes, and without Colab you would sit and wait days each time for code reviews and stupid readability approvals.
And then, of course, if you want reproducibility, you just check in Colab notebooks into the source control.
I have heard that at google collaboration happens with: - making lists (google groups) - gsheets - basic real time chat with auto disappear
Is that the case? I find that super interesting. No sexy Slack or Teams type of thing?
Chat supports rooms with chat threads without autodisappear. Everyone is in various rooms for their local team, broader team, org, and cross functional stuff. The net effect is Slack-like.
There's also the ticket system. Sheets are commonly used by various PMs and TPMs for high level tracking, but IC eng stick with the tickets.
It works fine.
That was the case from 2011-2016. I can't say with as much certainty now, but anecdotally, probably similar.
> I entered the workforce about 9 months ago
Right or wrong, it takes a certain amount of chutzpah to put forth such a definite opinion after less than a year in the workforce.
What OP probably misses is the "there ain't nothing so permanent as a temporary solution" thing. I too embrace quick and dirty solutions but only if I have total control over the lifetime of that solution. If someone's going to ask me to deliver it immediately and then build a castle on top of it... I might insist on using a tool that has more up front cost.
Yeah, that line made me nearly laugh out loud.
Not saying the author isn't onto something: using the simplest tool that will get your job done -- and bonus points if you can reasonably use the same tool for several things -- is a decent principle to live by. Using an existing tool is great, when it meets your needs without too many difficult trade offs.
And where they work, it seems like business requirements are scrapped and rewritten every couple months, so the whole "temporary-haha-yeah-right solution" problem doesn't really rear its head.
The rest of us have to deal with the difficult mess several years down the line, because "we'll throw it away and write a new thing once we need to scale" is something that very rarely actually happens.
Of course, the author has no experience of a year down the line, let alone several years down the line.
I particularly enjoyed the “every couple of months…” bit. So, about four times?
'zactly :D I don't want to be too harsh though; I definitely think the attitude of rolling out something simple that works is a solid approach when compared with the gold-plated second-system-syndrome thinking that's terribly easy to fall into. They're not wrong wrong, but there's a bit more nuance to be had once you've seen the monsters that can grown out of a hasty prototype.
I work for an American mega corporation that you’ve definitely heard of - my department relies heavily on a couple of spread sheets. They have survived 3 times of corporate buy out of my factory.
The spreadsheets looked dated when I started working here, 7 years ago.
2 years ago, my latest manager tried to move the department off these spread sheets to the corporation wide system. Another corporate wide system is set to replace the system we still aren’t using by the end of 2026.
I suspect we’ll still rely on our spread sheets in 2027.
I use Google Sheets for all my finances, it's great.
I have an Expense Tracker UI within Google Sheets that allows me to submit expenses to the main sheet (currently just over 5000 rows of expenses over the last few years)
I only just recently vibe coded a web UI tool that uses a Google Service Account to add expenses to this Google Sheet for me, and then created a Progressive Web App from that so I could do everything on my phone.
In summary, Google Sheets is sometimes all you need instead of a database for very simple applications (and built for an audience of one)
I've done the same for a long time. I've tried so many purpose-built alternatives, and always come back to my solution. (Funny enough, Microsoft Money from 20+ years ago is closer to what I'd like than anything available today)
Not to say there aren't features I wish I could easily have. I could of course build it, and I've "started" so many times, but after a few hours of the typical boilerplate code you have to deal with, I'd always give up and go back to my surefire solution.
(This was before vibe coding, so I may take a stab at that)
And it all started with Visicalc. The spreadsheet and the word processor are the most important computer programs ever created. No wonder Google and Microsoft still make billions from these two.
Yep they were the original "killer apps" and still are. They are the reason that PCs gained traction in businesses in the 1980s. I helped my chemistry teacher in High School back then to use Visicalc on a TRS-80 as a gradebook. Almost anyone who has used a computer for work has used a spreadsheet for something, whether managing simple lists, or something much more complicated.
I would argue that the compiler is the most important computer program.
Or maybe that it doesn't make that much sense to look for a most important program.
s/programs/applications/
Absolutely agree with OP.
One thing I would add is, sometimes when you need some extra complexity that's too difficult to express or build in Google Sheets, one step above it is Google Colab (or any other Jupyter notebook).
Before building a full blown app, I always ask myself: 1. can this just be a spreadsheet? If not, 2. can this just be a Jupyter notebook?
And yes, the integration between Sheets and Colab is great.
IMO Jupyter notebook is a big step up in complexity from just writing a python script. You can put block comments in python script just fine. "let me spin up a local web server to view my comments and run my code in serial in an object oriented fashion" no thanks from me.
how do you upgrade some existing "thing" from a google sheet to a colab notebook?
I know of the gspread package for python... but I can't see how that gives you anything but the raw data from the sheet. any graphs and interaction (!) and such you would have to redo in jupyter.
Or Google Apps Script! You can get a long way with some simple scripts to import data, etc.
I can't find who coined it but there's a saying along the lines of "a spreadsheet is the second best tool for any job"
For those who hated the unmaintainable mega spreadsheet of death, MS Access was actually a quite decent solution. It allowed you to sprinkle some structure and maintainability onto a spreadsheet without losing the accessibility and ease of development. You could whip up really functional UIs without much coding knowledge. 20 years later and I still don't know what the replacement for Access is in today's world...
Amen. IMHO the equivalent nowadays would be AirTable - big fan of this, especially now they’ve added Interfaces which is the equivalent of the MS Access UI layer.
"Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."
- Donald Knuth
Start with a gsheet, when it breaks build something else.
True story - I know a guy who built an application using Excel for tracking toll charges for car rentals back in the early 2000's. Over time he built out a team and an application. Piece by piece he automated things, but he initially did everything by hand, tracked it in Excel and printed it in PDFs out to his customers for reconciliation.
He sold the business for $400M. No outside capital, he was the only owner.
Anecdotal, my previous employer had a contract once for a gas storage / exchange, for years their whole business relied on an Excel sheet (basically tracking gas storage transactions from various customers). I don't remember why but they decided to migrate that to a proper application, I think it took a full development team two years to build in all.
But it's likely that, as these things go, they added much more features and visualizations on top instead of just a like-for-like replacement.
TL;DR that company was bootstrapped successfully on just a spreadsheet.
Agreed. That is my point. If that company had built the app from the start it would have died building it.
> Start with a gsheet, when it breaks build something else.
Absolutely don't. The one who built the spreadsheet will have changed companies and the "business logic" and the knowledge will be gone with them. You're now stuck with a blackbox that no ones knows the specs of but everybody depends on.
If the sky doesn't fall the sky doesn't fall. Buddy of mine in sales is using some old DOS software from the 90s to control inventory and quotes. I bet there are absolutely zero people who know how it works in that company today. But, it works.
Turns out when you make relatively simple software, it doesn't really need maintenance. How often do you need to maintain a function like f(x)= mx + b? If it works it works.
The question is not whether it works or not. It's that it becomes the bottleneck of your infrastructure.
Those users are accustomed to doing their work in a spreadsheet so it makes it harder to automate the process.
Spreadsheets are amazing tools, but they must not be used as the source of truth.
It is kind of interesting seeing the fear developers have over "everything in finance is on excel." It kind of reeks of armchairism where one assumes the worst immediately and assumes this assumption has somehow not been realized by the domain experts in this space who are in fact also smart spend all their time on the thing.
To an accountant, excel spreadsheet is a source of truth. There is no undetermined behavior. They can look at the calculations underlying the spreadsheet and understand what is happening, no different than a developer looking at source code. They do in fact have their own forms of unit tests considering these data are audited in a far more rigorous fashion than most any code that ships with unit tests.
How is that different than an engineer building out a service implementing material business logic then leaving for another job?
A spreadsheet doesn't scale, is easily lost or corrupted or stolen, doesn't have security and people that tend to use it don't add data validation and don't care about atomic properties or data consistency.
These are different reasons than given previously. Regardless, Google Sheets are automatically versioned and have extensive access controls, both at the document level, and cell level. Further still, these types of documents are not black boxes, since anyone with access can inspect the data themselves. Arguments regarding scale and atomic operations/properties/consistency are fine, though I do not believe all business logic is necessarily beholden to these qualities.
Let's qualify spreadsheets as software: critical software should not be made by a non-technical person that doesn't know software engineering principles.
I guess Google Sheets invalidates some of my arguments, but Excel certainly does not. And, even if the feature is there, I've never seen them applied.
Agree but a company can still have rules for a sheet tool to have e.g. comments, explanations as part of it.
If you can do something badly and you can do something the right way in the same amount of time, why do it wrong?
“Same amount of time”, that’s where you are wrong . Then again, I’m not the one saying Knuth know better than me, maybe not better than you though.
I'll die on this hill.
Google Sheets was phenomenal for prototyping apps and getting quick feedback from users back when I used it in 2015-2020. Back then they had this janky implementation of Mozilla Rhino underpinning their "Apps Script" engine and it still beat the pants off of anything else you could use for free.
Certainly you can shoot your feet with the various spreadsheet-isms but if you're diligent about keeping raw data pure (preferably in a completely different sheet inaccessible to users) it does a bangup job of quickly shoving a UI in front of users and letting them realize what they want and iterate on it before calcifying it into a more rigid system.
Exactly this. Worked for a startup that had dogmatic leaders on 'using the best tool' 'spreadsheets are bad' (a trope they just got from people, not having used it themselves). Ended up spending thousands on consultants to build reporting etc that ended up needing to be changed after 6 months because of business/personnel changes.
Spreadsheets are the best tool to quickly spin up and make changes to data.
I've always thought about a tool to make a 'front-end' version of spreadsheets that end users use, where the layout can be a bit more freeform (i.e. build reports and dashboards in spreadsheet, then 'select' these reports and paste them into a front end WYSIWYG tool).
Check out AirTable it’s exactly this. (Have mentioned it on two comments now, but I’m not affiliated with the company just a big fan)
One thing I've learned: Never (ever) make yourself reliant/dependent on Google products. If you do get banned / locked out, it is the most AI-Kafkaesque process imaginable to regain access. And you could stay locked out for years.
I use Google sheets myself from time to time, but I regularly do backups of the sheets I'm working on, or anything important I have access to. I've been in the hole before, for reasons I still do not understand, and it was one of the most frustrating "customer support" processes I've ever experienced, and it took years.
I keep telling people to make backups of "cloud" services ever since Grooveshark died from one day to the next
Maybe Spotify won't be taken down overnight, but they can lock me out for various reasons such as misdetecting an IP address (Google wouldn't let me log in at all when they thought I was in Russia, when I was at 31C3 in Hamburg, Germany, a conference where they afaik use some temporary IP space — I don't know what consequences that would have nowadays)
Hacker News also: if there are things here you want to keep, store them yourself
Facebook chats, Signal, etc.: download the data in a format you can decode if there's anything you want to keep. Make sure you can decode this Signal backup format if your phone dies
> I keep telling people to make backups of "cloud" services
The usual rule when making backups is that you need 3 copies, one of them offsite. A cloud storage service counts as an offsite copy, but you still need two more, typically one on your computer and one in cold storage (ex: external hard drive).
Treat cloud storage like you treat your hard drive, it can fail at any time. The failure modes are different: mechanical failure vs losing access to your account, but the end result is the same: the system is unreliable and you have to engineer around it.
I think applying these traditional schemes to SaaS environments (now called cloud) can be misleading
When people want off-site backups, the server owner can say they've already taken care of that. I'd say that having a copy under your own control is a separate checkbox we should include!
Good advice. Though I’d say you can count the cloud storage as 2 copies. They typically replicate the data to three drives, that covers all the typical failure modes you’d normally get when running a drive yourself. Then with a simple click you can even get a replica in another region.
The third backup being in a decoupled system on site is what you now count as your ”offsite” backup. Having this last copy is non-negotiable, no matter how many 9s S3 claim to have.
Also backups in two separate legalizations if the hosting company is not in the same country as you or your company.
Yes and don't forget signal is rolling out free cloud backup for texts so it should be making the process of backups even easier for non techy users.
How do I get it out of their cloud? It works as a backup to my phone, but I'd still want another copy that I can access regardless of whether I've got access to that phone number right now. Sorting that out with the carrier can take a while
What's (to me) much more exciting to me is the incremental local backups they're working on. I've iirc looked into how to decode these big backup files, and copy them off my phone semi-regularly, but this being rsyncable will make the process much faster
I assume the process is basically to restore from cloud on device and then export a local backup. But I don't recall them saying anything specific about that. The incremental backups do sound really nice.
That sounds like it'll require access to the phone number to set it up on a new device, and that's assuming the user promptly has the funds for a new device
Even if it works for desktop clients also, that still needs to be set up using a data matrix scanned by the mobile device (or if that's already done before you lost the origin device, you can "simply" extract the faux-encrypted sqlite format that the desktop client uses, albeit with having to recompile this encryption extension for Sqlite manually — ask me how I know..)
I'm still heartbroken about Grooveshark all these years later.
I still have my copy of [SciLor's Grooveshark.com Downloader][1] for posterity's sake :)
[1]: http://www.scilor.com/grooveshark-downloader.html
> even with Grooveshark being down it still works!
Wait what, how does (did?) that work?
And more importantly (I can find the opus files myself): can/could it retrieve my account data to know which songs to download?
I've been able to partially reconstruct my music from localStorage, downloaded songs on my phone (yay for having root and access to that data folder), and memory, but it's still incomplete
Fwiw, here's my own little contribution to getting song data from Grooveshark, in my first blog post: https://lgms.nl/blog-1 (not my first blog site though). Happy to meet other fans :D
Any good tools for automatic backup of these things? How would a non-tech-type do it?
This probably doesn't qualify as a non-tech type answer, but I have a Synology NAS which includes a feature (CloudSync?) to automatically download Google Drive documents in docx, xlsx, etc. format.
Ooh - I have a Synology NAS and didn't realize it can convert files on sync.
It's also ironic that we're considering docx etc as open formats these days.
There's sadly no silver bullet, especially for non-techies. To me it's like buying vegan products where available: I can't trivially become vegan with no effort, but I can affect market forces by preferentially buying things that align with that ideal. People could at least apply this where possible and buy products where they're in control somehow
For storage platforms like Dropbox or Onedrive, it can be as simple as ctrl+c'ing the data out of there every now and then
For Spotify, you can do the GDPR export and check that you can open it somehow. Even if it's not super readable, you can figure that out (with a tech friend or LLM perhaps) if you turn out to ever need it
For Signal, I've got no idea. The format is hard to work with for hardcore techies. They really really don't want you, ahem, attackers to get that data in the clear. (Two-sided coin). Make sure to turn on the backups, write down the passphrase, and take them off your phone every now and then, and hope there's a restore method when you need it
Perhaps there's a market for this. An automated or semi-automated backup of many cloud services. It could probably be as simple as doing a gdpr request in some cases.
That's not necessarily simple though, because some companies are shady and ass about it. And then if you want to pursue the matter, be ready to face significant effort needed to file a proper complaint in the correct channels for that.
Fwiw, GDPR has a forgotten clause that data exports need to also be provided in machine-readable format for easy service migrations and promoting competition / reducing vendor lock-in
The only reason I can imagine why nobody implements this, is that they like the status quo where it's hard to switch to their service, but equally hard to switch away. Once this becomes commonplace (e.g. because vendor A makes users aware it's a thing by implementing it for migrating from vendor B), vendor B will "retaliate" and A will have to truly be better than vendor B to retain said users
That is all to say, this might yet totally be a viable and legally unblockable business avenue for a third party to initiate. I'm just not sure there's enough demand to warrant (read: pay for) the effort involved. Maybe if you can have an LLM read the api docs of the service where you want to do the import and autogenerate a mostly-working version?
If you give a shit about music you should not use Spotify at all, but that is probably a different discussion
It is, but I think most people would care to at least have the song list, even if they'd need to go out and buy the corresponding data if they stop using the streaming service, or manually enter it into another streaming service
I can't tell whether I'm being super paranoid but I've been burned by Google so many times on product sunsets that I've just removed all of my data from them.
I managed to set up private self-hosted versions of an email client, photo viewing app, and barebones alternative to Docs and Sheets. Switched from Google to Kagi, and Chrome to Brave, but generally keep my own bookmarks of sites to use rather than using search engines.
I still run a skeleton Pixel, but the storage is almost exclusively just a very limited range of apps I use. I managed to get Google One storage from about 700GB to about 700Mb over the course of the last month or so.
Sounds like you're not using something like Nextcloud (which should cover all your bases it seems). Any particular reason, any experiences you want to share?
I just sort of wanted to learn how to build (rudimentary) versions of the same apps I've always used made by other companies/people, and like the idea of the data being as clean as possible. I'm a bit of a data purist, so I store all of my photos unedited, and keep all of my text documents as simple as possible (minimal formatting, data-heavy).
I'm also wary of just moving from one product to another, with the hassle of transferring things over constantly, security breaches, product sunsetting and all of those sorts of things.
I'll give Nextcloud a look out of curiosity.
I'm on a similar page. I try to set things up so that as many things as possible are regular files in my folder structure, which I then sync across devices. In my experience those are the only files I can rely on being able to retrieve long-term. Eg I don't use a photo app at all, I just have a folder with sub-folders (where I copy them manually). I don't know (yet) how Nextcloud fits with that, but it has several features that look really interesting in general (eg video calls).
Sheets is the one thing I haven't found a good self-hosted alternative to.
I tried Nextcloud a couple of years ago but found it really buggy and slow. Even the basic notes editor on Android was absolutely terrible. Absolutely no comparison to what I'm using now, Obsidian with Syncthing.
Can anyone recommend a good sheets alternative other than Nextcloud?
I'm working on De-Googling. I now have a Mac and an iPhone instead of Windows/Android, but switching from Drive to iCloud seems a fairly parallel move.
I also set up my first home server with RAID NAS. It's on my list to spin up an OpenOffice container or something I can use to replace Google Sheets. That will let me delete my Drive data; next is Google Photos and eventually Gmail.
It took about a week for me to completely de-Google from scratch.
Drive was easy enough to download everything off, but the real pain in the arse was Google Photos. I had something like 250 individual 2GB zip files and the supplementary metadata was separated off of the image files themselves. I had to put together some Python scripts to clean up all the different file naming formats over the years (PIXL_YYYYMMDD, IMG_YYYYMMDD) into just YYYYMMDDD, and reattach the metadata, and then check through that everything was safely downloaded before deleting the Google Photos.
Google Photos had some weird caching issues where it kept showing images I'd deleted and emptied from the bin, which was a little concerning. They were only appearing on my phone and persisted multiple times after clearing the cache. I couldn't find them anywhere in the phones internal storage.
Perhaps google takeout would have been easier?
That was Google Takeout! Although in retrospect I did find larger ZIP size options after doing the original export. But it filled Google Drive with 700GB of folders, so I just stuck with downloading the 2GB ones.
Is your home server LAN only or have you configured it in some way to be accessible and secure on the internet? I'm interested in setting up a fileserver myself but I'm not sure what the latest is on security.
I definitely don't open a bunch of ports to the internet! I use Wireguard to VPN back into my home network from my mobile devices. Wireguard only responds to packets that contain a valid preconfigured crypto key, so while the WG port is technically "open" it doesn't respond to a port scanner.
Tailscale is a great place to start. It uses a VPN to access your servers while outside of your LAN while avoiding the security risk of them being wide open to the internet.
So the way I understand Tailscale is that it's built on top of Wireguard; Tailscale claims it's "easier to use" but I haven't found Wireguard to be difficult to configure at all. Are there any extra benefits to using Tailscale that I'm overlooking?
Yes, Tailscale uses Wireguard. If you can use Wireguard, that is great. That is not an option for many people who are behind a CGNAT and/or do not have the ability to setup port forwarding. Tailscale also makes it easier for sharing access with other users.
What’s your Docs and Sheets alternative?
I’ve looked, I’ve never found anything that seems to both cover all the bases and not feel like a bad Microsoft clone.
Through my kDrive subscription, I get access to their own instance of OnlyOffice
It looks a bit dated like MS Office, but it does the job and since it used MS Office formats, I can edit the documents with Libre Office or other sofwares. And using the API, I can programatically access those files.
https://www.infomaniak.com/en/ksuite/kdrive
https://www.onlyoffice.com/
I just developed a webapp for it. I only used Docs for personal reasons, so my own version is basically just a really stripped down rich text editor. A lot of things I just save to .txt files.
It saves (both locally and to self-hosting) to JSON and, exports to PDF and HTML. And then I wrote a script to convert docx files over when I migrated from Google.
Obsidian with Syncthing works great for me over Docs.
Haven't found a good self-hosted Sheets alternative yet.
I just use any scripting language, mostly Typst, because then I have the analysis directly in the document
Microsoft Word and Microsoft Excel?
.xlsx is the key. Can use it with sheets, M$ or libre office. Or unzip it and take a look at XML.
same problem?
Why Brave over Firefox?
I assume you're talking about the free consumer tier?
Nothing like that should happen if you're paying for even an individual Workspace plan. You get a phone number for customer support, and it works.
Google shuts down free accounts when it believes they're being used for fraud/spam. And because scammers and spammers create them at virtually zero cost, and will fake activity to build account credibility until using them for nefarious purposes, that does mean legitimate free accounts occasionally get caught.
Regular backups are important no matter what though. Obviously Takeout exists, but there are lots of third-party automated backup solutions as well that will automatically convert Sheets files to .xlsx as part of the backup process. I use one that backs up nightly to my NAS.
> Nothing like that should happen if you're paying for even an individual Workspace plan. You get a phone number for customer support, and it works.
Last I was a workspace Admin, you had to login to get the phone number and the code to dial once you called.
It certainly did get you to a human. Unfortunately, they were not empowered to actually help with any of the things I needed help with, even when it would just be filing a enhancement request with the product team (they just tell you to post in the unmonitored product forum)
I've seen several believable tales of Kafkaesque billing issues leading to Workspace accounts being suspended. It took months to get them to do invoice billing.
>You get a phone number for customer support, and it works.
I don't believe this after decades of past experience with them trying to find any human to contact. Have you seen the phone number yourself? Normally they just give you the runaround trying to navigate a maze of support pages.
> Have you seen the phone number yourself?
Yes. Do you have a paid account? It's in the Google Admin console. It gives you a PIN to enter when you call.
The worst customer support experiences of my life have been from Google, both while using Google Fi personally and GCP while working at Replit in its early days. Thankfully I'm no longer using either of those products now.
Plenty of reports of people getting locked out of their Workspace accounts. Google even occasionally burns developers they have deals and working relationships with.
Just don't use any Google services. Not free, not paid (why would you send them money???!?!). Not for personal stuff, not for work projects. Not for throwaway data, not for important data.
The Google rage on HN is immature.
That's a feature of any SaaS. Adobe frequently shuts down ETLA customers due their own invoice processing failures. I can think of three significant government subdivisions that were unable to access any M365 service for 1-10 days as a result of a reseller change.
The real lesson here is that you need to understand the failure domains of the technology your business depends on. Your business is as good as the contracts you rely on. We're relatively good at preparing for IT failure, but not so much the other stuff. For small businesses, key revenue generation could be stopped by an employee doing something dumb with a corporate card.
The real lesson here is that almost all modern SaaS applications have massively under invested in customer support in order to appear more profitable or sustainable than they really are. One of the major factors behind LLM development is trying to solve this problem before the house of cards falls down. Companies were enticed by the recurring revenue of SaaS, but don't want to pay for the level of support required when you are responsible for all your customers data as well as their access to the service.
Why would a government division (or any 20-person office) pay a reseller?
Because government purchases go through the procurement office which is using an authorized reseller under a larger government contract.
Resellers handle a bunch of compliance paperwork necessary for the government, and are also contracted for migration and support needs.
> Plenty of reports of people getting locked out of their Workspace accounts
None substantiating the "most AI-kafkaesque process imaginable to regain access" upthread though. I mean, I don't know what you're citing specifically, but yes, obviously: business relationships like everything else get tangled up sometimes. People's electricity gets shut off incorrectly, people's Doordash orders arrive with the wrong stuff, phone bills arrive without the promised discounts; everything sucks, kinda.
But if you're paying the solution is to call your support contact and have them sort it out. And that works at Google the same way it does everywhere else.
You're right about google's track record but at heart yours is a comment about third-party cloud dependency, not google. As you mention, offline storage solves this and another commenter mentioned msft will ban you also (but you dont hear about it because...offline storage)
Track record is a factor that you should consider.
When companies buy services from others they often ensure that the contract has protection from things like this. They have clauses that the data belongs to them. They have clauses about what happens if the company is sold. They have clauses about abandoning the product. They have a number of other things added that I'm not aware of.
You as a single individual (and often as a small business) don't have the power to get that into a contract. However you still should read the fine print - you should go elsewhere if it the fine print is against you.
We bought a Google Workspace subscription for a building I help manage and I was shocked when I found out that you can't archive emails for discovery/legal purposes unless you buy a more expensive subscription that has access to the "vault."
We already pay nearly $90/mo for 6 seats!
try being banned by msft. I am still banned for 6 years without doing anything wrong. still lost access to all of my accounts.
A good reason why no one should ever have their Windows install linked to a Microsoft account, same for MacOS.
Who ever lost apple account by being banned? with no recourse? I don't remember a story like that
I've never heard a rant about people being banned, but i can think of a half dozen people who have lost their icloud accounts due to the combo of inexplicably not remembering or writing down their passwords and selling or losing a phone.
How is that different from losing access to, say, your own computer by the same route?
That's entirely different from another entity denying you access to your data.
People have investments in things like itunes, apps, etc.
are you trying to say if you forget your password it is the same as you getting blocked for no reason?
That's the opposite than ban by Apple. And also for this people can go to an apple store or call support right? unless they enable the most nuclear e2e option.
Can't of happened then if you don't remember a story like it...
I asked a question) Did I miss a story like that?
My dad got a Trojan and they took over his msft account to buy some Xbox cards. They banned him as well but he took them to small claims in the EU. As usual they didn't show up and he got a ruling to reinstate his account. Was under 100 bucks and he got his account back. If the account is really important I would do the same. There is a 90% chance they won't show.
just as a point of interest, in US small claims courts, the judge can award monetary damages, but cannot order somebody to do something (like turn your account on) i'm not sure if this varies by state.
This comment prompted me to go look at the various spreadsheet software available, since I was only familiar with the usual Excel / GS / Libre. There is also GNOME's Gnumeric, KDE's Calligra, Apple's Numbers, an online variant of LibreOffice called Collabora, an Excel clone made by a German company called PlanMaker, a Latvian effort called OnlyOffice, and then probably the most unusual variant, but somehow it isn't surprising that somebody made a spreadsheet based on Python:
http://en.wikipedia.org/wiki/Pyspread
Google takeout is key. Why struggle backing up individual Google things.
Do you have a good automated way to back up Sheets, etc?
This is a very interesting read, we are building Cursor for Google Sheets and the variance of use-cases we see is insane.
1. A lot of people are creating dashboards / CRMs - either they don't have any one selling them verticalized Software or its too expensive. 2. Some people have verticalized Software and they use Sheets so that they can share data with others without paying for per seat SaaS while not worrying about what the new members can read/write into 3. Lots of financial modeling and planning - From a chain of Cafe's in Laos, to Startups raising funding. 4. Lots of teachers trying to do scheduling for their school while ensuring that the teachers get enough of a break. We have seen this in Colombia, the US and Italy 5. A lot of market research and enrichment
A Spreadsheet really is the IDE of a billion people. You can try us here https://tabtabtab.ai/
The world is not binary, nor black & white. There is an entire spectrum of solutions between a spreadsheet and a highly-structured app. Sure, you can use a spreadsheet for anything, it's quick, and provides nearly no structure. You can also use a specialized application, tailored for the particular processes at hand, that does error checking on input, validates data integrity, and does not let you break data structures. And there is a whole spectrum in between.
One thing to note is that a spreadsheet (OPs insistence on calling it "Google Sheet" is amusing after years of hearing people call it "excel", it's a spreadsheet, people!) is a poor-man's relational database, with most spreadsheets having a single table, or multiple tables but modeling no relations. And you can't model relations in a spreadsheet in any meaningful way (imposing constraints, checking integrity, etc).
Written from the perspective of someone who makes a living providing a SaaS for (among others) inventory control, for which a spreadsheet is a direct competitor. Also, from the perspective of someone who has seen a lot of customer spreadsheets with inventory, not one of them in any way correct or containing good data.
Slightly Off Topic, are there any other online SpreadSheets other than Excel 365 and Google Sheets?
Some of them are AirTable like which is CRM focus, but I just want a really simple spreadsheet that is easily accessible and not from Big Tech.
I’ve mostly used LibreOffice for personal use and other cases where I don’t want to use Big Tech, but you could try OnlyOffice. I’ve also been interested in Grist, which is more like AirTable but programmed in Python and (relevant to your request) self-hostable.
Edit: Depending on your reasons for avoiding big tech, you may want to research the owner of Only Office, which was a Russian company but apparently isn’t anymore? You might want to also try CryptPad, which is based off of OnlyOffice and recommended elsewhere in the comments (which reminded me).
What's cool about CryptPad is all the data is encrypted behind the # tag key which never gets sent to server. So even the server admin don't have access to the user docs. It has being easy to migrate from server to server.
A truly shining example to google doc alternative.
It would be great to have some kind of syncthing <-> cryptpad drive, then it can be very nice alternative to even dropbox. Not sure what the development is ATM.
The web version of Apple Numbers is pretty good although I suppose it doesn't meet your non-big-tech criteria.
I actually dont have big tech problem, it is just most of the well knowns once are blocked in where I work, and now even Notion is blocked.
Try out rowzero.io! It's a pure spreadsheet like Sheets/Excel, but with a much larger row limit.
Have any thoughts on how it compares to https://baserow.io/ ?
Baserow is in the same realm of Airtable/Monday.com/SmartSheet/etc, which are all effectively visual DBs. These tools shine with structured data & rich field types. The core assumption that unlocks their power is that every row of data in a given tab has the exact same schema.
While powerful, this assumption also creates rigidity that a pure spreadsheet doesn't have. You can't, for example, do some quick scratchpad analysis off to the side of your data, or quickly subtotal a few rows with an adhoc formula. For that type of flexibility, you need a pure spreadsheet, which is the camp that Row Zero falls in (along with Excel & Sheets).
So, to answer your question - they're solving different problems. Some spreadsheet usage may be better served by a visual (or actual) database, which is why that sector has exploded in the last decade. But not all use-cases fit that criteria - the flexibility of the pure spreadsheet remains an incredibly powerful thing.
Thank You that looks fantastic! It feels snappy as well.
One of the biggest problems in business automation is the gaps between such low-effort “shadow” IT, low code platforms, and fully fledged out “proper” projects. The gap between “let’s make a google form” and “let’s build a react app with proper design, ci/cd, testing, cdn and so on” is too wide. There should be a bunch of intermediate steps there with a sensible migration path, but there are none, there are only walled garden alternatives that aren’t compatible with either.
I would argue the intermediate step are SAAS solutions such as ERP or CRM systems. Most of them offer sensible export options as well.
I've long argued that spreadsheets are essentially a structured programming tool for people that would never imagine they could or would program. And maybe even a gateway drug in a proportion of cases?
The problem is that spreadsheets are an unstructured programming tool. It's like BASIC with all its GOTOs, index-only loops, etc vs C with proper functions and control structures. You can have a structured spreadsheet but it requires discipline that almost no person (and certainly no organization) has.
Mary Shaw discusses spreadsheets as an example of vernacular programming in a paper I read: https://dl.acm.org/doi/abs/10.1145/3480947
Huh, this is a really fascinating article! I really like how she articulates common myths in software development. However, it feels like her remarks are more targeted at the academic CS community, because I think a lot of her critiques (such as lack of integration thinking) are already internalized by project leads of modern software systems.
The HN perennial video, "You Suck at Excel" by Joel Spolsky [1] really changed my view on spreadsheets. I had never bothered to learn them enough to utilize naming or any of the features that make spreadsheets much more comprehensible. I was very happy to see Google Sheets added named tables recently, too.
I've recently been experimenting in Apps Script to write my own (physical) book collection record system with a USB barcode scanner. So far I have nothing polished enough to show, but it is a very cool platform. I found it a bit frustrating that I couldn't just import NPM packages, but at the same time it's a good excuse to embrace simplicity and skip a library like Axios, and rely on its built-in fetch()-like API.
1: The original YouTube video has since been taken down, but you can still view it through the Wayback Machine:
https://web.archive.org/web/20161118170705/https://www.youtu...
Same, I currently have
- My own rough business accounting (download all bank statements and do some pivots and graphing. Real accountants do the real thing, but I like to have a version that makes sense to me and that is up to date)
- Personal accounting finance tracking for sharing expenses and tracking living costs over time
- Consolidated asset tracking across different projects/accounts etc, just a quick summary that's not perfect but spending 10 minutes a month manually updating it helps keep it in my head too.
- A lot of project management (we also have real PM tools, but I keep my own sheets because it's easy and it makes sense to me)
- A bunch of quick analytics (I also use metabase, but sometimes it's just faster to create a graph in sheets)
Most of the time the sheet is not the _main_ tool I use, but it is the easiest and most useful one, while the others have better integrations, safety mechanisms (I often end up with +500 or whatever in a copy-paste formula error and sometimes don't catch it), and collaborative measures (if you have 2+ people editing the same sheet you're usually going to have a bad time)
I feel this deeply. I only use Google Sheets, too.
It sounds crazy, but it’s the best tool for so many random things, and here’s why I stick with it:
It Just Works: There's zero fuss. I don't need to install anything, I don't need to save it, and I don't need to worry about the format. It's always there, and it saves automatically.
It's Simple to Share: If I need to show something to my spouse, a coworker, or anyone, I just send a link. No one needs to sign up or download some special app. Everyone can open it right away.
It's the Perfect Checklist: For managing my own stuff—like a budget, a travel plan, or even just tracking a personal project—a sheet is faster than any fancy app. I can make columns that say "Done," "To Do," or "Waiting," and that's all I need.
For most of my personal data and quick shared work, trying to use a dedicated software package is just overkill. Sheets is the easiest way to organize information in a clear, digital table. It's the ultimate low-tech solution to high-tech problems.
This is what we did in Excel. Is Google Sheet better somehow? Or is that only what new age kids know since college has adopted google products?
48 years old, so definitely not a "new age kid"
Sharing is the killer feature. Not that you can't share with Office 360 these days, but many of us were sharing Google Sheets years ago when the rest of the world was still sending Excel files as email attachments, and there hasn't been much reason to switch.
Probably not used by many, but if you need to break out of basic functions, some may find working in Javascript preferable to VBA.
It is "better" in the way that it is easier to share.
Sharing Excel sheets and keeping them in sync is tedious. (Even with O365/OneDrive)
This may also include sharing between your own devices.
I love excel and use it daily in my bullshit admin job.
But google sheets is so much easier if you have more than one person interacting with the data. It just works, easily, every time. Even with 365 or whatever for MS products, they're more cumbersome.
Well, did you suggest it to your boss? how did it go? bad organization is a two way resposability, except in the army.
> Doing the smallest and easiest solution to a problem as a way to get to know the full scope and then iterating after that if needs be is by far the best solution (for me).
100% -- this is YAGNI (or you-aint-gonna-need-it) and should be among the first things you think about when starting a new project.
I suppose the issue here is trusting Google with your personal and business data. Mining that information for targeting advertising aside, it's not unheard of Google locking people out of their accounts with no reasons or obvious recourse.
I wonder what the best non-mega corp solution there is for this.
Cryptpad comes to my mind although I suppose it might lack some features of google sheets but it has a web interface.
For a non web interface, things like libreoffice can be good too but I think that you are asking for a web version..
I am not sure if libreoffice has a web version, it seems that they do but I can't find much information and I might recommend crytpad personally so.
Why not use an open source spreadsheet in javascript and html that you can host yourself?
You can whip up whatever you want now with an LLM. And with JS it will save whatever you want in indexeddb or pouchdb and export to whatever formats like csv. Why lock into google?
For those who currently find themselves unable to use any spreadsheet because they are all based on algebraic notation, you might find the site below interesting. It's a spreadsheet for you that works with only arithmetic in two dimenstions. Be sure and try the first two short videos. You will never have seen anything like it. http://www.tmaker.site
I get the appeal — Sheets is insanely flexible and quick to hack together workflows. I’ve seen entire businesses basically run on it. The tradeoff I’ve noticed is that as client work scales, you start spending more time managing the sheet than the actual work. Curious — do you use it mainly for tracking, or are you also handling things like scheduling/invoicing inside Sheets too? I’ve always wondered where the tipping point is between ‘this is efficient’ vs ‘this is duct tape holding everything together’
I’m about to leave Google Sheets because I keep very long spreadsheets about my life and everything I do and it refuses to open at anything but right at the top. So every time I have to scroll and scroll to get to the bottom. Does anyone have a fix for this? Last time I googled all I found was some dingleberry on a Google thread saying that’s how spreadsheets should open. I moved to Google Sheets from Excel online that did that right at least. I moved away from Excel online because it has requirements for small file sizes and the images I would paste in the spreadsheet filled them up to the limit too fast.
Doesn't ctrl-end jump to the bottom row of the spreadsheet? Ctrl-down arrow will jump to the last cell in the current column. On a Mac it's cmd rather than ctrl I believe.
This reminds me of this idea of "Minium Viable Airtable" that I think is apt:
https://sirupsen.com/minimum-viable-airtable
I coach people for powerlifting and create their programs in Google Sheets. I even have functions setup for converting a given weight to their plate breakdowns (for example 455lb squat would be broken down as: bar, 4x45lb plates, 1x25lb plate). My athletes can enter their current one rep maxes and the sheet auto updates the numbers for each training session. They can record notes about how each set went, how many reps they got etc. and then I can review them. It's all super convenient.
You shouldn't use anything by Google.
I like what the author is writing. For the listed use cases, grist might be the better tool. It would also return control over your data back to you if you self-hist it (which is easy).
That’s what I thought almost thirty years ago: That MS Access is the solution to all problems in an office environment. I‘d model the domain and create a full working app with database backend in days.
And five years later I consulted companies who had business critical solutions built in MS Access that were not scaling anymore (concurrent users, faster database etc)
Applied to this article: Yes, you can use Google Sheets for all sorts of tasks, but eventually you will need to move on to a more robust solution.
Built entire businesses on Google Sheets and Apps Script. Powerful combo.
I worked on creating a card game with a couple of my friends. We kept all of the cards in a Google Sheet, allowing everyone to easily edit or create new cards. Then, I wrote a script to compile the sheet into a card atlas so that it could be consumed by Tabletop Simulator. It worked amazingly well.
The only issue was that I had to run the script myself, since my friends were less technical. I'd probably see if I could setup a workflow in Github Actions to do it for me if I were to do this again.
Everyone wants something like a local version of Airtable, but the issue is anyone that tries immediately turns it into a cloud product. Nocodb is better, but is still severely restricted & tries to think too much in terms of replicating Excel functions, rather than making it easy to create your own using JS/TS.
I've recently removed the fancytooling out of my pipeline, and re-done Jira on LibreOffice's Calc.
And with native python it has, I can query snapshots from Jira, add inputs etc.
So much simpler, you open Calc's window and just hop faaaast through sheets. Rather than opening your browser, typing URL, entering Jira, getting into correct board etc.
Need a to-do list? There too, just another sheet. Need to track your deployments? Just pull it into yet another sheet.
The sheet is everything you really need.
Only tangentially on-topic, but I do all the financial modeling for the past several (early stage) startups I've worked for in Google Sheets.
The ease, collaboration/sharing, and array formulas win out over the faster speed for calculations, better shortcuts, cross-workbook linking, and customization in Excel.
That said, it's been a few years since I've tried Excel so would love to hear someone convince me to try it again.
I'm using the MS suite for the first time in over a decade...and the collaborative aspects are still nowhere near Google's. I routinely get problems when multiple people are editing the same content (Word doc, spreadsheet, or PowerPoint). And sometimes the thick client works best, sometimes browser editing works fine...but it's inconsistent.
For all of them, Microsoft has a more complete feature set...but for 99% of things (and anything with lots of collaboration), I prefer Google Work Suite or whatever it's called this month.
This. I'm a huge fan sheets and built a bookmarking extension on it because it's free, portable, private, etc etc. https://chromewebstore.google.com/detail/quotebook/mcbjgbahg...
My very first programming job was with Quattro Pro spreadsheet. It was a great introduction for someone who was self-taught and pre-internet.
I note that this blog isn't a Google Sheet.
You're right, though it definitely fits into the ethos of don't overcomplicate things.
https://github.com/HermanMartinus/bearblog/
I used to work in a really big bank. One of our primary responsibility is to "convert" trade algorithm from spreadsheet to an actual production program/code. The usability of spreadsheet to show a concept quickly is great. But it is a nightmare to have to understand and debug during the conversion.
My new discovered superpower for Google sheet is using Gemini, not the integrated functionality, but using Gemini to spit out some very specific use case into app script which I plug into my sheet. Majority of the time the code works without any issue on first try with Gemini Pro.
2000's: I use Excel for everything
2010's: I use Google Sheets for everything
2020's: I use Etherpad[0] for everything
[0] Or any other alternative for that matter
Real 2020's: I use TikTok/Instagram/YouTube for everything
I use LLMs for everything.
+1
It’s amazing to me how well Fred Brooks’ insights from 50 years ago hold up (plan to throw one away, in this case).
Funny, I recently departed from the google ecosystem to proton, self hosted nextcloud, kagi, Libreoffice, and Apple Maps. Am I giving up some ease of use? Absolutely! Can I live with it? Absolutely! Can google go fuck itself? Hell yea. Libre office is like missing a limb, but with practice it can do anything I want it to.
Google, Excel, Numbers, LibreOffice, close enough as makes no difference for what the vast majority of people do with spreadsheets. And even for more complex use cases, any of them will most likely be fine. Google probably has the edge if you need real-time sharing with multiple people.
You have self-hosted Kagi? How?
Does Google Sheet allow fine grained filtering like "allow customers to see only their own requests" or "allow submissions to be edited within 1 hour"?
I was the internal tools PM that looked at the portfolio of products and asked, "Why aren't all of these just Google Sheets?"
Pivoted out of there lol
It’s embarrassing. Back when Zillow was trying to be a real estate broker, they had a pipeline for salespeople to track the progress of flipped houses. I was brought in with oh maybe 50 other devs to code the more extensible replacement.
The existing workflow was all down in google sheets, and it scaled to at least 10 states. There were growing pains, sure, but it seems like a monumental waste to spend an hundred years of dev effort replacing an existing working system that cost the price of a Google enterprise installation.
I often wished for a Google Sheets like service that had an easier to use API and a bit more control over the schema. A cross between sheets and a headless CMS.
>"I entered the workforce about 9 months ago"
This sentence made me feel like I was reading a young Gen-Z kid's tech complaint at a small company.
Reminder that anything you put into Google for storage is you voluntarily disclosing such information to the United States federal government without a warrant requirement.
Due to both the third party doctrine as well as FAA702, the feds do not require warrants to access, copy, process, and store indefinitely all information you provide to Google.
Good luck!
Works as long as you don’t have to ask ”which Google sheet” if you just have one sheet for a particular problem you are not in a world of hurt.
this is what got me excited about NOtion in the early days - they nailed that notion ( he he ) about just providing a nice view for databases, which you can design yourself
and of course Google sheets with its synchronous use model is doing the same
2015: This meeting could have been an email 2025: This enterprise development project could have been a spreadsheet
‘Why’ was apparently a too long of a word to include into the censored title.
LLMs making Google Sheet webapps expediently is killer feature.
I sure hope the author also uses Google Takeout regularly.
> "I spent 2 months designing and making an admin panel "
Why? It's easy and quick to code complicated things these days. It's nice having custom dashboards and functionality that fits exactly with what you need. Way more professional.
I'm sure Google Sheets are fine. But I've been seen truly ugly Google Sheets with way too many tabs and horizontal scrolling. Clunky cells that seem to expand and have their own scrolling universe with different laws to everything else. Why can't I simply click the cell to copy it all, nope, let's try double-clicking the cell, I just want to grab the contents to the clipboard, nope. Now it expands and I'm scrolling the whole sheet and have lost my place because Google Sheets tries to snap to rows or something. Damn I hate this memory of navigating someone's horrible Google sheet.
This is honestly one of the things I really like about Notion Databases, at the core they are an online collaborative spreadsheet. But then it can also be given multiple views and different forms such as a calendar, Kanban board, timeline, image gallery, etc., wish more apps would allow something like this, e.g. Obsidian Bases are a great first step.
See also: Do the simplest thing that could possibly work
https://www.seangoedecke.com/the-simplest-thing-that-could-p...
use bash scripts unless it's absolutely neccessary to not.
I am amazed how many people just upload everything to Google without a second thought
Related: How Levels.fyi scaled to millions of users with Google Sheets as a backend
https://www.levels.fyi/blog/scaling-to-millions-with-google-...
using spreadsheet to prototype thing == good idea
I don't.
for when not to use a spreadsheet, see https://news.ycombinator.com/item?id=34968457 tl;dr when it involves automated processes
[dead]
[dead]
I haven't used Google sheets for maybe 2 years, didn't have the need, but week ago I needed to send customer a table that will be updated every couple of days. I was surprised how slow it is. Table has 40 lines and 8 columns, static text only, and it takes 12s until I can edit it. For what it is (adding sentence every 3 day) it's ok but if I had to actually use it for myself on a daily basis it would drive me mad.
I run my household budgetting off google sheets - a clean load of 8 sheets, wth 20-200 rows and 20-50 columns including some simple cross-sheet formulas is fully loaded and interactive in less than 2 seconds. My work's sharepoint based Excel roadmap doc is 40 rows of 8 columns and takes about 15 seconds from clicking the link to actually being readable, for comparison.
It should be lightning fast for what you're describing.
All I can guess is you have some browser extension interfering? Maybe one that is blocking certain calls Google uses and the sheet doesn't load until they time out?
If you're running an adblocker or blocking trackers or anything like that, try disabling those to see if that makes a difference. Otherwise check the network tab of the dev console to see what seems to be slow.
I use it daily and have never had this problem.
I manage all the information for every parcel in my city in Google Sheets. It is > 29k rows x dozens of columns and it is instantly interactive when I visit the bookmarked URL.
Do you work for local government? I’ve heard of cities using Excel for this but not Sheets (although I’m not surprised).
ya there is no way this isn't some local issue for something that small to take 12 seconds. my last job i force updated sheets with thousands of rows every 5 mins and it would just be like a quick 1 second blink to totally clear and replace all those rows with fresh data.
Definitely something more going on, like some deeply nested functions.