Show HN: Ember Table by Addepar | Hacker News Reader

Show HN: Ember Table by Addepar

addepar.github.com

199 pointsldvldv49 comments

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.

There are still some tickets available here: https://tito.io/tilde/ember-camp-2013

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?

Nope; the opposite, in fact. For the past few months, Yehuda and I have been focusing our efforts on Ember Data.

Maintenance and feature work has been almost entirely done by people other than us, in the process of building real apps.

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.

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.

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.

Please do so, the more the merrier. I'll read it.

Would this be close to what you are looking for: http://datatables.net/blog/Introducing_Scroller_-_Virtual_Sc...

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.

At any rate, thanks for the heads up.

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.

[ 1 http://demo.sproutcore.com/table_view/ ]

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.

Same here. I wasn't sure if chrome crashed or something since there was no content on the page

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.

Only problem that I had was that I couldn't grab the scrollbar to go down the table faster (for the million table example). Great work though!

Yes, this is use case is a strange omission considering the solution presented.

I was able to. Maybe it's a browser issue?

I just tried again. Can't drag the scroll slider. Latest OSX Chrome.

It's an issue for Mac OS X for people who have invisible scrollbars enabled. Issue is being worked on, thanks for sharing!

1 Million Row is empty for me, another sample is working. Latest firefox, mac.

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.

Nonetheless its nice work! Hooray for opensource!

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)

To copy and paste from Excel/LibreOffice Calc to an html spreadsheet, I found this quite helpful:

http://labs.nereo.fr/slick.html

Congrats to the Addepar team. Love what you guys are doing :)

The fastest table I've seen was this http://ukijs.org/examples/core-examples/table/

To be fair, that table is less than 1/100th the size. I'm not surprised it's faster.

500kb transferred? 2 seconds to load all the CSS and JS files? 4.5 seconds to load everything?

Way too much overhead for a static page, IMO.

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

Sorry but if the project doesn't even mention SlickGrid (e.g. how does compare to it) I can't take it seriously.

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)

Cool! I was looking for a table with OLAP capabilities to use in examples in my BI course.

Reply on news.ycombinator.com