Hacker News new | past | comments | ask | show | jobs | submit login
Luckysheet, an open-source spreadsheet (github.com)
276 points by tzm 8 days ago | hide | past | favorite | 119 comments





I will keep saying this every single time some one gets this wrong (which is at least 49 times out of 50): the only way to handle scrolling properly on the web is for your scroll events to fall onto a real scrollable area, and to observe the effect it has (e.g. apply the scroll position to what you’re rendering with). This can be tricky to achieve well when you have dynamic content that the mouse needs to be able to interact with within that area, but it is possible to do well, with careful application of `position: sticky` and/or `position: fixed`.

As it stands, scrolling is nigh unusable on my Surface Book: vertical scrolling goes at a million times the speed it should, and horizontal scrolling goes a million times as fast as it should in the wrong direction.

Don’t do scrolljacking. It’s bad, every single time. With the tools the web gives you it’s not possible to get it completely right that way.


Absolutely. In the development process of our product DataGridXL we've also experimented a lot with "scrollwheel" events and such, for months really. It's just not possible to get it to feel natural. You might be able to get it working nicely on one specific OS+browser combo, but that's about it.

Always listen to the native "scroll" event: https://www.datagridxl.com/demos/one-million-cells


One deficiency of using the native scrollbars visually here is that the arrows at the end of the scroll bars on some platforms (e.g. Windows, most Linux) will scroll by a predetermined number of pixels, more or less, whereas in such an application you would probably prefer it to scroll one column horizontally or one row (though maybe more than one) vertically. Of course, placing your own scrollbar visuals is a hazard too, most significantly because it doesn’t look native and may offer different functionality from the normal scrollbar. You can’t win, the web doesn’t give you the tools you need to get the experience perfect.

But yeah, your example in DataGridXL is a good example of the right approach to take for this if you want scrolling to be done in steps as is conventional in spreadsheets.


> whereas in such an application you would probably prefer it to scroll one column horizontally or one row (though maybe more than one) vertically.

But isn't this exactly what element.scrollIntoView() is supposed to be for?

Native scrollbars, styled with scrollbar-width and textareas resizing with cols attribute is pretty straight forward if you do the box-sizing right.


I think you’re misunderstanding. I’m saying that on platforms where the native scrollbar has arrows that you can click to scroll by a small amount in the nominated direction, you might prefer clicking on those arrows to do something different—to scroll one row or one column, whatever distance may be, rather than however many pixels the user agent decides. But you can’t do that on the web.

element.scrollIntoView() is completely unrelated to this.


Ah gotcha, yes you are indeed correct. Something like custom amount of lines to scroll isn't possible afaik.

I was just stating that with scrollIntoView and the element's scroll-snap-align and scroll-padding/scroll-margin CSS properties you could set the wanted offsets and alignments of the scrollbar and define what you were argueing about.

But of course, you cannot influence the behaviour of the scrollbar arrows themselves.

[1] https://developer.mozilla.org/en-US/docs/Web/CSS/scroll-snap...


Ah, CSS scroll snapping. Refer to my other comment in this thread about that, I strongly recommend against using it for layout matters like this, it messes with the scrolling behaviour (especially on devices with precise-scrolling touchpads and inertia) something fierce; it’s quite unavoidably every bit as bad as doing the scrolljacking in JS.

You know your stuff, I can tell! In a pre-release version, we had hidden the native scrollbar and put our own scrollbar graphic on it that would animate using CSS transform according to native scroll offsets vs. DGXL viewport dimensions. The scrollbar size (width/height) and position made more sense, but at the end we couldn't get it to feel quite right.

We're quite happy with the native scrollbar. It's fine on mobile too.


Yep, I think native scrollbars is reasonable for DGXL. Maybe eventually you’ll sniff whether scrollbars take space and draw your own that match the size if they do, but it’s definitely a little risky.

These sorts of things are particularly interesting once you support a sparse spreadsheet; drawing your own scrollbars becomes much more compelling then, so that you can make them more useful. No idea about Excel, but LibreOffice Calc—(which amusingly gets scrolling by precise touchpad wrong in just the same way as Luckysheet, sans the wrong horizontal direction; this stuff is hard everywhere)—well, LibreOffice Calc’s scrollbars essentially pretend the whole time that the document is only as large as the extent of the cells with content or the selection, whichever is larger in each axis, plus a screenful or so in each axis. So if you’re at A1 of an empty document, the scrollbars thumbs fill about half of the bar, but if you’re at AMJ1048576 (maximum sheet dimensions are 2¹⁰×2²⁰), the thumbs are tiny at the bottom and right.


Sounds like a very strange approach, those LibreOffice Calc scrollbars ;-) Sometimes it's useful to give a minimal width/height for a scrollbar thumb, so that it remains visible and selectable. A tiny scrollbar thumb might be "realistic" when it represent the viewport vs document dimension, but it always looks a bit stupid.

How come you know so much about scroll bars? Did you make your own spreadsheet app/component?


The spreadsheet approach makes a lot of sense: they’re dealing with what’s practically a near-infinite document (a million cells is close enough to infinity in such cases!), but people seldom actually use that many cells. Thus, the shenanigans they pull are to make the scrollbars useful, so that they typically give a fair reflection of the actual size of the document the user is dealing with. I imagine Excel does something similar.

I know so much mostly just because I observe carefully, in both desktop and web software. I haven’t implemented anything like this, but when I observe things imperfect on the web and it’s a type of imperfection I’m not familiar with, I often assess it to figure out whether it’s possible to get right. I also value getting things right in straight HTML/CSS with no JavaScript.


Your implementation is pretty neat.

We recently kind of went down the path of our own scroll bar in one of our app forms because users wanted the scroll to behave in a very specific way. It was impossible to make it work as expected in all the OS and browsers. We eventually rolled back the change, restored the native scroll bar and instead provided a big optional floating scroll button in the bottom corner of the app which user can choose to use to scroll the way they expected to. Kept everyone happy.


Thanks, we really wanted to get the scrolling right so I'm glad it shows.

> We eventually rolled back the change, restored the native scroll bar

Doesn't it feel good to remove a bunch of "hacky code" and just go back to native? Even if it's not 100% like you imagined, at least you know that the other "perfect solution" never really existed.


The way I solved this in my own (not finished) web-based spreadsheet app is to have a scrollable div positioned over the canvas and to size the transparent div contents to the width/height of the sheet. Then I register scroll event handlers and redraw the canvas appropriately when the scroll changes. I think this is how Google sheets works, although it's a bit difficult to tell for sure.

It behaves exactly how you would expect. It even properly handles clicking and dragging to the edge of the screen, which I did not expect prior to implementing it.


It seems difficult for a canvas-based spreadsheet to do native scrolling. The DOM is drawn in advance and there is no cost to scroll. But canvas is different, every frame of scrolling means calculation. In this case, the use of native scrolling will cause jamming and poor experience.

With infinite scrolling, you can also just set the container to be absolutely huge, and use the scroll position to index. This works especially well for computed layouts like tables, where culling rows and columns is a simple scan over run lengths of row and column sizes.

Likewise if you know things will be inserted at the top of a scroll view, you can pre-allocate above the “top”.

The one thing that is hard to do well (but less hard now with new CSS features I think) is scrolling that feels good but always ends with the border of a cell being aligned to an edge of the scroll view (the Excel behaviour).


CSS Scroll Snapping may have a place for image gallery sorts of widgets, but for broader layout matters I strongly recommend against it: it can work tolerably on mobile (though it’s not without problems), but on desktop it seriously messes with scrolling so that on many devices it’s almost entirely problems.

(That’s what I said at https://news.ycombinator.com/item?id=23915285 which was dealing with much the same area.)

Instead, you’ll want to implement such snapping with absolute snapping as seen with robbiejs’s example.


Do you happen to have some links to resources I could read a bit more about it?

There are some intricacies about when to reset the scroll position, if ever.

Here's one way: https://codepen.io/xorgy/pen/yYdVoY


This way is very, very wrong in how it resets the scroll position: it essentially assumes synchronous scrolling, and falls apart completely if that isn’t the case—and it hasn’t been for some years.

By “synchronous scrolling” I mean that reading scrollTop gets you the true current value, and that setting scrollTop sets the value immediately. These used to be the case, but scrolling is handled off-thread now, so the values you read may not be the actual values, and your setting the value may clobber scrolling that has taken place since your code started being called. (This also means that any fake scrolling you do will lag behind reality—one of the reasons to use fully native scrolling if you possibly can. This has been unavoidable since asynchronous scrolling came in.)

The effect is that on devices with precise scrolling and inertia especially, it will make scrolling extremely slow, because essentially most of the scrolling delta is being lost. I see this problem very commonly in systems that have tried to implement their own scrolling. For reference, I’m using Firefox on a Surface Book. A generous two-finger swipe that should scroll by several thousand pixels is in your demo (when further instrumented to keep totals of deltas) only perceiving several dozen pixels of delta.

In short: you mustn’t ever reset the scroll position.


On Chrome based browsers on Android at least, it works perfectly fine with momentum. It even does accumulating momentum, I can easily get it up to 6,000px/frame.

Does this not work properly on iOS?


Although in theory the problem is universal, in practice the problem only appears when the user is using touchpad-based scrolling; touch-based scrolling is typically unaffected.

But it’s all happening because you’re interacting with the scroll position in a way that is incorrect within the models of the platform, reading and writing the scroll position as though it were atomic and sequentially consistent when it’s not, so it could break in more situations at any time. It’s thus much better to avoid the technique and work in a way that is supported.

(I’ve decided to change the terms I’m using from synchrony to atomicity. For users familiar with that domain: the problem is essentially equivalent to the scroll position being atomics that are changed from another thread, but you’re doing a load and a store, probably with relaxed sequential consistency, rather than using an atomic swap operation, or a mutex lock over a non-atomic. There is no recourse while using this technique because the scroll position is not exposed as an atomic or something lockable.)


I still cannot wrap my head around why so many folks want to use such applications in a web browser.

For me, web browser applications never reach the responsiveness and ease of use of well crafted desktop applications written in any decent systems programming language or even interpreted languages (not speaking of Javascript). Maybe I am getting old, but having the browser as a platform for programs is huge setback for many criteria that I personally value.

For example, as a free Excel alternative, I fall back to Gnumeric (http://www.gnumeric.org/) from time to time.


Sharing and collaborative editing. Being able to coordinate some process via a shared spreadsheet in a browser is efficient and resolves all issues of conflicting versions. Think of an overview of who is going to the office on which days this week (useful in times of working from home due to Corona).

Responsiveness is not the primary concern here: good enough is fine for most purposes.

This is not a replacement for a proper spreadsheet editor (I prefer LibreOffice myself); it's a tool to collaborate on tabular data with a group of people and minimal overhead.


Interesting to note that cloud storage and realtime collaboration isn’t 100% tied to a browser-based interface though. Even though many existing apps work like that, there are desktop clients for a bunch of cloud-native SaaS (and even though some of those are Electron).

Regular desktop Excel supports multi user collaboration on workbooks saved in onedrive exactly the same as excel online/Google sheets etc do. You can see what other users are working on and their changes are synced instantly. The only annoyance is when one user changes a filter and it changes for everyone.

> resolves all issues of conflicting versions.

But isn't a problem in the browser, because you are always on the same version.


Using HTMl & CSS for your GUI is orthogonal with collaboration. It's just a hack that people accept

No installation

Multiple tabs/windows

Don't leave the browser

Works-at-all on multiple platforms incl mobile

Deep linking / sharing / bookmarking

App freezes are less common (on network access) and easier to manage when they happen - obviously this is anecdotal and not universal.


Registration/Login required(I'll take the installation over that in many cases)

No properly working (or even implemented) keyboard shortcuts; I just tried, Google Sheets tells me to use Ctrl+C etc. but it doesn't do anything, and what's even worse is that the menu item for "insert" doesn't do anything either because Google wants to force me to use the dysfunctional keybinding...thanks I guess

Usually no right click + context menu

Input lag

No offline use possible(remember all the MS/Cloudflare/AWS etc. outages?)

Less control over data, privacy issues


I understand the sentiment, but some of your points are simply not true. Ctrl+C works fine last time I tested GDocs (inc sheets). It also have offline support, and supports right clicking? Input lag is very dependant on the actual application and how it's made AFAIK, albeit it might be more difficult to do it right using web tech. That leaves two arguments (basically privacy arguments). That is not it related to web tech. For example, Adobe CC more or less requires the same login and authentication requirements as other web applications. Some web applications does not require login (pixlr for example). Many desktop applications phone home as well and gather even more information about you and your computer.

Web tech is not the problem in itself - it's how it's used and deployed that can be a problem (like the ads/data "freemium" business model some use BFF which a _few_ users dislike).

I thought we were better than arguing with false arguments and pointing fingers at the wrong problem - well, I guess "hoped" (in a naive sense) is actually more accurate...


> Ctrl+C works fine last time I tested GDocs

Well, it didn't work when I wrote my comment, sorry that it seems to be inconsistent on my setup. Regardless it is still very questionable of Google to make the "insert" menu item do absolutely nothing but show a popup dialogue telling you to use Ctrl-V. It is annoying and comes across as a bit condescending, like some engineer at Google wanted to teach the noobs how it's done properly.

> It also have offline support, and supports right clicking?

I was talking about web apps in general, not just Google. Many web apps don't have any context menu or shortcuts, you have to move the mouse back and forth all the time for the simplest steps.

And what's even worse is that many JS-loaded websites mess with the UI so much that you can't open links in new tabs anymore. I don't even want to know how that can be done unintentionally.

> Adobe CC more or less requires the same login and authentication requirements as other web applications.

You are right there, maybe I conflated the web app trend with the rising amount of user-unfriendly software design.


The insert menu tells you to use the shortcut because browser restrictions make accessing/modifying the clipboard without doing so difficult.

To be fair, Google apps are extreme outliers in SaaS, especially offline support.

It's an open source tool that you can self host, having none of the problems, or add to your application and when you're doing that, all of what you said already applies.

But yeah, I get why you prefer native programs - I do as well. But the web ones have their place too.

Btw context menu is in google sheets for a long time - I wanted to say a decade, but it might be a little less.


> use Ctrl+C etc. but it doesn't do anything

Did you set clipboard events to false in about:config?

Probably. After all, if you don't set that, lots of sites will do stupid things like prevent you from copying, or pasting into certain fields.

But it will break things like Google Sheets.


More importantly (for Google sheets):

Easy to share

No need to backup

Cross platform (works on Linux)


> No need to backup

You trust Google etc. to never ban your account for any reason, or to stay available 100% of the time without outages?


And Google uses some badly tuned and not understandable by humans, and also constantly changing, machine learning algorithm to decide to serve you or not.

When something goes wrong with this, you have a a fairly small chance that you can reach a human to override, but it will be an overworked underpaid contractor somewhere and your chances will be poor.

If you talk long term (decades), it is quite possible that Google falls out of favor and becomes legacy, like Myspace, with not making that much money anymore. We all know what happened to the Myspace data, they just deleted most of it at some point.

Essentially it's a lottery with your data.

Now a badly maintained hard disk is a data lottery too, but it's not clear to me the chances to retain are that much worse than Google's.


I think it's foolish to shoot down advantages in practicality and fluency of use on the basis of a decades long event for the vast vast majority of use cases. My company hasn't been around for decades and we don't use any particular spreadsheet outside of a select few for more than a couple months at a time. You'd lose all credibility arguing against G-suite on the basis of losing your data/getting your enterprise google account banned, because it would cost the business so much time and confusion relative to the ease of cloud solution.

I've already had disks fail, never had an issue with Google Docs being down, and if it happens I think it will have been worth it.


You trust your hard drive to never fail during crunch time, or Jane Doe in accounting to not lose the flash drive that gets shared around the office every quarter?

I'd take "generally highly available" vs "trusting my local copy" almost all the time. And as for using something like a Git'd Excel document: most people won't do that, and Github can go down, too.

Just because Google Drive isn't perfect, doesn't mean it's not better/easier/more user friendly than what has been the standard for years.


You need to back up your hard drive too.

The point is that you always need to back up. Sure, if you pay Google you can probably rely on them. But it is still best to backup anyways.


It's not an either-or. My argument was for making backups, not cloud vs. local storage.

> Don't leave the browser

For someone saying that they don't like browser-based apps, how is this an advantage? They're presumably not in a browser in the first place.


Just before I even start,I want to mention that I'm a fan of MS Office and don't really like Google Sheets ( it's like a toy to me). Having written this,I still do believe that there are millions of people out there for whom browser based spreadsheet application is all they really need. Those aren't people doing tens of thousands of rows manipulations from database extracts.Those are the people who'd have a simple file and do simple things with it. I see a lot of consultants working with it: they create UAT stories,share with multiple users on the client side and everybody knows what's going on.

Because you never use the same desktop, I myself can use up to 10 different devices, it is always easier to access stuff from a webbrowser.

I do agree that the snappiness of Gnumeric is wonderful, and it's easier to do on desktop, nevertheless many desktop apps are worse than web apps.


Available everywhere without installing anything, and I don't need to worry about file formats. With Google Drive I also appreciate that I can write custom functions using javascript which I already know, rather than learn some obscure language.

I tried gnumeric just now and the crappy looking toolbar and the poor autocomplete experience for formula functions was enough to put me off.


> For example, as a free Excel alternative, I fall back to Gnumeric (http://www.gnumeric.org/) from time to time.

Gnumeric is useful, but its GUI is very laggy (more laggy than LibreOffice Calc). Sadly, there NO fast & usable Qt-based alternative to Excell for Linux yet.

As lightweight spreadsheet app for Linux I use Qt-based mtCellEdit[0], which does not support .xls/.xlsx formats & could not fully replace Excell too.

[0] https://github.com/matyler/mtCellEdit



Is there Qt-only (KDE-free) version of Calligra Sheets?

The browser is very accessible and understandable as an environment as compared to different kinds of desktop environments that exist. Sometimes having an imperfect thing which exists is better than a non-existent perfect thing. Sure, a web application will never be as snappier as a native application, but it can be built, deployed and maintained by a much smaller team than what would be required for supporting desktop applications for multiple environments. If it feels 'good enough' to the users, they won't care.

>Sure, a web application will never be as snappier as a native application, but it can be built, deployed and maintained by a much smaller team than what would be required for supporting desktop applications for multiple environments.

A webapp has a wide range of operational costs that a native app doesn't. I can't see why a modern webapp would be cheaper to develop as well with similar programming languages. Their advantage comes mainly from the lack of the need to install software, and for the data to be accessible by every device.


I am a big fan and user of keyboard shortcuts, and web apps make using those either weird and inconsistent with what you'd expect, or simply impossible. A user interface without support for keyboard shortcuts is not viable for productive use imho.

Web apps built with modern frameworks often can't even be used by Vim plugins in the browser, either because scrolling doesn't work, or the frameworks and scripts do so much black magic in the background that not a single button in the GUI is recognised as clickable element by the Vim plugin. Broken by design.

Not to mention all the performance issues and productivity blockers thanks to tracking, no support for right click(and its context menus) etc., instead we get animations which also add input lag to everything because it looks fancy.


I think it really depends on the scenario:

# Scenario 1 You are using one device where all your apps are installed or you have permission to install anything you want. You will find this in smaller companies with BYOD policy.

# Scenario 2 You are using a lot of different devices and/or regularly have to work with a new device that is only setup with the basic applications. It is not possible or allowed to just install any app. You will find this in enterprise businesses with a lot of policies about devices and workflows.

For #1 a solid desktop app is probably preferable but for #2 (prerequisite is a stable and fast internet connection) you can start working immediately when all necessary apps and data is available online.

Also there could be web apps that benefit from a spreadsheet which is more than just a basic grid view.


A tabular, instantly updating set of information is one I'm frequently discussing with groups of people online, it is ridiculously handy even with the overhead of a web browser slowing things down, if it's updating live. Of course a secure and easy to set up way to do it without the browser would be great as well.

> well crafted desktop applications written in any decent systems programming language or even interpreted languages (not speaking of Javascript).

These generally cost more money to develop/require ITs permission to be installed/get features slower.


Why would you use interpreted languages but not JavaScript?

Well, like it or not it helps a lot with web first exp. and also with collaboration.

I wish people wouldn't copy Excel (or Google apps for that matter). Those spreadsheets are terrible. It still baffles me that none of them can do sideways scrolling correctly, they are all incredibly awkward to edit, the formulae are fundamental to how they work yet hidden and obscure, they do weird "magical" stuff to strings like turning them into numbers or dates when you didn't ask, etc.

I'd really like to see people explore new paradigms. Something that has the functionality of a spreadsheet but looks nothing like current spreadsheets.


I had the same thought as you and started working on something that can be described as "AirTable meets Webflow". It's basically a no-code database with drag-and-drop page builder: tables are created and linked together (like in AirTable) and interactive pages are designed to work with that data (like in WebFlow). So in other words users don't directly use a spreadsheet-like UI to work with the data. Instead they use custom-designed pages - it is both much more powerful (e.g. fully scriptable, multiple pages can be linked to form more complex workflows, which wouldn't be even possible with spreadsheets) and yet easier to use. Oh, and it's self-hosted. Judging by the response from users it does seem like something like this is really needed.

I put some pretty crude demos online about a year ago [0] ... back then the idea was to create a more general purpose no-code web app builder, but since then I decided to focus specifically on database applications.

[0] https://www.formbeaver.com


When you say 'has the functionality of a spreadsheet but looks nothing like current spreadsheets', what do you mean?

I am working on Mesh Spreadsheet. It gives you a spreadsheet UI that writes code as text. It will likely use k9 as the formula language once it matures, but:

- you can try the JavaScript prototype at this link: http://mesh-spreadsheet.com

- you can see a proof of concept video using k here: https://www.youtube.com/watch?v=CEG9pFNYBCI


That‘s pretty cool.

One reason I prefer Apple Numbers to Excel is that in Numbers you arrange tables on a canvas. The tables can refer to each other. I think it makes it easier to work with, for example, an input table and an output table because they are separate entities and not just different ranges on the same grid. It’s similar to how some websites enable you to configure a dashboard view of multiple tables and charts.

Your presentation reminded me of that, specifically the view of how you implemented the tool in itself. But you’re using one large table rather than a collection of tables on a canvas.

I’m wondering if the Numbers approach might work better. In particular it might be more natural for dynamic arrays because they would not “overlay” a range of cells. They would be their own dynamically resizing table on the canvas. This might lead to something like Spreadsheet 2000: https://en.m.wikipedia.org/wiki/Spreadsheet_2000


Thanks! I have been considering this!

It might impact the 'flow' of modelling eg using automatic cell names like 'A1'. And it might complicate storing the sheet as text (might need to store more complex layout info than 'table is at coordinates x,y').

But it could also make layout easier, eg tables underneath each other could have different column widths. Could use CSS flow layout.

I also hadn't heard of Spreadsheet 2000 - great reference, thanks.

BTW - I think of the Mesh spreadsheet as a canvas, just a 'discrete' one as opposed to continuous. In theory, if the grain is fine enough (eg 1 character width of a monospace font), then you might be able to get the best of both discrete and continuous approaches.


Speaking of automatic cell names ‘A1’, the other thing I prefer about Numbers is that you can name columns and use the name in formulas. For example, you might have a table “Sales” with columns “Item”, “Number Sold”, “Item Price”, and “Total”. The formula for all cells in column “Total” is

=‘Item Price’ * ‘Num Sold’

Instead of =B1C1, =B2C2, etc. You’re doing something similar with the name cell, but with separate tables you can designate column headers and row headers, and use them to reference cells. For example, in another table you might say: =SUM(‘Sales :: Total’) to sum up column “Total” in table “Sales”.

(I might be getting the syntax wrong here, you don’t type this in, you “option-click” on the cell you want to reference and it inserts the reference.)

This is optional, you can still do A1, B4, etc and sometimes that’s what you get when you use the same name for two columns in order to disambiguate. But in general it makes it easier validate your spreadsheet, I think.

I believe the approach to naming goes back to Lotus Improv: https://en.m.wikipedia.org/wiki/Lotus_Improv

I think Quantrix Modeler is also based on the ideas of Improv.

Come to think of it, there was Javelin in the 1980, that you might find interesting. It’s not a spreadsheet but it was used for financial modeling and time series: https://en.m.wikipedia.org/wiki/Javelin_Software

But those are quite far departures and might not be where you want to go. I just wanted to point them out in case you hadn’t heard of them. (I’ve only heard of them but I have never used them, so I cannot say how good or bad they worked in daily life.)


> you can name columns and use the name in formulas

You can do that in Excel too: whether it's the whole column of a sheet, or a column of a table - syntax for latter is `someTable[someColumnName]`. Mesh will have the latter, albeit with different syntax.

Thank you for the links! I will have a look. There's a deep history.


I didn’t know Excel supported that too. Nice. I should have guessed, it does a lot of things.

The problem is exactly that I don't know what I mean. That's why I think yet another Excel clone - whether it's free or works on the web or not - is not interesting.

Your talk was interesting, thanks.


Hi, what's K9? My Google searches in combination with "formula and/or language" gave me only dog related results.

I believe he is talking about: https://shakti.com/ which confusingly is a version(?) of K https://aplwiki.com/wiki/K hence K9.

Yes, that's it.

> It still baffles me that none of them can do sideways scrolling correctly

Ironically the original version of Google Sheets could do sideways scrolling correctly. At some point (maybe around 2010?) to be more like Excel.


I rather like the Airtable concept - it feels like a spreadsheet, but the columns are typed, and it can do joins.

It's a shame that it's so limited (50,000 rows in the most expensive plan).


https://baserow.io/ is promising

They really are, i want a self-hosted airtable so bad...

I just found out you can sponsor them: https://github.com/sponsors/bram2w


That looks really interesting. I hadn't run across it yet. Thanks.


I just happened across https://www.calcapp.net/ yesterday while doing research for a project I'm currently working on that requires similar features.

Terrible, but extraordinarily successful.

It looks really nice! But...

The main reason I tend to avoid Google Sheets is that they're slow. Slow to open, slow to update more complex sheets, slow if you have more of them open. In general, much worse overall experience than a desktop spreadsheet, especially if you're using Firefox.

So I was really hoping for something with the snappiness of EtherCalc (which is blazing fast!), just more elegant. I realize it's difficult to have both functionality and speed, so a maybe a system of plugins could be useful. Most of online business sheets I saw use just a few arithmetic functions, many people would be happy with just that.


thanks for this! I never knew something like Ether Calc existed!

There is also Etherpad: https://etherpad.org

Interesting, this suffers from the same issue I have with TeamViewer (and only with teamviewer; this Luckysheet is the first thing outside teamviewer I see this) on mac os x: if I scroll up in a document that has a vertical scrollbar, it will not only scroll up but also to the right. It happens on all the macs in the house, doesn't happen on Linux/Windows... Well, for Teamviewer; I did not test this one on all those machines yet.

The problem does not arise with VNC or any other remote tech or program. I have never figured why it is and it's been there for years across different macs and different OS X versions.


I have the same behavior here (MB Pro 13'', Catalina). But additionally I also experience that the scroll direction left to right is inverted. I have to scroll left so that the spreadsheet scrolls right and vice versa.

Not so top to bottom.


Yes, indeed I have experienced that as well sometimes...

Call me crazy but I would really like a ncurses spreadsheet.

https://github.com/andmarti1424/sc-im

SC-IM - Spreadsheet Calculator Improvised -- An ncurses spreadsheet program for terminal


Check out visidata: https://www.visidata.org/

My first exposure to lotus 123 was what looked like a ncurses interface!

Recently I've become addicted to sc-im, a vi (vim) like spreadsheet. Using this tutorial: http://blog.startaylor.net/2016/08/29/sc/

While I don't do very complex things, in terms of note taking using a spreadsheet, it's excellent.


this is quite impressive. formulas, charts supported out of the box. does it support importing xlsx and exporting to xlsx or pdf?

Keep it up it's a step closer to free me from Google

Seems snappy enough on mobile, but translation of functions seems to be missing, so the formula editor is all in chinese to me. Not sure if that is plugable in runtime. One needs to at least translate src/function/functionlist.js maybe more..

This would all be easier if this was not a Vue app, but rather HTML5 but all in all not that different from how desktop apps are made.


This is not a vue app is it? As far as I can see this classic JavaScript with jquery.

There are English tips for formula in the functionlist.js

This spreadsheet is currently the most comprehensive in open source projects I have seen

I've always been curious about what data structures are used to store spreadsheet data. Are there any online spreadsheets just creating, dropping and altering SQL tables as needed?

This looks like a really great effort, better than other canvas spreadsheets I have seen. Great work!

Interesting idea with an browser based open source spreadsheet.

This is really impressive and all, but we already have a pretty good open source online spreadsheet editor by OnlyOffice and I can't help thinking where we could be if the (I imagine) pretty significant amount of work that went into this was put into improving an existing solution...

Realistically it's not possible to "just" work on something else like that.

The work is very different. The work to make a new product like this is completely different from the work to improve an existing, large, established behemoth of a project that has a large number of users. It's a software lifecycle thing, analogous to the difference between spinning up a mini startup, and working for a settled big company with tens of thousands of co-workers.

Perhaps the big product would be better if everyone worked on it, but you're talking about unpaid authors, doing what they enjoy in their free time, often for fun.

What's the reward to the unpaid author of refining the existing, established, behemoth of a solution?

They aren't going to be able to try out their own big new ideas or do any significant architectural design that way.

They aren't going to be able to take it in a new direction, because the existing tool has a lot of users so can't change that much.

They aren't guaranteed that what they want to work on, or what they want to see as features (maybe to use for themselves) would be accepted upstream.

They aren't going to be able to change anything that existing users depend on really. For example if they wanted to try a different syntax for formulas, or a different editing paradigm.

They aren't likely to end up with something they can point at when asked what they spent all their free time working on. Contributing to such a large project, if they enjoy doing it that's great, but nobody outside a small group of people will associate them personally with their bit of work - unlike an independent project, if that gets a reputation.

They also have no chance of monetising their work later, if that's what they choose to try to do in future. Or more likely, to make a commercial branch.

For some people, that kind of work on an established project like that suits them. But it's completely unsatisfying kind of work for other people. It's not reasonable to pressure them, through oblique criticism, into doing it unpaid if they wouldn't enjoy it.


Large parts of onlyoffice are AGPL (https://github.com/ONLYOFFICE/sdkjs). Luckysheet is MIT

Luckysheet comes with the MIT license.

I can't see why it's an advantage.

Compare the licenses and think again :)

I can't see why more options to choose from is not an advantage.

More options is good for rapid evolution of a new domain. Eventually though, we need collaborative effort to take established ideas to a mature state.

For example, there are a number of fledgling open-source nonlinear video editors (NLEs) -- to name a few in no particular order Kdenlive, Openshot, Olive, OpenMovieEditor, Blender Video Sequence Editor, Shotcut, Cinelerra, and Flowblade. I say this with full respect to the authors and contributors to those projects, we just need ONE open-source NLE that is on par with Final Cut or Premiere Pro.


+1 for the NLE example, as it's one of the biggest problematic areas to me. What even is the difference between Shotcut and OpenShot? Both are 90% of the way to being the perfect everyday video editor, yet they both get destroyed by the first shareware result for "free video editor" when it comes to polish.

But we really can't blame the authors - there's no money in open source user apps and polishing isn't fun to most people. I'd immediately jump on the opportunity to build an NLE from scratch if given the time and financial freedom, but I can't see myself digging though someone else's code and sanding all the rough edges for fun.


A web-based spreadsheet, the code is under the MIT License, seems to have some (/many?) features of the commercial products.

Looks similar to every spreadsheet since Visicalc....

Fair point, updated my comment to give an idea what this is to someone like me who doesn't get right away what this.

  Language                     files          blank        comment           code
  -------------------------------------------------------------------------------
  JavaScript                     142          54627          91825         243672
  CSS                              9            790            238           5908
  HTML                             2             10              1             43
  -------------------------------------------------------------------------------
  SUM:                           153          55427          92064         249623
  -------------------------------------------------------------------------------
without the demoData dir. that's nuts

That seems reasonable for a full-featured spreadsheet. If you think it can be done in 10k with all the features, go for it.

Excel has 30 million lines of code, now that's nuts.

This may not be the most concise possible code base, but there's no way to build something like this with a thin layer of code on top of a browser. I can't imagine any similar level of functionality with a size that's a lower order of magnitude than this.

Maybe there is:

1. Hire Chuck Moore to write a spreadsheet in Forth.

2. Hire Fabrice Bellard to write tiny Forth interpreter in Javascript.

tada.


It's closer to 90k lines of JS if you exclude data and external libs, those directories: data locale demoData expendPlugins/chart plugins

Ah good catch. A little more reasonable for a 1-person project then.

Looks like there's a lot of vendored code in src/expendPlugins/chart—maybe that's the source of some of that?

Chart is MIT license



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: