

Ask HN: Aren't Ember and Angular a "wrong" kind of framework, similar to J2EE? - aartur

I&#x27;m looking at the new wave of Javascript frameworks (Backbone, Ember, Angular)
and can&#x27;t shake the feeling they are much more similar in style to J2EE than to
more saner Rails or Django. They take you out of control of your code - they
call you and you must fit their world view. They are &quot;everything&quot; and &quot;nothing&quot;
at the same time - they offer you &quot;everything&quot; to build a web app, but at the
same time it&#x27;s hard to say what concrete functionality they really offer. There is little &quot;meat&quot; inside their code: it&#x27;s just an abstract model that you MUST work with.<p>Compare it to Django where in view functions you can do whatever you want - you
are in control of what&#x27;s happening, and functionalities you need are available
as &quot;library style&quot; calls. Can&#x27;t Javascript frameworks work like that?<p>I&#x27;m asking the question because these frameworks receive much praise nowadays
with little to no critique, so maybe my all-or-nothing-framework hate (I began
career as J2EE programmer) is inappropriate here.
======
brianchu
It's really hard to answer this question when Backbone is lumped together with
Angular and Ember. What Backbone offers is a light layer of structure over
your code. Yes, it doesn't give you much, but I believe its sole purpose is to
avoid the jQuery spaghetti that forms once you start writing more than 100-200
lines of JavaScript. Backbone doesn't give you many opinions, but I personally
agree with you in that Backbone gives you a few opinions (not many), but not
enough meat to justify those few opinions. It's basically a guideline as to
how to structure different components of your app and how to communicate and
share data between components. That being said, as far as I'm aware, you can
more or less do anything you want to the DOM in Backbone Views. And Backbone
certainly does offer some features: routing, an event system, and a data
syncing system.

Backbone is probably several times less restrictive and controlling than
something like, say, Ember or Angular. I've only used Angular, so let me
comment on that. I think Angular definitely offers some powerful features that
justify its structure. Two-way data binding, a system for reusable components
(directives), a structure for organizing animations, a system for managing
data from RESTful APIs, a full testing scaffold/system, etc. _It 's not
uncommon for jQuery and even Backbone apps that are rewritten in Angular to
cut their codebase >2x._

I've heard that Ember is even more restrictive/opinionated than Angular, and
perhaps it is more powerful as a result - I don't know. I've been satisfied
with Angular.

That being said, there are tradeoffs for using frameworks. For example, you
should only do DOM manipulation inside Angular directives. Honestly I think
this is a positive, due to various powerful structural features of directives
(reusability, modularity, customizability), but for some this can be a
negative.

Moreover, because these frameworks are just contained in JavaScript files, you
can selectively apply these frameworks, where necessary, to different parts of
your web sites.

Ultimately, I think frameworks like Angular or Ember _are_ as restrictive
_and_ as powerful as frameworks like Rails and Django. Backbone would be like
Flask or Sinatra.

~~~
aartur
> What Backbone offers is a light layer of structure over your code.

It is strange to me implement a design pattern as concrete code. It's like
implementing MVC pattern as "Model" "View" and "Controller" classes and
forcing everyone using MVC to use your code package. Design patterns are
knowledge and are not in 1:1 relation with code.

~~~
blktiger
I kind of think of backbone.js as a set of patterns to write your code in, but
then someone went in and abstracted the common pieces out so you don't have to
reinvent the wheel.

A simple example is the Backbone Events module. Sure, you could wire up your
own event handling code, but why would you want to? Using a common library
like backbone means that all of the bugs are fixed in a common place and you
don't have to worry about it.

------
lstamour
Don't forget to have a look at HTML5 Web Components e.g. Dart's Web UI.
[http://www.dartlang.org/articles/web-
ui/](http://www.dartlang.org/articles/web-ui/)

I'd say that, being simply linked HTML5, CSS and JS, is about as lightweight a
view-controller system one can build. It's like a Rails/Django where you can
skip the ERB, because it's all HTML. Personally, I can't wait for it to catch
on (and get refined with further implementations and bug fixes, particularly
for server-side, progressive enhancement or non-JS approaches).

For pure JS, have a look at Polymer. [http://www.polymer-
project.org/](http://www.polymer-project.org/) (Dart's looking at using most
of this itself in future, perhaps AngularJS 2 and Ember will follow...)

~~~
X4
hah, yeah I agree with lstamour, that's what I wanted to link too.
WebComponents are THE HIT! I translated many W3C specs into German some months
ago for a friend's thesis and these people literally know the future of the
web.

Comparing today to what is possible with WeComponents and CORS and WebRTC is
like comparing the Stone Age with 2045. Ok enough enthusiasm, now let's all
get back to work again.

~~~
lstamour
Good news. Polymer.dart continues the Polymer web components goodness, more
closely following the standard:
[https://groups.google.com/a/dartlang.org/forum/#!topic/web-u...](https://groups.google.com/a/dartlang.org/forum/#!topic/web-
ui/6laXXxRtA7k)

------
joeldidit
(Slightly related..) I like AngularJS, but I very strongly disagree with the
idea of the one page app. I don't know what else to say. It just seems wrong.
Javascript was meant to make the page more dynamic and responsive, not take
over the entire experience and (possibly) slow everything down. It's supposed
to be a layer, not everything.

------
markchatkhan
These days it's all about modularizing and separating concerns.

Angular let's you create a front-end completely decoupled from a backend and
backend agnostic.

Angular is also in fact completely agnostic about your model. You can plug in
any kind of model as long as you can parse it in javascript.

With this kind of architecture, it's a lot easier to do things like re-use a
backend for multiple front ends, for example a mobile-site and a desktop site
and a native iOS app and a blackberry app. It's also easier to maintain and
change each individual piece.

JS frameworks are only a front-end though, you also need to adapt your backend
into a modern API style, rather than a html spitter-outter.

~~~
aartur
> Angular is also in fact completely agnostic about your model. You can plug
> in any kind of model as long as you can parse it in javascript.

Why Angular has to know my model? I can make it decoupled from other parts of
my code by using standard programming techniques available for many years
(modularity, layers etc.).

Maybe the problem is that Angular actually implements design patterns as code,
and it should be just knowledge?

~~~
lstamour
It might be easier to conceptually think of these view-binding models as "View
Models" or presenters. A longer article I plan to read on the subject is
[http://msdn.microsoft.com/en-
us/magazine/hh580734.aspx](http://msdn.microsoft.com/en-
us/magazine/hh580734.aspx)

------
zcrar70
J2EE was very verbose - both Ember and Angular make it a key priority to make
it quick and easy to do very powerful things.

However, I agree with some of your premise. Both Angular and Ember have very
opinionated and restrictive world-views. That's what allows them to create an
environment where you can do great things quickly. But it also makes it harder
to create things that don't fit into that world-view.

------
rektide
Frameworks help you build a system on top of the web. Rails and Django are
systems underneath the web.

Building up or building down, none of these technologies are inherently web
themselves, they are their own self-establishing bias.

Look at Polymer or Custom Elements if you are interested in building web
technologies that are themselves truly of the web.

~~~
lstamour
And now, Polymer.dart ;-)
[https://groups.google.com/a/dartlang.org/forum/#!topic/web-u...](https://groups.google.com/a/dartlang.org/forum/#!topic/web-
ui/6laXXxRtA7k)

------
bmm6o
Comparing JS libraries with web server frameworks is pretty apples-to-oranges,
first of all. But MVC frameworks pretty much have to be "everything". Can you
use a desktop UI library without going with it completely?

~~~
joefiorini
Further, who has ever advocated for building desktop apps _without_ a
framework? The comparison of client-side frameworks to server-side frameworks
is the wrong comparison. If I'm going to build a sufficiently complex Mac app
I'm going to use Cocoa, no question. If I just need to automate something and
don't necessarily need a UI, I may look at AppleScript or even a simple shell
script.

This is more of an apt comparison for web front ends. The choice of Backbone
(or, in my case something that provides a little more value like Flight) vs.
Ember/Angular is like choosing to build a CLI app vs. a full-on desktop app.

There are perfectly valid reasons for choosing either and in the right
context, the right tool is worth its weight in gold.

------
factorialboy
I think Angular is pretty declarative and doesn't do any "magic" unless you
ask it to.

Can't say the same about Ember though.

