Luckysheet, an open-source spreadsheet
github.com
github.com
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.
Always listen to the native "scroll" event: https://www.datagridxl.com/demos/one-million-cells
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.
We're quite happy with the native scrollbar. It's fine on mobile too.
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.
> 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.
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.
How come you know so much about scroll bars? Did you make your own spreadsheet app/component?
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.
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.
element.scrollIntoView() is completely unrelated to this.
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...
Here's one way: https://codepen.io/xorgy/pen/yYdVoY
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.
Does this not work properly on iOS?
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.)
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).
(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.
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.
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.
These generally cost more money to develop/require ITs permission to be installed/get features slower.
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.
But isn't a problem in the browser, because you are always on the same version.
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.
I tried gnumeric just now and the crappy looking toolbar and the poor autocomplete experience for formula functions was enough to put me off.
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.
# 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 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.
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.
Easy to share
No need to backup
Cross platform (works on Linux)
You trust Google etc. to never ban your account for any reason, or to stay available 100% of the time without outages?
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.
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.
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'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.
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
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.
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...
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.
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.
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.
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'd really like to see people explore new paradigms. Something that has the functionality of a spreadsheet but looks nothing like current spreadsheets.
It's a shame that it's so limited (50,000 rows in the most expensive plan).
I just found out you can sponsor them: https://github.com/sponsors/bram2w
Ironically the original version of Google Sheets could do sideways scrolling correctly. At some point (maybe around 2010?) to be more like Excel.
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.
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
Your talk was interesting, thanks.
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
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.
=‘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 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.
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.
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.
Not so top to bottom.
SC-IM - Spreadsheet Calculator Improvised -- An ncurses spreadsheet program for terminal
While I don't do very complex things, in terms of note taking using a spreadsheet, it's excellent.
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.
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.
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.
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.
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
-------------------------------------------------------------------------------
1. Hire Chuck Moore to write a spreadsheet in Forth.
2. Hire Fabrice Bellard to write tiny Forth interpreter in Javascript.
tada.