Hacker News Reader

Comment by judofyr | Hacker News Reader

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 play this game. Every time I look at Ember it seems that it wants to define the architecture of my application. Thank you very much, I like my stateless-ness very much!

View on HN

Ember is primarily for web apps, not web sites. Apps that require a login are not concerned about crawlability. So, if you're just building websites, you are correct to not choose Ember.js.

Also, it's trivial to have some pieces of your app rendered by rails or whatever you're using server side.

We're using Ember to build the next generation of our product (a web app) and it has been an extremely pleasurable experience.

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

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.

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

> What does double-loading mean?

Basically, a web app that is usable (or at least readable) before all your JavaScript initialization is done. With Facebook, as soon as the HTML and CSS hits your browser it can render a more or less complete page. With Ember.js, that doesn't happen until the application is initialized and all your templates are rendered.

To be fair, that totally depends on how the application is written. You can have server-side-rendered page with single-page application, with or without Ember.js.

With Ember.js the routing framework is client-side and Ember.js stores all dynamic values in the URL fragment. The server doesn't see enough information to render a page, even if you were willing in theory to duplicate your rendering logic server-side.

You can use HTML5 pushState in Ember.js [1] and Backbone so application state is captured in actual URL path instead of URL location hash. The server can see enough information to render a page.

[1] http://www.kaspertidemann.com/how-to-make-ember-js-use-histo...

There's nothing stopping you from having only certain parts of a page or application use Ember. Several people use this approach successfully.

See the `rootElement` property of `Ember.Application`: http://docs.emberjs.com/#doc=Ember.Application&src=false

it seems ember is targeting web apps, which are generally behind a login for the bulk of the app, making most of your contentions moot. Not disagreeing with you, just making the point that Ember is probably not trying to be a one size fits all solution

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!

There are better ways to do it, but I use a javascript include tag to render the directory that holds my ember app in the view file of the route I want to render it in.

Reply on news.ycombinator.com