How do we beat AngularJS in the developers mindset?

Yes. But then that’s what Ember assumes you are willing to do, as a developer: If you want to treat JavaScript as a serious and integral part of your application that you are willing to spend time setting up your toolchain.

There’s an argument to be made that you may not want to do so. Countless web app developers have been quite happy with throwing script tags into their app and that’s it; sprockets has made this very easy for Rails and there’s probably similar solutions for PHP frameworks too. But there are downsides to this approach: Modularity, precompilation, asset digests, minification, transpiling (if you use ES6), etc. pp. all have to be supported by your backend framework specific toolchain; and think about what happens when you swap out your API completely. And as for package management, well, you can develop JS without but I wouldn’t say it’s exactly fun.

It is fair to say that Ember requires an upfront investment in setting up your environment (although ember-cli makes this as easy as possible). If you don’t want to do that, Ember will not be the right choice for you, and frameworks like angular allow you to introduce JS more “gradually”.

But then think about what you’re trying to do: You’re trying to write a SPA (otherwise you wouldn’t use Ember) and that means a website that is, for all intents and purposes, governed by JavaScript. Why is it such a bad thing to invest in a proper JavaScript toolchain then? I don’t know how you develop PHP, but wouldn’t you say that using composer, properly modularized code and deployment scripts is a massive improvement over just manually editing your HTML and throwing PHP in and then SFTP-ing everything to the server like in the days of yore? So why not approach JavaScript with the same attitude?

I do agree about documentation and proper full page examples, however.

You should really tell the Angular 2 guys this. They are busy building exactly all that, called ng-cli. Guess who was the inspiration?

1 Like

In all fairness, there’s a time and place for small-footprint frameworks that you just sprinkle in for the 2-3 things that you need. That said, Ember doesn’t want to be that kind of framework.

1 Like

I couldn’t agree more The moment I saw typescript I had almost wrote it off from there

Ya I hear what your saying, this might just be how it has been presented to me thus far and how it’s not even in the same ballpark of thought

You see everywhere “angular or ember” and angular this ember that etc etc

And when I saw things like that JSConf demonstration between Angular, Ember, and Knockout the presenter went out of his way to extract the snippets in use in his slide and never once showed the file system

What I’m getting at is that from where I sat, it looked like Ember was supposed to be Angular’s direct competitor attempting to accomplish the same tasks with a different under the hood approach.

And yeah in the PHP landscape the usage of composer and full stack framework adoption has been instrumental in improving the scene and proving there was a better way than what we traditionally were doing. Stacks like Symfony also incorporates things like Assetic which I think is similar to the rails component you mentioned earlier (I’m on my phone) it’s a cli and template asset manager.

Where Ember cli and composer (and npm and pip and gems and blah blah) differ, is that these package managers are general purpose. Though one COULD say if they knew Symfony “Its got a Console cli component to it relies on pretty heavily” where that one especially differs is that it’s also general purpose, other vendor packages in the framework can “tap into it” and extend it infinitely.

My problem with Ember cli was exactly the same I had with meteor cli and cakephp cli, these are client components that solve a very explicit problems (I’ll call them DX issues (Developer experience)) and purpose for one thing and one thing only ever. So now I got this little program installed. For brevity I also dislike Symfony’s little tool to create new projects for this exact same reason. It’s one function is to clone a new Symfony project into a new directory.

I am also familiar with the use of Gulp and Grunt for running tasks and watchers continuously doing their thing. At one time for a node project I had I think four or five running cli tools doing various things and solving explicit things. I’m not unfamiliar with this landscape. Nevertheless I still think Embers up front asking situation is a bit cray still, and in the situation where I don’t necessarily want a SPA explicitly, I still think Ember would do well to easily enable someone to do that fairly easily. Even if it isn’t the best part or reason or even target audience. But that may be just me lol

I agree, although while having ember-cli and friend is indeed a good thing, I also believe they should not be mandatory.

Talking about inspiration, JS frameworks have decades of toolsuite experience from other languages to build on, and monolithic toolsuites have clearly shown their limitations. Too cumbersome for small projects, yet not flexible enough to be used in an application ecosystem, they mostly shine for standalone, mid-size projects only.

Maybe it’s just me, but I have this nagging feeling that the JS world is re-inventing the wheel, while it could have used proven and tested tools. And it’s doing so in a completely isolated, non-interoperable fashion.

I hear you. I think the issue is just that the JS landscape is very fragmented and not incredibly mature in a lot of ways. In Ruby, e.g. there is one dep/package manager (RubyGems+Bundler) and one task runner (Rake) and that’s it. JavaScript still hasn’t figured out the way to do things and IMHO, in a lot of ways, it has really fundamental issues (e.g. reproducible builds with NPM are really, really difficult). I think that’s why Ember “reinvents” a lot of the things you wouldn’t deem necessary otherwise.

@spectras - ember-cli is not strictly speaking mandatory. You can still develop without. That said, I think for a small community it makes much more sense to converge on a standard set of tools. Documentation, addons etc. are geared towards ember-cli, but you can always just drop a script tag to Ember into your application.

Hello Ember group,

I made a database to collect the differences between technologies and would appreciate input from an Ember expert about this one.

Go here to see a trade-off report between Ember and Angular. If you see anything that’s not right, you can just click on it and enter a correction.

Thanks, Dan

Hello,
It’s a bit messy, it seems to mix completely unrelated things, such as ECMAscript 6 features, with the frameworks.

  • Basically, the whole “syntax and language” is mostly irrelevant to a framework comparison.
  • Or “errors are displayed immediately in the editor”, isn’t that a feature of the editor, rather than of the framework?
  • Or “safe from stored cross-site scripting (xss) attacks”, that does not depend on the framework, that depends on the application code.
  • Also, criteria are fuzzy and seem to stem more from pre-existing opinions than measurable things. Eg: “easy to test”, what does that cover? “fast to load”, how much is that, 10ms? 100ms? 1s? 10s? using what device and what network?

I believe the approach will not yield the results you expect. If you are planning to do a generic comparison (eg: press article), you should define generic enough aspects you want to compare, before even looking at the frameworks. If you are planning to choose a technology, you should define which criteria are relevant to your project and your company.

Anyway, if you want to discuss this further, I suggest you open another topic :slight_smile:

Thanks for taking the time to consider this approach.

If this isn’t the right thread, I’ll start another one. I thought it fit because it is meant to clarify the cases for each of Angular and Ember which influence decisions and developer mindsets.

You raised a few objections, so in fairness to myself, I’d first like to answer them.

I hold that when making technology decisions, it is not the best approach to consider the technologies in isolation from their dependencies. What you see in the syntax section mostly reflects my understanding that Angular 2 uses Typescript and Ember doesn’t. I might be wrong about that. Typescript provides some benefits. If Ember also uses Typescript, then all of those things will go into the third, ‘common’, column of things that don’t factor into the decision.

People make decisions for many reasons. Some of the reasons are facts but unfortunately many of them are opinions. As you know, opinion reasons are debatable, but nonetheless very important to many people and unfortunately hard to replace with quantifiable fact reasons. Because they’re debatable, I put radio buttons at the top to show or hide the opinion reasons which I record in the database in a very unscientific process of reading all sorts of different commentaries.

If you’re still interested, here’s the whole project. It might help give this Ember/Angular comparison some context.

I don’t understand people who criticize Ember or Ember-Data “opinionated” approach.
Let’s talk about consume an API or interacting with a back-end more than 10 years old. Ember Adapter is highly configurable out-of-the-box. AngularJS? Has ngResource and ? Try to use it with different resources to fetch and you risk proliferation of chaos. Define models, define a way to interact and serialize an API, this is “non-opinionated” approach to me (it’s just an hyperbole :slight_smile: ).
Besides that, have you ever tried to embed an angularJs application inside a legacy PHP monolith? Well, with Ember is actually possible without messing with the URL rewriting. This, however, is my little experience on this topic.

<offtopic>
well i know your comment is not up2date but i’d like to mention this anyways
as much as i love the fact devs do not have to care about IE8 due to compatibility layers nowdays…
did you know IE < 11 got deprecated by microsoft in a clear statement where they even dropped security support? microsoft.com/…/WindowsForBusiness/End-of-IE-support

(just wanted to mention this here)
</offtopic>

NuGet works for most, and VS2015 adds support for Grunt, Gulp, Bower, npm…

Let’s start by promoting it in the bootcamps that are booming all over the place. I just graduated from one and nobody ever even mentioned Ember.

2 Likes

There was a hackathon last year here in Wellington, and I just had a half hour session about Ember.js, I saw that so many people would be interested. After that, I started a free workshop, where I teach beginners and experienced developers about Ember.js, every week. We build applications together. This initiative helped me to build www.yoember.com :slight_smile:

Almost a year later, I see, that more and more company start using Ember.js here in New Zealand and Wellington, and they can hire developers with Ember.js experience, thanks for the free workshop.

I would suggest, if you would like to be an “evangelist” of Ember.js, don’t hesitate, just start it and you will see, the community will grow so quickly around you. :slight_smile:

Hey @zoltan, another NZ-based dev here, recently got into Ember for our updated mobile web app and really enjoying it. I’m based near Christchurch so if you get anyone down this way who wants to chat feel free to point them my way - rpoole [at] gmail [dot] com and I’d be happy to help.

@ricky1981 Ah brilliant. I’m glad you like it. :slight_smile: I’ve been in Chch two weeks ago and I had a workshop on Chch.js meetup. Login to Meetup | Meetup You can find me on the global Ember Community Slack Channel, or on JavascriptNewZealand channel as zoltan.

In reference to your documentation comment, that’s assuming that there is usable documentation available for the problem you’re trying to solve. You have my sincere pity if it’s something esoteric, you’ll likely be blazing a new trail. I’ve been working on an Ember project at my job for almost nine months. It’s getting easier, but that being said I won’t call it easy very often if ever.

I read a piece the other day about a developer who chose Ember for an ambitious project. He said what everyone says, that Ember has a steep learning curve. He also said something else that was very perceptive. He also referred to a “learning gap”, meaning that many aspects of the framework offer no extra help. No current StackOverflow (current meaning since 2013), nothing more than a stub of documentation, nada… A learning curve is continuous, even if steep, and can eventually be completed. A gap means you might be on your own…

1 Like

Hi Drew, I hope you find the responses to your critique illuminating. For the Ember priesthood complaints against Ember are rarely acceptable. Just read through the “Why I’m Leaving Ember” thread that they gnashed their teeth on until the post was closed.

No matter the very carefully presented and attributed complaints, there seemed to be a disappointing lack of many Ember faithful to admit or often even consider that it has (glaring?) issues. Most of the issues for me are stale, missing or spotty documentation. I think that many people that are good at Ember are either in that slim minority that picked it up effortlessly, or they are forgetful or insincere in admitting that they probably had the same problems.

So yeah, this IS super snarky, but this is from what I’ve learned from almost a year of having to use Ember and lurking this site.

$0.02

1 Like

I think bootcamps would have a hard time teaching ember in a short period of time, thats why they teach angular because its less complex. Ember is by far more beneficial though, a junior developer could contribute code day one because of the conventions which angular lacks.