The future is tensors ;)
Show HN: We built the fastest spreadsheet
121–130 of 225 posts
Re: Show HN: We built the fastest spreadsheet
#122Founder/CEO here. When I worked in AWS S3, I spent a lot of time in Excel. Even as a dev, it was the fastest way to explore data, build models, and share forecasts with business partners. My Excel usage was plagued by slow performance, poor cloud integration, and no first-class Python support. I loved the richness and responsiveness of Excel, but I had to give up too much power to get it. This felt like a false choic…
Re: Show HN: We built the fastest spreadsheet
#123As someone who used to work on Excel, awesome work and congrats on the launch! I get that it's easy to bash on VBA, but I'd argue it's what made Excel what it is today (though maybe not the language/runtime per se, but rather the ergonomics). I feel pretty confident saying that probably 5% of the world's economy runs on VBA macros that were started by some eager worker that was tired of doing repetitive tasks and won…
I never understood two of Microsoft's owngoals:
1) The lack of a migration path from workgroup (LAN) to client-server for Access et al. So dumb. SQL Server should have become a first class citizen of Access. Or Access become a viable front-end end to SQL Server. Where swapping JET and MSSQL was a drop-in no-brainer. (Maybe that happened later...)
2) Not unifying tabular data. And then make Excel and Access "modalities" (?) for accessing that data. Lotus' Symphony (successor to 1-2-3) was so awesome; hybrid database and spreadsheet. aka The Correct Answer™. And Symphony was on DOS! (Lotus' Improv was even cooler. I wish I knew why it didn't succeed.)
I guess all this ML data pipeline Parquet NumPy stuff finally separated tabular data from how it's used. Yay.
I haven't used the Microsoft stack in anger since late '90s, when Java emerged, so maybe the .Net/CLR reboot mooted my complaints.
I never had the chance to use Borland's tools (Paradox, QuattroPro) in anger, so don't know if they did any better.
Re: Show HN: We built the fastest spreadsheet
#124Earlier quoted context omitted.
Nice work, did you start off by looking at any previously built canvas-like spreadsheets or was it straight to "virtualized custom canvas magic"? I interviewed at a spreadsheet company (for a frontend role) and they asked, "how would you go about determining what cells need a border when a user clicks an individual cell, clicks a cell and selects multiple cells, clicks a cell next to an already selected cell." Fascin…
Row Zero frontend dev here -- when architecting, we looked at some off-the-shelf canvas-based table tools, but ultimately rolled our engine for more control & flexibility with our growing feature set. We elected for canvas over DOM for perf among other reasons (eg DOM scrollbar virtualization is hard when MAX_ROW * ROW_HEIGHT exceeds the maximum allowed browser element height). Great interview question. Tons of nuanc…
Re: Show HN: We built the fastest spreadsheet
#125Founder/CEO here. When I worked in AWS S3, I spent a lot of time in Excel. Even as a dev, it was the fastest way to explore data, build models, and share forecasts with business partners. My Excel usage was plagued by slow performance, poor cloud integration, and no first-class Python support. I loved the richness and responsiveness of Excel, but I had to give up too much power to get it. This felt like a false choic…
This looks like something that I could use right away, but I wonder, since we can write Python, does this mean that we can write back to one of the native backends (e.g. Postgres)? Currently, the only way to do this from Excel (e.g. saving a snapshot of an analyst's current dashboard that they just built) is through a macro, which then starts the (understandable) descent into Excel's External Content and Trust Center…
We have gotten a lot of requests for write-back-to-DB (Snowflake, Postgres, etc) so will be adding first-class support for this feature soon that will use the same connection creds which are stored encrypted in KMS and are not viewable to people you share the workbook with.
Would love to chat about your use-case if you want to reach out to us at contact[at]rowzero.io
Re: Show HN: We built the fastest spreadsheet
#126Earlier quoted context omitted.
> files are consistent and application-independent I see diverse, inhomogenous state schemas that are deeply coupled to the originating application (internal data structures serialized to disk!) and have arbitrary legacy structural constraints ("document") as well as seams between application silos
You’re talking about the file contents, not about files as objects. Regarding the file contents, how is that different when the data is proprietarily stored in hidden SaaS databases?
Re: Show HN: We built the fastest spreadsheet
#127Hello all, I'm Grant, founding engineer at Row Zero. Working on this spreadsheet engine has been one of the most exciting, complex, and stimulating engineering experiences of my career. Feel free to ask any technical questions about the product. We're really proud of what we've build and what's on the roadmap!
Do you support the equivalent of Excel's Iterative calculations?
Re: Show HN: We built the fastest spreadsheet
#128Never understood spreadsheets. Why would you assume data fits in a 2d-array? And why put heterogenous data in that 2d-array in blocks at different x,y offsets? The future is tensors ;)
Re: Show HN: We built the fastest spreadsheet
#129Interesting concept. Are you planning on offering an interactive embedding alternative (add the spreadsheet to an existing app) soon?
Re: Show HN: We built the fastest spreadsheet
#130Is there a way to push data into it, rather than have it pull data from data sources? I have some use cases where users want <3s latency from source data updates to the display being refreshed. For reference, I managed to get to ~10s using Google Sheets' API.