Congratulations to the guys at Addepar on releasing this. They have been contributing an amazing amount of stuff to the Ember.js community—not least of which is helping us build Ember Data.
Probably my favorite thing about Ember is that it isn't built by academics toiling away in an ivory tower; it's driven by real-world problems that web developers are facing.
Our goal is to provide a set of tools that allow developers to build apps and not have to solve the same problem over and over. Displaying large sets of data is one of those problems, so this dovetails nicely with the mission of Ember.js. Thanks guys!
As a side note: if you're interested in this kind of stuff, we'd love to see you at the first Ember Camp, next February in San Francisco. You can even meet the guys who wrote this.
You can also come meet us at our office in Mountain View. We have food and beer and can show you some cool Ember things we are working on(we are also constantly hiring, my email is in the profile).
"Probably my favorite thing about Ember is that it isn't built by academics toiling away in an ivory tower; it's driven by real-world problems that web developers are facing."
So your favorite thing about your project is that it was written by you?
This looks great. Can anybody recommend a similar library (i.e. lazy-rendering table component) that either doesn't depend on a JS framework or uses backbone.js? I know Slickgrid but find it a bit too clunky on the whole, and re-styling it is awkward since its DOM isn't exactly straightforward.
Coincidentally, I just finished a similar table using backbone. It isn't nearly as feature-rich, but it has sortable, movable, resizable columns, and a mechanism for adding filter fields. It was built for a specific purpose in an existing project, but I was actually going to work on turning it into a standalone library and writing a blog piece on it after work today.
Ah yes, I've looked at Datatables before. I think it doesn't allow plugging in arbitrary, lazy, client-side data sources though, can anybody confirm this? If so, that's a pretty big hole in its API and a showstopper for me.
I second this. Any recommendations? ReclineJS is OK but have not had great success with it -- wraps Slickgrid. This table may be enough to make me jump into EmberJS from Backbone.
A feature rich, reliable table view in SproutCore (from which Ember was forked) has been a highly requested feature for at least 4 years. I'm glad that someone has finally done so, but I am also disappointed that it was so difficult.
This is incorrect. Ember.js is not a fork of SproutCore, and they share no code. Ember.js just borrows some of the best features of SproutCore, like bindings and computed properties.
Additionally, the Addepar guys put this together in a few weeks. I'm unsure where your claim that this was difficult is coming from.
Perhaps they no longer share code, but they share architecture which was responsible for the lack of table view in SproutCore. The history of the two projects is long and complicated, and most of the people working on Ember were SproutCore developers. Ember was even "SproutCore 2.0" for a long time.
SproutCore's current table view demo still stutters and lacks the features of the table view featured here[1]. If the Addepar guys put this together quickly, it's because there are no longer architectural road blocks preventing them.
Tom is one of the two main developers you're talking about when you say "most of the people working on Ember were SproutCore developers."
I think the "lack of architectural road blocks" is called ember.js. If you're working with Sproutcore and haven't spent time with ember.js, you should take a look. It has a bit of a learning curve but it's very powerful once you get past that. The guys who built the table would tell you that instead of being an architectural road block, ember.js was the power that made the table possible. That's why it's called ember-table.
I am well aware that he is, but since he didn't say so it sounds accusatory if I point that out. If you read my original comment, I said that SproutCore has been missing a table view for years, and that it wasn't an oversight but something that people attempted to fix a number of times. So if Ember has solved the problem, I am glad it has finally happened. But as someone who has been trying to build projects on SproutCore for years and finding roadblocks, this was long overdue. Perhaps Ember has attained the maturity that SproutCore never seemed to be able to find.
The guys who built the table would tell you that instead of being an architectural road block, ember.js was the power that made the table possible.
That's what it means to be a roadblock... if you don't run into one, you would never imagine that there could have been one. A roadblock is what happens when you attempt to do something logical and find out that due to something outside of your control, it's realistically never going to happen.
I'm not trying to beat a dead horse here, but the two really do not share much architecture, especially when it comes to the view layer. The only place where the two started out looking similar is in the object model, and even that has evolved so much in Ember.js they only look the same if you squint.
Very nice, but you should add some "loading..." text until it's ready to display; on my iPad there were several seconds of a blank white screen and I thought something had gone awry.
Nice. One issue is that the common idiom of cntrl+f is going to be broken with this. Would be awesome if the table supported a search box of some sort.
Very cool - any chance of getting a blog post about how you structured the lazy rendering part within Ember.JS? I have an application where I need to do something similar.
They implemented a scrolling list by recycling the views. This is done in native ios or android apps. So they should write a more generic component which could do that (wihtout the scrollbars and stuff)
I think this is exactly what was done in the fastbook app from Sencha.
This is cool, and I kind of wish it was released a few months ago. I've been building something like this from scratch for a work project for a little while now. Did you guys look into using an actual <table>, or did you go with divs form the start?
We were using Slickgrid for a while and that was a very painful experience as the code was very complex, didn't do frozen rows/columns and didn't interoperate with Ember nicely. I think we wrote this with div's from scratch.
Your table looks very nice, thanks a lot for sharing. We have one in our app that is pretty similar, but not as well developed. I am considering replacing the one in our app with this one.
My only reservation is adding underscore.js to our codebase. Not that I have anything against underscore, but we already Ember, jQuery and jQuery UI. I'm hesitant to add another major dependency. How hard of a dependency is Underscore.js? Could it be easily separated.
It seems like the only thing they are using from Underscore that's not already in Ember.js is Function.bind; I'm totally open to adding it to Ember.js proper.
Awesome. Minor issue: there's some stuttering when flicking on a mac touchpad with Firefox. If I keep my fingers on the touchpad while scrolling, the scroll seems to follow just fine without stuttering. But if I flick it up/down fast there's a delay as soon as my fingers leave the touchpad - and then 200-1000ms later (depending on how fast I flicked), it starts scrolling again. This doesn't seem to happen in Chrome.
Pretty laggy for me with chrome stable (my default browser) and my 2012 13'' MacBook Air. I suspect it was probably because there were half a dozen or so million-row tables -- some with complex graphics. But for basic tabular data, this looks awesome. Good work!
This doesn't work quite well - if I scroll fast enough, my browser (Chrome) thinks I've finished scrolling and goes back to scrolling the screen. As a fan of scanning through data extremely quickly, it's a very annoying interface.
Which kinda makes me think that that particular example, while very cool, is not actually worthwhile. I mean... whats the usecase of being able to scroll through a table with 1000000 rows? I mean... what are you even doing/looking for when you're scanning through tabular data quickly? Wouldn't it be far better to just search or have the data visualized or filtered in a meaningful way?
oftentimes when i'm searching through large datasets it's not for a particular reason - if i have a very large dataset whose contents is fairly ambiguous, my first step is to get acquainted with it. i like to do that by just check random rows, seeing if there are any patterns in the data, or something else that might spark my mind towards how i want to use the data
This is really cool; it'll be interesting to see it's application to feed style content as opposed to tables (in the discussion on the html5 version of facebook mobile rendering the feed was a major bottleneck)
This seems like the classic compile-time run-time trade off. On the one hand it does indeed appear to take a while to load the page. The upside of this though is obviously smooth scrolling for very large presentations of data. Since the sort of use-case this kind of table would be used for could potentially be long and drawn out this trade off becomes totally reasonable in my opinnion.
True, but perhaps more could be done to trim the fat. There are quite a lot of dependencies, and jQuery UI is quite a large library. Am on my phone so can't dig down to see how necessary it is but I'd hope the authors will be able to streamline the dependencies in the future
I agree. I looked at the source and it seems to me that the design is overconstrained (like ORM) and some of the issues people are talking about are likely to persist, unless they start using Ember differently. There are many reasons for SlickGrid being built the way it's built.
Feedback is more than welcome! Please get in touch on github. Let Peter, Louis and all the other developers know what can be done better. I know Peter is hard at work fixing some of the issues already identified here.
Also Igor mentioned above that they built this because they weren't happy with some things in slickgrid. Maybe he can do a blog post or documentation in the future comparing them.
As far as using Ember, the team works closely with the core developers but if you have ideas about how to use it more effectively I think everyone would welcome it. Ember is new and we're all learning (me especially cause I only get to play with it during hackathons. :p)
Probably my favorite thing about Ember is that it isn't built by academics toiling away in an ivory tower; it's driven by real-world problems that web developers are facing.
Our goal is to provide a set of tools that allow developers to build apps and not have to solve the same problem over and over. Displaying large sets of data is one of those problems, so this dovetails nicely with the mission of Ember.js. Thanks guys!