Show HN: Ember Table by Addepar • Hacker News Board

Re: Show HN: Ember Table by Addepar

#41

Post by tomdale » Fri, Dec 21, 2012, 2:08 AM UTC

vemv wrote: post #39

tomdale wrote: post #2

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 develop…

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

Re: Show HN: Ember Table by Addepar

#42

Post by tomdale » Fri, Dec 21, 2012, 2:12 AM UTC

ynniv wrote: post #34

tomdale wrote: post #27

Earlier quoted context omitted.

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 A…

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.

Re: Show HN: Ember Table by Addepar

#43

Post by jdross » Fri, Dec 21, 2012, 2:13 AM UTC

superbaconman wrote: post #30

fudged71 wrote: post #29

Earlier quoted context omitted.

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

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

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

Re: Show HN: Ember Table by Addepar

#44

Post by tomdale » Fri, Dec 21, 2012, 2:14 AM UTC

workmanw wrote: post #40

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 Undersc…

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.

Re: Show HN: Ember Table by Addepar

#45

Post by rizky05 » Fri, Dec 21, 2012, 2:24 AM UTC

davidwparker wrote: post #21

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!

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

Re: Show HN: Ember Table by Addepar

#46

Post by pragone » Fri, Dec 21, 2012, 3:45 AM UTC

bicknergseng wrote: post #25

pragone wrote: post #12

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

Re: Show HN: Ember Table by Addepar

#47

Post by benatkin » Fri, Dec 21, 2012, 5:04 AM UTC

vemv wrote: post #38

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.

Re: Show HN: Ember Table by Addepar

#48

Post by ehsanu1 » Fri, Dec 21, 2012, 6:08 AM UTC

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.

Re: Show HN: Ember Table by Addepar

#49

Post by TeeWEE » Fri, Dec 21, 2012, 8:43 AM UTC

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!

Re: Show HN: Ember Table by Addepar

#50

Post by bhntr3 » Fri, Dec 21, 2012, 8:44 AM UTC

benatkin wrote: post #47

vemv wrote: post #38

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)