Ember.js 1.0 Prerelease | Hacker News Reader

Ember.js 1.0 Prerelease

emberjs.com

80 pointspatr1ck36 comments

Off topic but can a another Windows user can tell me if the text looks horrible to you as it does to me? http://i.imgur.com/rooNb.png

I know Chrome has bad font rendering problems on Windows but this is just atrocious. Also FF is a bit better but not by much. This usually happens to me with webfonts only. The fact that I see so little complaints about this online make me think that perhaps it has something to do with my system.

edit: an even worse example http://i.imgur.com/XTATn.png

yeah, I'm getting that look too.

You may wish to try adjusting your ClearType settings.

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

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.

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.

Could this be due to the background image?

That exacerbates it a bit, but the font is still pretty blocky unless you zoom the fuck out of it.

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.

Whilst you're right that Windows fonts are generally rendered poorly in comparison to Mac/Linux, this is especially an issue with web-fonts afaict. Web-safe fonts like Arial, Georgia etc look (pretty much) fine under Windows.

In fact I think something else is at work here, because actually the main font this site is using is 'Lato' which looks just fine under Windows if you search for it at http://www.google.com/webfonts

Glorious Windows!

Looks atrocious for me as well.

I've looked at Ember.js in the past, but frankly, I've been intimidated by the lack of good documentation and examples. I'm not an expert like some of you and I really need good tutorials. Backbone excels because of the large community. Knockout has some killer walkthroughs - http://learn.knockoutjs.com/. Now that Ember.js 1.0 is on the horizon, is this getting better? I want to learn!

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.

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.

Hmm, I recently decided to get into the webapp/js stuff and decided to start with Ember, but the lack of documentation was too much for me. Now I'm learning angular and I love it.

Could you elucidate more on your decision? Specifically, was anything harder in angular/easier in ember?

Firstly, I haven't been into webdev for a long time. I've been working on iOS for a little over 2 years now and given that prior, I found the semantics of ember.js to be a little more intuitive than angular.js.

At my current gig, I'm working on a vehicle fleet routing system, where my primary focus is essentially on getting the core algorithm right. I could have delegated to UI to someone else, who is better at these things than me. But eventually I had some free time and decided to do it on my own. Most of the UI is around a big Google Map, and given the limited time, I couldn't figure out how to write a wrapper view around it with Angular.js but with Ember it was fairly straightforward. It's very likely that I haven't explored Angular enough, but my primary focus here was to ship it to our internal users asap. Also, since I'd proudly told my boss that I don't need a front end guy, I had to get something working to save face. If Ember didn't work, I would've tried Backbone.js. BTW, like everyone else, I love the simplicity of Backbone.js.

Also, the ng-* attributes in angular templates feel a tad bit unpleasant. Handlebars templates OTOH, were very familiar. Probably because I'd used Mustache templates in an iOS project some time ago.

Actually, I found the documentation of Ember.js to be pretty good. There aren't enough examples around, but the documentation is pretty decent. Besides that, I learnt quite a bit of advanced undocumented APIs from Clemens Müller's blog (http://code418.com/).

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.

really excited about this. We've been using Ember.js for a few months and I've been really impressed by the people in the community (at least in NYC).

Here are some slides from a presentation my cofounder did about our journey from first commit to production deploy in 10 days:

https://speakerdeck.com/u/jrallison/p/building-customerio-wi...

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

I really do love what Ember brings but I need, need, need a production ready persistence layer. Backbone has me spoiled in that area.

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

> It has a run loop in an event-driven browser

The "run loop" hooks into the existing browser's event loop in order to coalesce side-effects. This is exactly the same thing that the browser does when you make a number of changes to the DOM in an event handler.

There is nothing strange going on here.

You can turn that off if you want, personally I don't miss much of it.

As for the even driven stuff. Not sure what you mean by that, the run loop is not to dispatch dom events but to settle the bindings asynchronously (with the benefits of not triggering multiple changes for the same property within the same run loop and having a comprehensive pipeline to get data on the screen).

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

That was his point, he said production ready.

Stupid question maybe, but has coffeescript support been talked about at all?

I've had issues with ember and coffeescript before because of some of the choices they've made on how to declare models.

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.

Yay real excited about this! I'm currently a Backbone.js junkie but I'm looking for something more opinionated and less boilerplatey. Nice to see Ember.js maturing. Let's see some more documentation!

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'm confused about how this or similar offerings like backbone would fit into an existing web app framework like django. Would you even use this for django or rails? Because at the surface, it seems like I'd have to retype my model definitions in JavaScript (or at least code generate them) and then use some JavaScript templating system instead of django's.

Can anybody shed some light on this for me?

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

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.

we were planning to use Ember.js in our production app last week, but dropped the idea of using it after learning that API might change in 1.0 release at Throne Of JS (http://throneofjs.com)

Now, that we are much closer to 1.0 release, We'll re-visit the idea! The whole team was highly impressed by it.

congrats guys - looking forward to dropping it into my app and giving it a try this week!

Reply on news.ycombinator.com