Ask HN: Aren't Ember and Angular a "wrong" kind of framework, similar to J2EE?
8 comments
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.
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.
> 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.
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.
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.
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.
Don't forget to have a look at HTML5 Web Components e.g. Dart's 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/ (Dart's looking at using most of this itself in future, perhaps AngularJS 2 and Ember will follow...)
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/ (Dart's looking at using most of this itself in future, perhaps AngularJS 2 and Ember will follow...)
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.
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.
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...
(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.
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.
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.
> 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?
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?
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
The client model does not have to be the server model, and it probably shouldn't.
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.
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.
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.
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.
And now, Polymer.dart ;-) https://groups.google.com/a/dartlang.org/forum/#!topic/web-u...
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?
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.
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.
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.
Can't say the same about Ember though.
Compare it to Django where in view functions you can do whatever you want - you are in control of what's happening, and functionalities you need are available as "library style" calls. Can't Javascript frameworks work like that?
I'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.