7 ms·
Show HN: Ember Table by Addepar
- tomdale 14y agoCongratulations 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 14y agoAs 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 https://tito.io/tilde/ember-camp-2013
- perokreco 14y agoYou 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).
- vemv 14y 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?
- tomdale 14y agoNope; 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.
- jwoah12 14y agoThis 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 14y agoWe 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.
- julian37 14y agoThis 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 14y agoI 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.
- jwoah12 14y agoCoincidentally, 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 14y agoPlease do so, the more the merrier. I'll read it.
- clueless 14y agoWould this be close to what you are looking for: http://datatables.net/blog/Introducing_Scroller_-_Virtual_Scrolling_for_DataTables http://datatables.net/blog/Introducing_Scroller_-_Virtual_Sc...
- julian37 14y agoAh 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 14y agoVery 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 14y agoSame here. I wasn't sure if chrome crashed or something since there was no content on the page
- haclifford 14y agoThis 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)
- pragone 14y agoThis 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 14y agoWhich 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 14y agooftentimes 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 14y agoThe fastest table I've seen was this http://ukijs.org/examples/core-examples/table/ http://ukijs.org/examples/core-examples/table/
- BCM43 14y agoTo be fair, that table is less than 1/100th the size. I'm not surprised it's faster.
- Cieplak 14y agoTo copy and paste from Excel/LibreOffice Calc to an html spreadsheet, I found this quite helpful: http://labs.nereo.fr/slick.html http://labs.nereo.fr/slick.html
- outside1234 14y agoVery 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 14y ago500kb 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 14y agoThis 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 14y agoTrue, 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
- ynniv 14y agoA 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 14y agoThis 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 14y agoPerhaps 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/ http://demo.sproutcore.com/table_view/ ]
- bhntr3 14y agoTom 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.
- 14y ago
- davidwparker 14y agoVery 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 14y agoYes, this is use case is a strange omission considering the solution presented.
- superbaconman 14y agoI was able to. Maybe it's a browser issue?
- rizky05 14y ago1 Million Row is empty for me, another sample is working. Latest firefox, mac.
- aroman 14y agoPretty 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 14y agoCongrats to the Addepar team. Love what you guys are doing :)
- gregable 14y agoNice. 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.
- vemv 14y agoSorry but if the project doesn't even mention SlickGrid (e.g. how does compare to it) I can't take it seriously.
- benatkin 14y agoI 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 14y agoFeedback 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 14y agoYour 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 14y agoIt 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 14y agoAwesome. 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 14y agoThey 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 14y agoCool! I was looking for a table with OLAP capabilities to use in examples in my BI course.