Show HN: Ember Table by Addepar

http://addepar.github.com/ember-table/

by ldvldv • 14 years ago

199 49 14 years ago

addepar.github.com

tomdale6• 14 years ago

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!

tomdale6• 14 years ago

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

perokreco2• 14 years ago

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).

vemv2• 14 years ago

"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?

tomdale6• 14 years ago

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.

jwoah122• 14 years ago

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?

perokreco2• 14 years ago

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.

julian372• 14 years ago

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.

stevefturner• 14 years ago

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.

jwoah122• 14 years ago

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.

wheaties• 14 years ago

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

clueless• 14 years ago

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

julian372• 14 years ago

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.

zevyoura• 14 years ago

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.

hayksaakian• 14 years ago

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

haclifford• 14 years ago

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)

pragone2• 14 years ago

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.

bicknergseng• 14 years ago

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?

pragone2• 14 years ago

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

swah• 14 years ago

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

BCM43• 14 years ago

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

Cieplak• 14 years ago

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

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

outside1234• 14 years ago

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.

jongleberry• 14 years ago

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.

dclusin• 14 years ago

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.

larister• 14 years ago

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

ynniv3• 14 years ago

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.

tomdale6• 14 years ago

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.

ynniv3• 14 years ago

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/ ]

davidwparker• 14 years ago

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!

fudged712• 14 years ago

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

superbaconman• 14 years ago

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

rizky05• 14 years ago

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

aroman• 14 years ago

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!

jobowoo• 14 years ago

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

gregable• 14 years ago

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.

vemv2• 14 years ago

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

benatkin• 14 years ago

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.

bhntr32• 14 years ago

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)

workmanw• 14 years ago

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.

tomdale6• 14 years ago

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.

ehsanu1• 14 years ago

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.

TeeWEE• 14 years ago

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!

anodari• 14 years ago

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

Show HN: Ember Table by Addepar

Related Stories