Ember.js 1.0 Prerelease(emberjs.com) |
Ember.js 1.0 Prerelease(emberjs.com) |
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
Back on-topic: Very interested in this release, router sounds especially promising. Hope to see some docs on that soon.
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
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.
Could you elucidate more on your decision? Specifically, was anything harder in angular/easier in ember?
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...
Ember data has a bigger goal than this and, yes, it takes time to get it right.
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.
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).
I've had issues with ember and coffeescript before because of some of the choices they've made on how to declare models.
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.
Can anybody shed some light on this for me?
Now, that we are much closer to 1.0 release, We'll re-visit the idea! The whole team was highly impressed by it.
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/).
