If you like Handsontable, you may also be interested in Sensei Grid[0], a similar, but much simpler data grid component. It doesn't aim to be a spreadsheet/excel alternative, but just a data grid with good usability.
Using windows 10. Tried both Firefox and Chrome (both up to date versions) with same results. Menus don't work. Learn More button doesn't work. I can enter a simple formula such as '=5*10' and get a result, but can't refer to another cell. Can't move to anywhere past row 8.
Not bad, reminds me of the functionality I get by mixing DataTables(1) and Jeditable(2). I might take a look at this and see if I can work it into any of my current projects.
Is it just me, or using jQuery for a complex web app in 2015 looks like, mmm, a bit strange choice?
The author has, of course, done a great job, for we see a working app; this trumps almost any objections. Kudos to the author.
But if you developed a spreadsheet of a similar functionality, would you choose plain jQuery and writing state machines by hand? Or would you be forced to use jQuery because you'd have to use key components based on it?
> Is it just me, or using jQuery for a complex web app in 2015 looks like, mmm, a bit strange choice?
This statement is everything that is wrong with the Javascript craze. It's not even 2015, it's 2016 and the argument for not using jQuery is that it's not trendy.
Since when are we so obsessed with looking trendy and keeping up with fashion? I still see people using php + jQuery to build apps that otherwise would've taken twice the time and twice the amount of bugs that take twice the number of developers.
Tech stack should be chosen based on merit that can only be built through the test of time. This is why I'm against using Node.js to write CRUD apps and why I'm against writing everything from scratch because it's the 'right' way. Guess what, 'right' or 'wrong' wont matter if the tech stack you chose slows you down or hurts other important requirements.
Why novelty is rewarded over reliability in SV, I'd never fucking get.
I'm there with you, except that jQuery in 2015(/2016) is not just about fashion; it's about technical merit.
The biggest selling point for jQuery was unifying the mess of browser APIs under one, consistent API. Back in 2006 browser support for ecmascript was so haphazard that writing vanilla JS was an absolute ache. Or so I hear.
As years progress, browsers become steadily more conformant. In tandem, jQuery's value drops.
Meanwhile, cost (speed, size) remains constant.
This argument can be made without considering fashion; even if nobody had ever written a single library after John Resig did, jQuery in 2015 could still be considered an strange choice just for that.
Agree, there are technical merits, jquery is not designed to separate model and controller code from the view. It can obviously be done but most jquery code i've seen are injected smack middle inside the business logic, selecting a few elements from the DOM based on their css-classes(?!) and then modifies them in place. I wrote shit like this myself a few years ago but the more i think about it today the more absurd it sounds. It simply doesn't invite you to write good code and almost requires another framework on top for you to do so. It's a much more low level tool than other frameworks, and might therefor be the perfect job for something as complicated as a spreadsheet.
jQuery is a poor choice for building larger modern web apps because it has a large legacy of plugins that rely on globals and script tags. This becomes problematic as an application continues to grow.
It adds a lot of complexity, because you end up relying on file load order and you typically don't know where stuff comes from. This is why most people have gone on to use module bundlers, because they want their code to declare its own dependency graph, instead of being implicit.
If I see "$.foobar" being used, how do I know where the "foobar plugin" got added to jQuery? If it's imported at the top of the file, it's very easy to look at the file that's being referenced.
This also complicates testing a lot: Instead of loading a test file that imports a library, you have to pull in the library with all of its implicit dependencies and then load the test file.
It's not about novelty, it's about writing code that's easily testable and extensible.
The latest commits to jQuery.sheet were done in 2015, thus the date.
The problem is not in being trendy. The problem is working on a pretty low abstraction level when higher levels, streamlining the code while giving more performance, are available for years.
It's like asking why an app in 2007 would be written in plain JavaScript when e.g. jQuery is available.
Re 'no right or wrong': it does matter if you have to maintain the codebase for a long time. I've seen some legacy codebases, and I can appreciate some of the right choices done by their authors many years ago, as well as pity some of the poor choices made many years ago. Both significantly affect how easy it is to fix bugs and add features to many-yeas-old (or sometimes decades-old) code.
It's interesting to hear jQuery being criticised for being at to low an abstraction level. I thought the hip thing to do was to revisit the stone age: http://youmightnotneedjquery.com
If jQuery is low level, what is high level? SproutCore? Cappuccino? Angular 1? These high-level frameworks have a bright future ahead.
JQuery is too big and its raison d'être is no more. All useful ideas have been integrated in JS5 and HTML5. Plus IE6-8 and Android 1-2 are dead.
I would love if more and more awesome JS libraries like FLOT (Canvas based chart library) would remove all JQuery dependencies and use just native DOM.
(raison d'être = most important reason or purpose for someone or something's existence; too big = 120KB of dead weight is huge, minified 1+MB JS file is bad for mobile users)
1. It's difficult to think it's too big. jQuery 1.x, compressed and minified, is somewhere around 35kB. jQuery 2.x is smaller. This is a relatively small proportion of a web page. It's smaller than frameworks like Ember or Angular.
2. Some of the useful ideas have been integrated (querySelector/querySelectorAll is a popular one) but that's not really the full story. jQuery is still good at abstracting over some of the differences in implementation, and the API is better (for example, doing an AJAX request in jQuery is much nicer than in vanilla JS)
3. 'IE6-8 and Android 1-2' aren't dead. True – if I were building a modern consumer-focused app or site, it might be possible to make the business decision that it wasn't worth supporting them. But you also have to remember that penetration is higher in some industries and countries, and if you need to remain accessible to these then you need to take that into account.
I don't doubt that we will start to see fewer libraries depending on jQuery as support for older UAs is phased out. But you're overstating the current case for it.
Yes, being plain jQuery is a major plus in my book until the cool javascript frameworks manages to switch to Maven (haha :) or otherwise sort out their build and dependency mess.
As for my bragging rights I wrote a dynamic maps implementation in ECMA-script back in 2005.
Today I'm a happy JavaEE user for anything backend (although I accept that Javascript in one form or another is the only thing that runs in the browser for now)
So far nobody has been able to give me a real reason why not to use jquery other than "because it can get really slow if you use it for the wrong thing."
This uses jquery, and isn't really slow. Why is it the wrong thing for this project?
>There has been a big push to move to native Dom rather than jquery, in pretty Much every way. The default wrapper is still jquery, but the internals are 99% dom only. The speed gained from that move are substantial.
I went back and forth with this idea; but in the end I took a read over the Jquery code. It's very helpful since they mark down what browser bug is being worked around in every instance.
After reading through it fully, I found that if I wanted real IE 8/9 support then jQuery was the only answer for complex dom interactions because all the other systems not built on jQuery have either dropped IE8 support (like React), or are for business domains where IE8 support isn't an issue.
Anyways; there's no reason you can't use jQuery + React.
If I was developing a spreadsheet in the browser I would use the lowest level abstraction possible for performance (which is what they're doing since the jQuery is just a wrapper). When you're potentially managing tens of thousands of rows of cells no matter what you use its going to start to chug and solutions using abstraction on top of abstraction on top of abstraction will start to chug a whole lot quicker than vanilla JS.
Disagree. With the right abstractions (like a "virtualized" table such as react-virtualized https://bvaughn.github.io/react-virtualized/) you won't ever need to render tens of thousands of cells simultaneously.
But feel free to implement your own virtualized table if you really don't want "abstraction on top of abstraction on top of abstraction"
I've not used their pro version but the free MIT Licensed is really excellent.