How do we beat AngularJS in the developers mindset?

Sure.

  • Computed properties and aliases using the Em.computed() shorthand are not in the Guides. (This is a great example of the kind of gap I see a lot of, actually: this stuff is too specific for the Guides, but the API docs are too detailed - and specifically organized - to surface it.)
  • The $() shorthand for getting a jQuery object of the current view.
  • The concept of parentController.
  • Enumerables’ firstObject and lastObject.
  • needs in controllers is mentioned almost in passing in the Guides, then in the API it’s so densely explained it’s almost impenetrable. This seems like a pretty important topic which could benefit from a clear, focused explanation.

That’s just off the top of my head, all except the last two just from today’s work.

I don’t want to run down the quality of the documentation. I picked up Sproutcore when the primary entry route was a “Hello World” tutorial on a wiki which was (a) buggy and (b) out of date, and if you wanted API docs you had to build them yourself from the JSDoc in the code. Ember is a relative paradise. But it’s still really hard compared to a lot of things web programmers could be learning.

2 Likes

@Sarus I agree with you.

I’d also say that I think including ActiveModelSerializer into Ember-Data is an error. This should be, at most, an external library, but NOT included into Ember-Data. Quite ironically, I stumbled upon an old PR from @tomdale iirc that said this won’t be included by default in Ember-Data.

This thing alone makes developer think Ember-Data is Rails centric, and as a consequence, most efforts regarding adapter in the PR list are spent on this specific serializer. It introduces a dependency with a server-side technology not everyone use, which is bad imho.

What should be done is:

  • Either make the RESTAdapter compliant with JSON-API, and make ActiveModelSerializer compliant with this format too.
  • Or move ActiveModelSerializer outside the project.

I’m a bit afraid tbh by the status of JSON-API. There does not seem to be a lot of activity inside the repo, and we are nearly beta7 in Ember-Data, I think work should be done now to make it compatible with JSON-API.

1 Like

Hey guys,

I’m taking the plunge out of Backbone (finally, I know) and am still a bit on the fence. I absolutely love the paradigms, principles, and overall structure Ember provides. A lot.

But, having done both the ToDoMVC (Ember) tutorial and the Angular tutorial, I would have to say that the Angular one feels more thorough.

I’m with everyone else on this thread: people seem to be hesitant because of the testing and documentation advantages Angular holds (though, the documentation on Ember is actually astounding, it is missing a single thing…cough Git)…

A couple suggestions:

  1. If possible, add testing to every step in the documentation / tutorial app steps. Angular has very strong testing examples (that work with their sample app you can download immediately). This relates to my next point, but the sample app should really be put up on Github.
  2. Put the sample app on git, broken down in step by step git commits, just as the angular one has done. It makes it blindly easy for someone to quickly dive in, go through the steps (without the tedious copy and paste code process). I know when I ran through the Angular one, it was really handy to do the git checkout -f step-3 as I completed the steps, for example.

Either way, phenomenal work on 1.0. I’m really blown away with the concepts and am feeling that Rails-y excitement over a FED framework. Kick ass.

2 Likes

I would love to see testing added at every step as well.

Usually I can stumble my way through figuring out the undocumented parts with Ember. Testing however continually throws up roadblocks in front of me and I can never get anything beyond the basics to work.

Cheers,

James

2 Likes

@andrewmartin and @hasaki thank you for your feedback.

Yeah I couldn’t agree more about the tests and step by step stuff. I’m thinking I might do something to help out here in some form.

My thoughts about it are in accord with yours, I think:

Hello guys,

first to say to I am super new to EmberJS. I agree with all the comments about the steep learning curve and that’s it’s not that easy to get to that ‘Aha’ moment, when you know what is going on.

I think that having a section with links to posts, screencasts will be really nice. Someplace that you can go and see some really helpful articles that are up to date. For example I really enjoyed smashing magazines’ article and had more than one ‘aha’ moments : )

That said, I really enjoy learning EmberJS and can’t wait to get to the level where I can start the next project with it. Hope to see the final version of ED and HTMLBars soon as well

And to the team I can say - great job guys. : )

PS EmberJS’ site is so much nicer than AngularJS :smiley:

There are too many ways drive people to make a decision which one should go. I have tried too many as well, search keyword like “vs.”, “comparison”, “awards”, “performance”…Finally I settle down one main factor - “success stories” - To see what companies have use it; what product finally has been built. if you compare http://builtwith.angularjs.org/ and Who's Using Ember.js - Ember.js. you see what I mean.

1 Like

Yes. Thats what convinced me as well. I think there are just more complicated products got built on ember in production.

I think we should build better tutorials to learn ember.js. For those of us, which has any experience with ember.js the should also have some best practice informations like blog entries.

For all german speaking ember people, I bought the domain ember-blog.de. I would like to set up an blog about learning ember.js and good practice samples about real world projects examples. If someone are interested to help with writing. Please contact me

I recently completed a project using Knockout. I then started re-doing that project in Angular, and now Ember, just as learning experience. One reason I tried Angular first is that they are hosting meetups featuring users from known companies using Angular. It was the one and only Ember meetup that piqued my interest. I think I prefer Ember and would love to hear more about how its solving real world problems. It would be particularly valuable to learn about how it differs from Angular. Perhaps someone from the Ember team could speak at some meetups.

@nullsteph did you see the recent explanation @jandet did of her building Vine.co at ember meetup NY? It’s well worth a watch if not (also @ebryn talks about HTMLBars at the end, etc.) :

Also it might interest you to look at this:

http://emberhotseat.com

1 Like

I’ve been using Ember.js for a few weeks now and the primary feedback I have is as follows:

  • Ember.js documentation is poor. Sure, there are lots of examples scattered throughout the guides, but they guides themselves aren’t cohesive. They don’t answer enough questions. They don’t link to corresponding API calls.

  • The Ember.js “story” – building an application from scratch – is to specific to a simple use case. The bottom line is that most applications – single-page or otherwise – will involve some server-side state, must handle user-driven browser actions (page reloads, etc.), and will need authentication and session data at the server level. Ember.js is, frankly, very poorly documented and supported for these things. It works only if you have a very specific pattern to follow. As soon as you break out of that pattern you run into open issues.

  • There are not enough recipes for the very obvious use cases. Case in point, the most obvious and common pattern of all, that of the aforementioned authentication. It should be trivial to enable to unification with Flask or other backend session handlers, to redirect users to a log-in page on the front end depending on whether they are authenticated, to sync session data that needs to persist across Ember application loads, and to handle common browser actions. Although in theory this sounds easy it turns out to be much hairier to handle all the use cases in practice. If Ember.js were to introduce a well-documented, seamlessly integrated authentication subsystem this would probably do a lot of get users more supportive. As is it, it’s a deal breaker for many applications.

Bottom line: as long as Ember is used to write a (very limited) Ember-ish application, it’s great. If you need to do anything of moderate complexity, particularly where server-side synchronization is required, the amount of work needed climbs precipitously.

3 Likes

Ember-CLI is coming, man. The documentation could use your help and your voice… we need as many voices as possible around this screaming where things are poor, and doing it inside the actual website git project… even better, providing patches and pull requests…

Personally, I think your authentication example isn’t great, though. Not all ember “apps” require authentication in your prescribed manner. What you seem to be after, though, is a golden path. In exactly the same way that Rails doesn’t provide a default authentication method (apart from Realms) out of the box, but rather affords a plugin system, I think Ember is going to be better served by providing a plugin system… which, by the way, Ember-cli and the work with ES6 is kind of doing…

This is cutting edge stuff. There aren’t any other javascript frameworks attempting what ember is attempting, and to that end it’s not “finished” yet.

But yeah, please come help out on the documenation front. We’d love to hear your change requrests, or even just your specific complaints. <3

@adamdonahue Ember Simple Auth is a great authentication system that is simple to integrate. See kagemusha and my Ember App Kit+Ember Simple Auth API Client and our companion rails+devise+doorkeeper API server for a working example that use it. Kristian Mandrup and I are working on cancan-style authorization for Ember. More info on that when its ready.

I think charging $799 to learn Ember.js the official way is too much. Dial it down a little? I don’t mind paying some, but not that much I think. Hmms… $200 I think is a nice price to learn.

I’m making the Ember Sparks screencast series right now (‘EmberCasts’ was already taken) to fill part of that hole. However, the way I’m avoiding burnout is by limiting the scope to 1 ~5-minute video every week, so there’s plenty of room for others.

2 Likes

TIL how to use defineProperty

thanks!

1 Like

I have to agree on this one, I’ve been using ember for a few months now and feel pretty comfortable with it. I’ve had a couple of cracks at TDD (my workflow has been entirely BDD on the server side for about 5 years now) and I just haven’t been able to get a test to run. In part I think this is because I’m using ember-app-kit which adds an extra layer to understand. The transition to ember-cli hasn’t helped here. However, I am hopeful that once ember-cli gets going a good testing story will emerge there.

That is exactly what happend to me. I started with ember and invested a lot of time books and the very good video and landed at angular. The reason was that the abstraction of ember is very high. You are far away from html, what is ok when you are within the borders of the framework. I think angular simply has an other level of abstraction than ember.