

Show HN: Ember Table by Addepar - ldvldv
http://addepar.github.com/ember-table/

======
tomdale
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!

~~~
tomdale
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>

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

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

~~~
jwoah12
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
Please do so, the more the merrier. I'll read it.

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

~~~
tomdale
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.

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

~~~
bhntr3
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.

~~~
ynniv
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.

------
zevyoura
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
Same here. I wasn't sure if chrome crashed or something since there was no
content on the page

------
davidwparker
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!

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

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

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

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

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

------
TeeWEE
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!

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

~~~
perokreco
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.

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

~~~
tomdale
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
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.

------
aroman
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!

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

~~~
pragone
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

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

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

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

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

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

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

------
jongleberry
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
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
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

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

~~~
benatkin
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.

~~~
bhntr3
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)

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

