Ember.js 1.0 Prerelease (opens in new tab)

Can we please get a Chrome release version that uses DirectWrite like FF4+ and IE9+ already? Sheesh. https://groups.google.com/a/chromium.org/forum/?fromgroups#!...

What I see matches your screens. The font renders poorly on Windows (Chrome & Firefox), on 2 different PCs (one Vista, one Windows 7). Cleartype is enabled (default). I've seen similar problems with web fonts before, but this is especially bad (probably exacerbated by the small font-size) so you're not alone. Shame, as it detracts from the rest of the design which is pleasingly beautiful.

Back on-topic: Very interested in this release, router sounds especially promising. Hope to see some docs on that soon.

You may wish to try adjusting your ClearType settings.

cancelbubble: I can't reply to your comment directly, but your account appears to have been hellbanned for quite a while. I'm not sure how to get that undone, try contacting pg.

this is a generic windows issue. usually noticed by users who switch over to it after using a mac for a while. lets just say font-aliasing is not one of windows strengths.

Could this be due to the background image?

yeah, I'm getting that look too.

Looks atrocious for me as well.

Glorious Windows!

It seems like the problem is that things are changing so quickly with Ember.js that any documentation (blog posts, guides, etc.) that is available is horribly out of date.

I just spent a few days trying to build an app with Ember.js and had a lot of trouble trying to figure out what is the current best practice for structuring my app. Should I be using a Router or StateManager or Controllers or something else. Clearly the project is progressing very quickly, which is great, but with so many new ideas being tested out, it's currently difficult to figure out the "right" way to build an app with Ember.js.

I recently tried angular.js and then chose Ember.js, I ended up struggling with it for about a week, after which it was easy enough. Since then, I've written two relatively simple internal apps with it in less than a week.

I'm in the same boat. A few months ago when I started looking I ended up settling on knockout mainly because of the excellent docs/walkthroughs.

Where is the community congregating in nyc? I've missed out.

Really? Backbone collection/models are a simple layer with an Ajax call behind. No relations, no lazy loading, etc. Backbone models are akin to an ember object with a fetch/save call, nothing more. (Good for some scenarios, but not enough for "ambitious web app" IMO)

Ember data has a bigger goal than this and, yes, it takes time to get it right.

Have you seen Ember-Data? https://github.com/emberjs/data

Also prototype ninja'ing is on by default. It has a run loop in an event-driven browser.

CoffeeScript doesn't support the hooks we need to make its class system work with Ember.js' object model, but Yehuda and I have both worked on a large-scale Ember.js application written in CoffeeScript and it was fine.

I'm in the same boat. While I definitely appreciate Backbone for what it tries to be (and it excels at that, in my experience), I find myself somewhat unsure at times if I'm deviating too much from best practices. Not that I need someone to hold my hand, but a lot of times when using backbone for my non-trivial app, I got the feeling I was reinventing a wheel.

For example: view clean-up (the zombie problem), model relations, alternative transport layers (socket.io), and view nesting.

I did however often greatly appreciate the elegance and simplicity of Backbone's source code and design, as well as for introducing me to the fantastic Underscore library, which I now make much use of both client-side as well as in Node.

I think I'll wait until the first 1.x release to consider porting my app over, or perhaps not depending on how Backbone 1.0 turns out.

Excellent work by both teams.

I've been messing around a little with ember lately, I'm no expert, but from what I've tried using ember-data you can define the models directly from a REST endpoint response and pass that to your views or have other properties be dependent on them without ever explicitly specifying those fields exist.

Your assumption is pretty right, with backbone and this you would normally receive the model data from your server via JSON, and handle display and interface on the client side (coding the UI in Javascript would be the major advantadge, because you can get a speedier UI).