Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Advice On & Instruction in The Use of Ember.js

trek.github.com

Post reply on HN
Print view View original

31–40 of 72 posts

Re: Advice On & Instruction in The Use of Ember.js

#31

Post by judofyr »

wycats wrote: post #24
judofyr wrote: post #17

Let me tell you why I don't care about Ember.js at the moment: It's an "all or nothing"-solution. I couldn't care less about Stateful Single-Page Applications. I'll take a stateless, curlable, crawlable (remember Google?), old-style web site any time. Of course, some parts might require more dynamicness than other, and in that case it's lovely to jump to client side MVC. But it doesn't seem that Ember.js wants to pla…

> I couldn't care less about Stateful Single-Page Applications. I'll take a stateless, curlable, crawlable (remember Google?), old-style web site any time I take it that all of your applications involve public content with minimal if any enhancements to logged in users?

Yes, but even from a user's point of view I'm delighted when I use stateless web "apps". Facebook is an excellent example: There's quite a lot of AJAX-magic, but it still feels (and functions) as a stateless web site. No silly "double loading"; easy to bookmark; links I can Cmd-Tab; the page doesn't magically fail when my internet connection is broken.

I am aware of that most the issues with single-page applications comes from the applications themselves, not the architecture (i.e. is the developers', not the technology's fault) but there seems to be quite a lot of complexity with this architecture. I've seen very few applications that handles all of these issues.

Re: Advice On & Instruction in The Use of Ember.js

#32

Post by MatthewPhillips »

jguimont wrote: post #23
MatthewPhillips wrote: post #16

Earlier quoted context omitted.

Those are implementations details, to the developer they serve a similar purpose. This is my problem with it, a web framework that gives equal weight to M, V, and C is missing the point; in the client the View is fucking everything . It is where any developer will spend the vast majority of their time; not in code organization. The frameworks and I mean this plurally, that win will be those that give structure to app…

Then you do not understand what M and C does. It might be called a client but it is a stateful client. Views come and go , you organize your code in C and M and you'll have a robust long lasting application (in a desktop app, a mobile app or a browser app).

> Views come and go , you organize your code in C and M and you'll have a robust long lasting application (in a desktop app, a mobile app or a browser app).

That's because we're not writing good reusable views. We're writing one-off views that corresponding to the current needs of the current application we're working on. Here's a good view: http://developer.apple.com/library/ios/#DOCUMENTATION/UIKit/...

It was created 5 years ago and I'm pretty sure it's got a lot of life left in it still.

Re: Advice On & Instruction in The Use of Ember.js

#33

Post by judofyr »

tgriesser wrote: post #18

With regards to view cleanup code in Backbone - in the github develop branch [1], the view is now a little more active in its memory cleanup. A dispose() function was recently added which removes any handlers added in the view's 'events' object, as well as any collection or model listeners where the view is passed as the third argument (callback context). This function is also called by the view's .remove(), taking c…

You can also use Coccyx [1] which clears events on all objects (not just this.model and this.collection) and also adds recursive view disposal.

[1]: https://github.com/onsi/coccyx

Re: Advice On & Instruction in The Use of Ember.js

#35

Post by benatkin »

skilesare wrote: post #28

I've now shipped an Ember.js application and a knockout.js application. I enjoyed ember quite a bit but feel that knockout gives me all the magic with half the complexity. It is true as the author mentions that it doesn't aim to fix the UI/statefullness issue, but I slapped on Backbone Routing on to my knockout code and it made capturing 'state' and urls a breeze. The last time I used ember was 0.9.6 and I don't thin…

I posted it as a gist on github for better formatting. I hope you don't mind. :) https://gist.github.com/3517051

Re: Advice On & Instruction in The Use of Ember.js

#36

Post by drek »

Does anyone else thing that the documentation for ember.js is really lacking? Some of the classes it has aren't even documented (ContollerMixin comes to mind) and others are lacking in the documentation depratment. Also, I don't seem to be able to find a full listing of instance methods for a class, I have to climb up the inheritance tree in the docs class by class.

Re: Advice On & Instruction in The Use of Ember.js

#37

Post by Mc_Big_G »

judofyr wrote: post #31
wycats wrote: post #24

Earlier quoted context omitted.

> I couldn't care less about Stateful Single-Page Applications. I'll take a stateless, curlable, crawlable (remember Google?), old-style web site any time I take it that all of your applications involve public content with minimal if any enhancements to logged in users?

Yes, but even from a user's point of view I'm delighted when I use stateless web "apps". Facebook is an excellent example: There's quite a lot of AJAX-magic, but it still feels (and functions) as a stateless web site. No silly "double loading"; easy to bookmark; links I can Cmd-Tab; the page doesn't magically fail when my internet connection is broken. I am aware of that most the issues with single-page applications…

If you do it right, you can support bookmarking pages and cmd-clicking links in your web apps.

Also, an Ember app could be designed to function seamlessly with an intermittent connection where a normal website would just be unavailable. Also, many pages will just continue to function without doing any extra work, provided the user doesn't post to the server until the connection comes back.

Re: Advice On & Instruction in The Use of Ember.js

#38

Post by wycats »

judofyr wrote: post #31
wycats wrote: post #24

Earlier quoted context omitted.

> I couldn't care less about Stateful Single-Page Applications. I'll take a stateless, curlable, crawlable (remember Google?), old-style web site any time I take it that all of your applications involve public content with minimal if any enhancements to logged in users?

Yes, but even from a user's point of view I'm delighted when I use stateless web "apps". Facebook is an excellent example: There's quite a lot of AJAX-magic, but it still feels (and functions) as a stateless web site. No silly "double loading"; easy to bookmark; links I can Cmd-Tab; the page doesn't magically fail when my internet connection is broken. I am aware of that most the issues with single-page applications…

> Yes, but even from a user's point of view I'm delighted when I use stateless web "apps". Facebook is an excellent example: There's quite a lot of AJAX-magic, but it still feels (and functions) as a stateless web site.

> No silly "double loading";

What does double-loading mean?

> easy to bookmark; links I can Cmd-Tab;

The primary goal of the Ember router is to provide this functionality out of the box. The reason you get a single callback with an object regardless of how you arrived at a given state to is to ensure that entering through the router (cmd-tab, bookmark) is the same as transitioning in the app.

If you use the router with the Ember `{{action}}` helper, there isn't really any way to have URLs that don't have the features you desire.

> the page doesn't magically fail when my internet connection is broken.

I don't know exactly what this means. Surely when your internet connection is broken, regular "stateless" pages don't work either?

Are you just saying that there are fewer problem states as an end user? Either the page loaded or it didn't? I've personally had a ton of issues with Facebook Ajax requests failing when I'm in a flaky connection scenario resulting in a generally unusable page.

Can you elaborate on what you mean here?

Re: Advice On & Instruction in The Use of Ember.js

#39

Post by programminggeek »

Ember looks cool, but knockout lets me ship fast and it's less "magic".

Also, I think single page apps have a place as part of a greater architecture, but not as the entire app. If I wanted an entire app everything to be JS, fine, use Ember or something like it, but most parts of the web don't need this and single page apps make the web a bit worse if not done correctly.

Single page apps are the new hotness, but once the fad is over and the newness wears off, they'll be fit into their proper place over time and won't take over the entire app.

Re: Advice On & Instruction in The Use of Ember.js

#40

Post by rjsamson »

mehulkar wrote: post #27
judofyr wrote: post #17

Let me tell you why I don't care about Ember.js at the moment: It's an "all or nothing"-solution. I couldn't care less about Stateful Single-Page Applications. I'll take a stateless, curlable, crawlable (remember Google?), old-style web site any time. Of course, some parts might require more dynamicness than other, and in that case it's lovely to jump to client side MVC. But it doesn't seem that Ember.js wants to pla…

I was concerned about this as well, but I'm successfully using an Ember app as just part of my application. The plan is to use multiple ember apps within the same rails app.

Can you talk a little more about how you're doing this? And have you been successful so far? I'd love to use ember in a few areas of our app while keeping most of the existing structure in rails views, but my (limited) experience with ember is that it looks to be more all or nothing. I'd love to be wrong about that though!
Post reply on HN