8 ms·

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-de

• bluGill 1y ago
  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!)
  • Cthulhu_ 1y ago
    Wasn't Microsoft Access basically that? There's also Google's AppSheet, which may be that too.
    • yomismoaqui 1y ago
      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..
      • IAmBroom 1y ago
        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.
    • sroerick 1y ago
      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
      • breadwinner 1y ago
        Here's a modern Microsoft Access: https://visualdb.com/ https://visualdb.com/ Or try Airtable.
    • jasode 1y ago
      >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.
      • jfengel 1y ago
        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.
      • breadwinner 1y ago
        Have you tried Airtable? It works like a spreadsheet but is a database underneath.
      • fsckboy 1y ago
        >>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
        • zevon 1y ago
          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.
        • mjrpes 1y ago
  • breadwinner 1y ago
    > I wish there was a better way to make spreadsheets use a database as a backend. Here you go: https://visualdb.com/ https://visualdb.com/
  • password4321 1y ago
    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.
• Zigurd 1y ago
  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.
  • Romario77 1y ago
    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.
    • conductr 1y ago
      > 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.
    • Zigurd 1y ago
      Google Workspace apps all (?) have versioning.
      • curioussquirrel 1y ago
        This is true, but sadly for very large spreadsheets, it kind of stops working at a certain point. You get timeouts when loading cell history or the version of the spreadsheet version history.
• dotancohen 1y ago
  > especially so for people who can't code. Presumably those people learned to use a spreadsheet. What makes learning spreadsheet formulae possible, but SQL, Python, or R impossible?
  • imgabe 1y ago
    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.
  • jeffbee 1y ago
    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.
  • compiler-guy 1y ago
    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.
    • breadwinner 1y ago
      That's not true, you can use Airtable to get the ease of use of a spreadsheet with the robustness of a database.
      • compiler-guy 1y ago
        And now you have two problems. It’s not just SQL that you have to learn, but airtable. Which probably isn’t installed anywhere.
• imgabe 1y ago
  I agree spreadsheets are amazing, but they are not databases. Much grief has been caused by trying to make them be one.
  • breadwinner 1y ago
    Have you not heard of spreadsheet-database hybrids? Like Airtable? Or if you want to use Postgres: https://visualdb.com https://visualdb.com
  • bonoboTP 1y ago
    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.
  • themadturk 1y ago
    And yet...they are often used as databases, successfully.
• hannofcart 1y ago
  > 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.
  • cousin_it 1y ago
    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.
    • IAmBroom 1y ago
      > 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.
      • DonHopkins 1y ago
• ubermonkey 1y ago
  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.
  • themadturk 1y ago
    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.
• thesuitonym 1y ago
  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.
  • jader201 1y ago
    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.
    • mebizzle 1y ago
      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.
    • abruzzi 1y ago
      > 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.)
      • jacobr1 1y ago
        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.
• slightwinder 1y ago
  > 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.
• thm 1y ago
  And not to forget, you can run Doom and Tetris in them.
  • IAmBroom 1y ago
    In both GS and XL, actually. Excel used to have its own video game as an Easter egg.
• velcrovan 1y ago
  > 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.
  • piltdownman 1y ago
    Data > Protect sheets and ranges, choose Protect range or Protect sheet, and then click Set permissions to customize who can edit them. What Problem?
    • dahcryn 1y ago
      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
      • velcrovan 1y ago
        MS approach is the same these days actually, people even complain about it.
      • okanat 1y ago
        When was last time you used Onedrive or Sharepoint connected Excel? That's also how it works nowadays.
    • velcrovan 1y ago
      I am anal about doing this at the range level, but few people are.
• Scubabear68 1y ago
  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!
  • TeMPOraL 1y ago
    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 :).
• Ajedi32 1y ago
  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).
  • breadwinner 1y ago
    > 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/ https://visualdb.com/
    • 1-more 1y ago
      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.
  • cassepipe 1y ago
    Btw, anyone ever used Mathesar ? I saw it on the hn frontpage but I haven't tried it yet
• freehorse 1y ago
  > 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.
  • Zigurd 1y ago
    Having worked on Lotus Notes, I am acutely aware that groupware wasn't the answer either.
  • dkarl 1y ago
    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.
• oaktowner 1y ago
  >>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.
• deleted 1y ago
  [deleted]
  • deleted 1y ago
    [deleted]
• fsckboy 1y ago
  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
• CrulesAll 1y ago
  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.
  • bonoboTP 1y ago
    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.
• supportengineer 1y ago
  >> especially so for people who can't code Minor point, but I would say that people who can construct formulas, are indeed coding.
• Schiphol 1y ago
  > RIP HyperCard, may you be never forgotten. There's Decker https://beyondloom.com/decker/ https://beyondloom.com/decker/
• alexdoesstuff 1y ago
  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.
• Lu2025 1y ago
  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.
• ChuckMcM 1y ago
  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.
• hahajk 1y ago
  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 https://github.com/gristlabs/grist-core
  • dugite-code 1y ago
    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