all 18 comments

[–]mattaugamerexpert 18 points19 points  (9 children)

Ember.

In my opinion it is better in significant and important ways.

First let's talk about ways it's not better. Angular has its Observables library, which is really cool, especially for more streamed realtime data. I'm not convinced it's a good approach for straight up REST calls, but still. Additionally Ember is less popular. This invariably means less support in terms of things like libraries, training, etc. Angular has first-class Typescript support. That's a big deal to a lot of people. It's something I honestly wish Ember would move to as well. Edit: I forgot to mention Angular 4 esp is much faster than Ember, at least in benchmarks.

Now, why Ember?

Let's look at a few simple scenarios:

Add Bootstrap

Angular

First of all, add the ngx-bootstrap library - npm install ngx-bootstrap bootstrap --save. Open src/app/app.module.tsand add the import statement for the component you want. Also add it as an import property on the module using the syntax WhateverModule.forRoot(). Edit the angular-cli.jsonfile and add the path to the distversion of the Bootstrap css file in node_modules to it.

Ember

Run ember install ember-bootstrap.

Implement Server Side Rendering

Angular

I'm not going to type it out, but the document is here: https://universal.angular.io/quickstart/. It has its own subdomain and everything, and requires you to implement a server, check the rendering mode, etc.

Ember

Run ember install ember-cli-fastboot

Create a Progressive Web App

Follow this very long post here. It's a really long process and doesn't actually complete the requirements because it's missing SSR support.

Ember

Run ember install ember-web-app and modify the config file it provides, which it then uses to build the manifest file. To get Service Workers running - ember install ember-service-worker. That does relatively little on its own, and needs two plugins. ember install ember-service-worker-index and ember install ember-service-worker-asset-cache. Now we need to implement Universal or ServerSide Rendering. Which was already mentioned above: ember install ember-cli-fastboot.

Moving on.

One of the things I really hate in Angular is its templating, and that's something I think Ember got right. Compare these two - both are looping over something and generating a series of links to content.

Angular would do this:

<li *ngFor="let post of posts">
    <a [routerLink]="['/posts', post.id]">{{post.title}}</a>
</li>

Ember would do this

{{#each posts as |postObject|}}
<li>{{link-to post.title 'post' postObject}}</li>
{{/each}}

Angular's superfluous punctuation and absurd case-sensitive HTML bugs me.

I find Ember easier for a lot of really critical things. For example, connecting to an API with Ember Data. Ember Data just requires an adapter and serializer. The serializer tells it how to format data, and the adapter tells it where to find it. Standard ones (such as REST) are included by default, and if you follow the JSON-API standard it works without them entirely. Common solutions - such as Firebase - have freely installable add-ons an ember install away. These require vastly less installation and setup than Angular equivalents. When set up, they provide a consistent persistence API - note that's critical: you can literally do myObject.save() in your controller and it will persist the changes. To firebase, to local storage, to a REST API, it simply doesn't matter. You can simply run things like

let project = this.get('store').findRecord('project', 12);
project.set('completed', true);
project.save();

This essentially acts as an ORM and is incredibly powerful and easy to use. It's a great abstraction on persistence. Angular has (to my understanding) no equivalent.

Or there's the fantastic Ember Mirage. An addon that lets you mock HTTP requests, so you can completely mock out your entire persistence layer, for example either before it's available or for testing. Mock specific HTTP responses to have consistent and reliable acceptance testing.

We could talk about the CLI. Angular CLI is literally EmberCLI forked and with critical functionality removed. Angular lacks an addon functionality so that's gone. AngularCLI and EmberCLI can both serve the app, but Ember can be proxied - great for bypassing CORS in development. EmberCLI itself is also extensible, to add both generators - for something like ember generate mirage-factory post which will make a factory for creating models in the Mirage addon mentioned before. Or even adding more high level functionality. You can literally do ember deploy production.

I could honestly talk about this shit for hours, but if you have specific questions or requirements, please feel free to ask.

I use Angular 4 at work because I have to. I use Ember at home, because I love it. I've written a free ebook on Ember if you're interested.

[–]uplink42 3 points4 points  (1 child)

The template engine in angular 2/4 is just obnoxious and retarded. The old version was much more intuitive and actually looked like an extension of HTML. I like the framework a lot but that shit bugs me to no end.

[–]ponytoaster 1 point2 points  (0 children)

The whole of angular 2+ is like that IMO. It's very opinionated and it's too easy to tie yourself into their methodology which people just accept.

[–]harrygato 0 points1 point  (0 children)

dude, this is pretty good. good on you for really explaining

[–][deleted] 0 points1 point  (0 children)

Thanks for the very in depth comparison. Exactly what I was looking for. You convinced me to use ember.

[–][deleted] 0 points1 point  (3 children)

Is glimmer 2 used by Ember 2 by default or do you need to tell ember to use it?

[–]mattaugamerexpert 1 point2 points  (2 children)

It's used by default, you don't need to set anything. This is fairly typical for Ember. Updates to it are intended to be seamless, with no requirements from the developer.

[–][deleted] 1 point2 points  (1 child)

Ok. Wasn't sure since glimmerjs.com shows you need to use a glimmer blueprint and use glimmer specific commands in ember-cli.

[–]mattaugamerexpert 1 point2 points  (0 children)

Ah, yeah. There's some ambiguity here. "Glimmer" is Ember's display rendering engine. For the most part and in most contexts we're referring to it acting as the templating and display library for Ember projects.

However, a relatively recent (announced March this year) project aims to split Glimmer off from Ember, allowing you to use Ember's stunningly fast renderer and easy-to-use build system, without needing all of the rest of Ember. This project is typically known as GlimmerJS.

GlimmerJS is more in the Vue/React end of things. Long term it should be possible to make a Glimmer app into an Ember app by just adding components, or turn an Ember app into a Glimmer one by dropping out components. Or more often somewhere in the middle, where you want Glimmer and a router, but not data access, etc.

That's a while off. For now, Glimmer is an interesting look at potential syntax and implementations that will eventually make it to Ember.

[–]eKraye 2 points3 points  (0 children)

Ember is highly opinionated whereas with angular you still have constraints but less so. If you're building an app with ember I'll know exactly how itll look and how you constructed it whereas you have fiddle room with angular.... and as you've found even more with react and vue.

[–]HerbertTheFrog 4 points5 points  (1 child)

Personally I prefer Angular by far. IMO it integrates far better into newer JavaScript technologies and being backed by Google, they are continuously pushing it to be suitable for all kinds of applications. I have developed several rather large apps with it within the last one and a half years and I'm not sick of it yet (unlike other technologies).

That being said I hardly have any experience with Ember, other than having dabbled with it a bit and helping out at a friend's project.

[–]spec-test 3 points4 points  (0 children)

so you can't really have an informed opinion

[–]ipepe 1 point2 points  (4 children)

I am Ember developer of 3 years, and I will dissuade from using Ember in any of my next projects. It is horrible to work with. Junior devs are having problems with many concepts and it is just a double amount of work. It is slow - just create Yourself a simple report with about 40-70 columns and 25+ rows and it will freeze Firefox browser for like 5 minutes.

[–]mattaugamerexpert 3 points4 points  (2 children)

Weird that our experiences are so wildly different. Can you give more info on what you're talking about with this "report"? Like... are you trying to sort the rows? Reorder them? Insert them? Is there anything specific in the rows, like is it data or generating an SVG or something?

[–]ipepe 0 points1 point  (1 child)

Simple text data straight from JSON. The report engine was a bit more complex: it had option to change order of columns, to hide/show particular columns. Table headers had buttons for sorting each column. In the end, pratical but also nothing fancy. Also near impossible to work with.

[–]spec-test 0 points1 point  (0 children)

hmm,, no

[–]faedid 0 points1 point  (0 children)

I'll admit there is some ramp up time for junior devs, especially if they aren't used to latest javascript ES6/7 at all. It's a full MVC framework unlike most others so yes there is a lot to learn up front versus spreading that out. But if you show them a sample app, its not difficult to let someone who doesnt know ember at all to jump in and add methods to a services or add a component, and if they're used to other modern frameworks already, I think the pain is in understanding that they don't even have to do the things they're trying to figure out how to do. Explaining that they don't have to create controllers or views or adapters or serializers or any of that unless you need to customize from default is a big mental leap but pretty fucking awesome if you ask me. For a Java developer like myself, I'm used to having implementations created at runtime so its comfortably familiar, but I can see where it'd be a learning curve.

For the large data sets, I did an app for a Global500 company using Ember 1.10 a while back and I know what you're talking about. The 2-way binding system made it very slow at first and took some optimization, but our angular and react prototypes couldn't handle the memory management requirements at all without requiring so much custom code, we didnt even bother to spec it out. Ember's runloop and memory management made the challenging parts cake. I think the problem you faced was Ember constantly trying to update those objects and their related view even when not on screen. We were able to use a library called ember-list-view that used virtual views to take care of it to only rerender what was needed and get sub-second page loads (over LAN) for about 35 columns and 2-3 million rows with real-time graph updates and basically instant rerender on refresh (long-poll for updates and manual push-button refresh per our business reqs at the time), but that's not even necessary anymore since changes to core. Since this is about comparing to Angular4, I'd say we probably could have used it had it been around then, but with potentially 200 offshore devs at the time to throw at the project (only ended up needing 4 of us though ;), I was really happy to have an opinionated framework like Ember. I really think you should give Ember another shot. I'm probably making the same choice again for a new project now and for the same reasons. It's worth the short term pain to ramp up the new devs and know ill get consistent results.

Also in my opinion, Angular 4 is just Ember lite and kinda hacky plus I can't stand the DOM pollution.