
AngularJS from an Ember.js perspective - tomdale
https://docs.google.com/a/tomdale.net/presentation/d/1e0z1pT9JuEh8G5DOtib6XFDHK0GUFtrZrU3IfxJynaA/preview
======
gregwebs
This is the only intelligent comparison I have seen of Ember & Angular (or
actually of Angular with any other modern framework). Thanks!

I am wondering if the uniform access principle is mostly a dynamic language
issue: you end up screwing up whether you need a parentheses invocation and
you don't know until runtime. If you type everything with TypeScript then you
know at compile time if you messed it up. Relatedly, Ember's get/set is more
difficult to make strongly typed. In the TypeScript definitions I am looking
at, property access is only typed as a string. One could define an enum for
each object to be used in place of the string, but overall there is a price to
pay with set/get since it isn't baked into the language (like Ruby).

~~~
emn13
I think the uniform access principle is misguided (or at least misconstrued).
It's a bad idea... in general. If you're building an API and you have need
some kind of stable, unchanging interface to expose - then it makes sense.

But people are using it everywhere in their programs; and it's not really
valid there. First of all, data-access is _fast_ and computed functions may be
slow. Hiding this difference means that writing efficient code becomes more
tiresome - you need to consider each and every access as potentially
expensive, even though the majority are probably trivial. This means you need
to know the code better to get anywhere. And if you make it hard to write
efficient code, people won't bother (and rightly so, since that's usually
premature optimization).

Secondly, in most languages, simple data access is side-effect free and
(usually) thread-safe or at least has predictable threading behavior. Managing
side-effects - even without threading - is a major pain in any large code
base, and although functional purity can be enforced otherwise in some
languages, in most cases you've got nothing to go on. Making your life more
difficult by discarding annotations that distinguish between method calls and
member access isn't helping.

Of course, in a dynamic languages you're in a tricky spot here - it's hard to
refactor, so exposing member access is something that's more work to change
later when you discover you need computation or a side effect. However, even
so; making a system harder to reason about for the purpose of a fairly
pointless architectural purity is usually a bad idea.

The uniform access principle as applied to interfaces is another story; but in
general use - I think it sounds nice in theory, but works poorly in practice.

~~~
pcwalton
JavaScript hasn't had simple data access for a long time if ever. Computed
properties have been widely supported for a long time, there's "watch" [1],
and of course there's the prototype chain. ES6 adds proxies, which makes
practically everything you might want to do with an object potentially have
custom behavior. IMHO, in JavaScript you might as well respect the uniform
access principle, since "a.b" meaning simple data access has arguably never
existed.

[1]: [https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Reference/Global_Objects/Object/watch)

~~~
emn13
Since code could be self-modifying; clearly simple-data access has never been
a guarrantee.

But in practice, today as ever, it's a good guideline. When you see an
accessor, it will almost always be fast and side-effect free.

Now, part of that is because not all browsers support the features you refer
to and therefor these features just don't get used much. But even in languages
like C# and python, that have had real accessors for a long time, it's still a
good guideline: it's generally considered bad practice to make a slow, side-
effectful accessor, and most people don't.

Controlling side effects and performance are important, and the uniform access
principle has little upside in most non-public code, yet considerable cost in
that it obscures one of the few indicators mainstream languages have for these
aspects.

------
sailfast
Having just dug into Angular while wondering if I really wanted to be working
with Ember, this was a great comparison. It's obvious to me now I have to look
at both frameworks. While done by an Ember.js creator I found the presentation
also provided me with a much deeper knowledge of Angular at the same time -
well done.

As for the Google popularity, one could snidely remark that Angular's
documentation and taxonomy requires significant amounts of searching to solve
the problems you are after. While the community is active, it's quite
difficult to find examples of the right solution or effective documentation
for newbies at times.

~~~
machty
I just added this to the slides (ran out of time to prepare/say all the things
I wanted to), related to Google popularity:

\- A toolset’s mindshare is predictably going to be greater than that of a
framework

\- Angular interest (per Google) dwarfs Ember; jQuery interest dwarfs Angular,
etc

\- Angular encourages you to build the framework; Ember is the framework

~~~
bib971
What do you mean "Angular encourages you to build the framework"? What kind of
framework?

~~~
steveklabnik
The answer is in the deck.

[https://docs.google.com/a/steveklabnik.com/presentation/d/1e...](https://docs.google.com/a/steveklabnik.com/presentation/d/1e0z1pT9JuEh8G5DOtib6XFDHK0GUFtrZrU3IfxJynaA/preview#slide=id.g177e4bd2b_0192)

~~~
veemjeem
it is also on slide 53

------
Bognar
I hate that Google Docs modifies your history when you go to the next slide.
This presentation clocks in at 57 slides and Firefox history defaults to
truncating after 50 entries, meaning I can only go back to slide 7 and not
back to HN.

Is it really better that I can use my browser forward and back buttons to
navigate slides? Especially when there are forward/back buttons on the
presentation anyway?

~~~
steveklabnik
I personally enjoy this aspect, as I think it fits the philosophy of the web
better. Each slide has an address, because they're separate things. You can
also trivially link to a particular slide this way.

I open articles in new tabs, so the going back to HN part hasn't ever affected
me.

~~~
Already__Taken
Each slide should have an address yes but I don't think everything should push
do your history stack.

That Git cheat sheet page the was on HN a few days ago. Every time you changed
the command it pushed onto your history. I want to click back to HN not back
and forth between 2 commands I switched across 6 times.

I was going to comment then but I don't think the site was using push state it
is actually browser behaviour.

~~~
taude
I just open all articles (and all HN comment threads) in new tabs. Sometimes I
don't even get to them after scanning the front-page for awhile.

------
tomphoolery
I _really_ liked this. Although I prefer to work with Ember.js, Emblem and
EmberScript (as the latter addresses some of Ember's syntactical faults),
Angular seems very interesting when you view it as more of a toolset for
building your own framework than a "complete" framework in and of itself.

When you bring the _entire_ Ember toolchain into the mix, outside of the
already-complete framework, it begins to smooth Ember's rough edges in
development. It's just the same with Rails, I'm a Ruby developer and we're
used to dealing with dependencies already, so it's not really a huge leap
outside the box for us to be using tools that will compile down to
HTML/CSS/JavaScript to build the frontend to a Rails backend API application.

I still understand Angular as a toolchain/framework/whatever for people who do
not understand JS to the point where they want to begin extending it. Angular
is a "safe zone", something that frankly JavaScript as a language (without
Ember's additions to the object model and such) needs right now. When you
write apps in Ember, I feel like a deeper understanding of how JS is working
is necessary before you begin to abstract that portion away. Is this still a
correct assumption to have? I'm not trying to insult anyone, frankly JS is a
pretty screwed up language so I feel like it's a natural tendency to want to
just get what you need out of it quickly and safely and then move on to more
fun projects. In my opinion, it's simply a different way of doing things, not
better and not worse.

------
chidevguy
One thing that I like about Knockout is that you can easily drop it into a
legacy site, allowing you to have some pages that use it and others that
don't. Forgive my naivete, but is this something that is easy to do with Ember
or Angular as well?

~~~
adambard
Angular yes, Ember perhaps not. I this wrote briefly on the subject recently:
[http://adambard.com/blog/angular-in-the-
small/](http://adambard.com/blog/angular-in-the-small/)

~~~
bcardarella
Angular definitely not.

~~~
lhorie
I've been working on porting mission critical parts of a 10-year-old+ app over
to Angular; some of the syntax is clunky but it's definitely doable

------
paulftw
Kudos to the author - I am impressed how well Alex Matchneer understands
Angular.

Few thoughts of my own: \- Ember is a long term relationship with one
particular way of doing web FE, a way invented by someone else for you. Ember
philosophy is "one size fits all". \- On directives and transclusion - it's
like Lisp's dotted pair. these new concepts may be hard to understand, but
experiments like that often fascinate programmers, and for a good reason - one
day those experiments will revolutionize the way we build software.

The debate of a small set of flexible tools vs one tightly integrated system
is not new. We had Linux vs Windows, Django vs Flask, etc. It's funny to see
it pop up in yet another area.

Thank you for this great write up and raising a bar of this long going
discusiion on Ember vs Angular.

------
hpvic03
I've been working with Ember for a while now, and I love it. Convention over
configuration is a big deal, and the Ember team has done it right. I think if
you like Rails then you'll like Ember.

------
atjoslin
I use angular a ton, and just learned more about Ember from this. thanks. I'll
have to check it out someday. Ember looks like it has good testing now too :-)

------
wereHamster
People really like googling angular

That could also be because angular has horrible documentation!

------
virtualwhys
That was a really informative comparison, kudos to the Ember author for
injecting minimal bias.

I've been on the fence about switching from jQuery + Coffeescript to
Angular/Ember/etc.

Still am, bit of a server-side luddite here, AJAX, client-side form
validation, some jQuery effects for dropdown menus, show/hide layers, etc. is
as far as I go.

------
jemptymethod
Do we really need either Angular's or htmlbars' (see slide 37) way of
"decorating DOM elements with behavior" when it is so trivial with just ES5
and HTML? See this jsfiddle:
[http://jsfiddle.net/dexygen/nU8VK/](http://jsfiddle.net/dexygen/nU8VK/) Give
me a couple/three strong JS devs and I guarantee you I could take these simple
building blocks (as well as spans with data- attributes, and innerHTML,
instead of templates), and I could build out a framework way faster than
either Angular or Ember.js and would validate as HTML5 to boot. Doubt me? I
pretty much did the same thing for PHP; see
[http://dexygen.com/ria/#!/docs/jackrabbitmvc](http://dexygen.com/ria/#!/docs/jackrabbitmvc)

------
Banzai10
So technically what the presentation is trying to say is that you should use
Angular to build Ember like framework. hahah

I personally like Angular, the Google support and the community are strong
points to it. The documentation used to be hard to find, but now, specially
with StackOverflow, finding what you need is easy.

~~~
bcardarella
I don't think relying on Stack Overflow is a good solution for lack of good
library documentation.

~~~
cjcenizal
Why not? It _is_ a good solution for lacking good library documentation.

------
dsego
This format sucks, I can't click on jsfiddle links or even copy them.

~~~
machty
I just linkified everything, should be good now

~~~
dsego
Great job, thank you.

------
Bahamut
I enjoyed reading this, as a heavy Angular user & someone interested in trying
out Ember sometime. Thanks!

