PivotTable.js: a JavaScript Pivot Table implementation(github.com)
github.com
PivotTable.js: a JavaScript Pivot Table implementation
https://github.com/nicolaskruchten/pivottable
14 comments
Looks interesting... If doing everything in javascript is not sufficient, another nice open source project with a slick interface on top of a real OLAP server (Mondrian) is Saiku - http://analytical-labs.com/
I've looked into Saiku and it has a very pretty and usable interface but, as you say, it requires the OLAP server. Not very useful if you plan on doing ad-hoc reporting with django as a backend for instance.
This is not a JS library!! This is coffeescript. Stop calling coffeescript stuff .js it is really misleading for people that actually develop in JS.
I take your point. I'll be honest with you though: one of my goals was to get highly-ranked for the phrase "javascript pivot table" because that's what I had initially searched for. I would likely not have found something called "coffeescript pivot table" or something similar. So I mostly mean "pivot table invokable via javascript" rather than "originally written in javascript".
How? It compiles down, and produces(not-great but decent) JS, and be included normally, why the objection?
Have to agree with the OP. Even though I can generally read CoffeeScript I'd much rather have all the code I depend on be on JavaScript because I much prefer contributing to JavaScript code.
I also feel like CoffeeScript encourages incredibly complex practices just because the code can be written in a small amount of space. For example, here's a block of code from the library in question:
I also feel like CoffeeScript encourages incredibly complex practices just because the code can be written in a small amount of space. For example, here's a block of code from the library in question:
sumOverSumBound80: (sigfig=3, scaler=1, upper=true) -> ([num, denom]) -> ->
sumNum: 0
sumDenom: 0
push: (row) ->
@sumNum += parseFloat(row[num]) if not isNaN parseFloat(row[num])
@sumDenom += parseFloat(row[denom]) if not isNaN parseFloat(row[denom])
value: ->
sign = if upper then 1 else -1
(0.821187207574908/@sumDenom + @sumNum/@sumDenom + 1.2815515655446004*sign*
Math.sqrt(0.410593603787454/ (@sumDenom*@sumDenom) + (@sumNum*(1 - @sumNum/ @sumDenom))/ (@sumDenom*@sumDenom)))/
(1 + 1.642374415149816/@sumDenom)
format: numberFormat(sigfig, scaler)
I'm not a Javascript expert, and I haven't used CoffeeScript before, but this block of code looks perfectly readable to me (except for that ugly mathematical equation). If this is supposed to be an example of unreadable code, then maybe it's time to learn me some Coffeescript...
Indeed, I've never given CoffeeScript more than a cursor glance, but I'll say that rates much higher in readability than average javascript I've written. If that is ment to be an example of bad pratice....
I agree, this is the hairiest, least documented part of the API. CoffeeScript makes it easier to read than the corresponding Javascript construction but then again this might be CS encouraging things that wouldn't fly in JS for good reason :)
The pivot table needs an aggregator object per cell, so we need a factory-function to provide one (this is the right-most arrow).
That function needs to know which columns to use as the numerator and denominator, without these being passed in on every invocation, so I used a function-generator that closes over those two values.
The third, almost gratuitous layer of function calls allows one to parametrically generate this function-generator with different formatting options.
The pivot table needs an aggregator object per cell, so we need a factory-function to provide one (this is the right-most arrow).
That function needs to know which columns to use as the numerator and denominator, without these being passed in on every invocation, so I used a function-generator that closes over those two values.
The third, almost gratuitous layer of function calls allows one to parametrically generate this function-generator with different formatting options.
This is misleading. Of course like Javascript you can write terrible CoffeeScript code. There are plenty of terrible written Javascript code examples out there.
Absolutely, but you get by like Yen (replied) who think that it's completely readable. Whereas in Javascript you're going to have a much harder time arguing that a triple-nested function that returns an object with other functions inside of it is readable. This exact same code in Javascript would be a laughable offense, but people defend it to the death when it's Coffeescript because the complainers "just don't get it".
http://nodejsreactions.tumblr.com/post/51550250985/discoveri...
http://nodejsreactions.tumblr.com/post/51550250985/discoveri...
Hey, I agree with a lot of what you are saying here, but it seems unfair to cherry-pick a single method like you are doing here. There's a lot of confusing JavaScript out there, too.
For the same reason I don't call my c++ libraries (foo.asm) or dart libs (foobar.js). Fundamentally it is a different language with different syntax and semantics. Just because something can compile to js does not make your library a "js" library.
Note that this is not an argument against coffeescript as a language. Use it if you want. Just realize that calling things ".js" when they are not is both confusing to newcomers and those expecting to read a lib written in js.
Note that this is not an argument against coffeescript as a language. Use it if you want. Just realize that calling things ".js" when they are not is both confusing to newcomers and those expecting to read a lib written in js.
Maybe he wants to contribute? That's all I could think up...
I agree. It might seem like nitpicking, but it's a very different syntax.
Would like to see a demo of this with a large data set.
I'll work on getting something like that posted. I want to demo some of the fancier aggregation functions as well :)
I'm working on a analytics-related project and this looks like something I can use! The input format is a little restrictive, but understandably so (since this is meant to be used for tabular data)
The data I'm working with is a little more nested and looks like :
[ {
color: {r: 0, g: 0, b: 255}, shape: {name: "circle", description: "A round shape"}},
{color: {r: 255, g: 0, b: 0}, shape: {name: "triangle", description: "Has 3 sides"}}
]
than the example that was provided.
than the example that was provided.
Looks nice and light weight.
Also check out Saiku:
http://demo.analytical-labs.com/
Talks to OLAP server over XMLA (like Mondrian)
Also check out Saiku:
http://demo.analytical-labs.com/
Talks to OLAP server over XMLA (like Mondrian)
Maybe camel case is not appropriate as the title, from wikipedia:-
"The term pivot table is a generic phrase used by multiple vendors. In the United States, Microsoft Corporation has trademarked the specific form PivotTable."[1]
[1] http://en.wikipedia.org/wiki/Pivot_table
"The term pivot table is a generic phrase used by multiple vendors. In the United States, Microsoft Corporation has trademarked the specific form PivotTable."[1]
[1] http://en.wikipedia.org/wiki/Pivot_table
Lots of people said that there were no javascript pivot table libraries. Actually, that's not true. As I know, flexmonster pivot table component is a mature implementation. And recently I have a pure javascript implementation. It supports CSV data just exactly like excel and also I am adding OLAP support as well.
webpivottable.com
webpivottable.com
This is very cool. But the inherent limitation here is that it only works well for small datasets. If you have a million rows you don't want to download it all into your web browser and summarize it in the browser. Instead you want to summarize it on the server and only download the summary to the web browser.
For a lot of data-sets the amount being passed around is going to be small enough though. I expect CPU power to be more of a limit than bandwidth: depending on what grouping options the user picks a large dataset could take a lot of time to draw making the interface feel very clunky, particularly if like us you have a chunk of your user-base stuck on classic IE instead of more modern browsers.
We are working on something similar to enhance our app's existing custom reporting features. While we're erring in the side of "client side will be fine for our current requirements" if you don't mind the extra state storage server-side (or extra database hits to re-collect the data from the back-end each time) you could keep the data there and pull the results back via AJAX calls - with careful design you could even be share the slicing/dicing code between client & server and make the choice dynamically (if the data is small send it all to the client then you are as responsive as possible, if it is above a certain payload size keep it server-side to improve load time at the expense of interactive latency due to the AJAX calls as the user plays with the data). And/Or you could give the user the choice.
We are working on something similar to enhance our app's existing custom reporting features. While we're erring in the side of "client side will be fine for our current requirements" if you don't mind the extra state storage server-side (or extra database hits to re-collect the data from the back-end each time) you could keep the data there and pull the results back via AJAX calls - with careful design you could even be share the slicing/dicing code between client & server and make the choice dynamically (if the data is small send it all to the client then you are as responsive as possible, if it is above a certain payload size keep it server-side to improve load time at the expense of interactive latency due to the AJAX calls as the user plays with the data). And/Or you could give the user the choice.
Emphatically agreed!
We routinely use this tool to summarize datasets which are, at their most disaggregated, hundreds of millions of rows. We have a server-side process which rolls those up into hundreds of thousands of rows, which are then fed to the browser via a query interface which tends to send only a few thousand at a time, which is easily handled by this tool.
Each step in this pipeline 'summarizes' to an extent, and the last mile is this interactive client-side tool, which would be less responsive if it were server-side.
We routinely use this tool to summarize datasets which are, at their most disaggregated, hundreds of millions of rows. We have a server-side process which rolls those up into hundreds of thousands of rows, which are then fed to the browser via a query interface which tends to send only a few thousand at a time, which is easily handled by this tool.
Each step in this pipeline 'summarizes' to an extent, and the last mile is this interactive client-side tool, which would be less responsive if it were server-side.
Agreed; to be fair though, is it really appropriate to use a client-side pivot table library if your use case necessitates a server-side approach?
Yummy. Couple that with a column-orient database and I don't need OLAP any more.
I just used this other one for a project at local.italiaonline.it and it is really good (all sums are ok :)
http://rjackson.github.io/pivot.js/
http://rjackson.github.io/pivot.js/
This is pretty cool and fast. For Java people check out ZK Pivottable http://www.zkoss.org/product/zkpivottable
I'll definitely be spinning this up in the near future to pull together some web service data. Might even be a good excuse to begin working more with coffeescript. Thanks!
Nice! PivotTables are underrated.
My next project was to build something very similar to this. I've done the same before in PHP many years ago for the company I used to work for so I was confident that I could do it. Having this to leap frog my development is going to be extremely useful. And by that, I mean any extras I'd develop I'd contribute back.
Now to start playing.