6 ms·

Your latter two points are odd since they are directed at Angular when they can be used to describe literally every frontend framework ever created. The third p

Your latter two points are odd since they are directed at Angular when they can be used to describe literally every frontend framework ever created. The third point, in particular, is fundamentally what a framework does... it does some "magic" in the background to prevent you from HAVING to understand what's going on in the background. The second point is one of the tired pieces of non-sense that seems to never go away. Their was NOTHING wrong with the Angular 1.x approach to web development, because it started some time before the initial release in 2009. A proper warning for anyone learning AngularJS should be a warning for any frontend framework: * Much of the code abstracts away the DOM and some Javscript nuances, so don't expect learning a front-end framework to be the same as learning JS (In the same way that learning Rails is not learning Ruby). * All client-side frameworks take somewhat different approaches, and often use new terminology to explain that approach. This does not necessarily translate from one framework to another, but can. * Angular 2, an in-development long-term replacement for Angular 1 uses a very different approach to development, and will not translate well from 1.x to 2.x. However, Angular 2 is a modern-browser only framework, and the 1.x will be developed for the foreseeable future.

lhorie 12y ago
> Your latter two points are odd since they are directed at Angular when they can be used to describe literally every frontend framework ever created. I disagree. There are abstractions whose knowledge is easily transferable (e.g. promises, looping through a list of DOM elements), and abstractions that are not (e.g. directives/transclusion/$compile/etc). Angular is notorious (and has received a lot of flak) for having a lot of the latter, so I think the non-portability/magic warnings are warranted.
- debaserab2 12y ago
  When have you ever picked up code that was written as an integral part of an application using a framework (not just a library) and dropped it into another completely different one without a fair amount of re-work?
  - hippich 12y ago
    Short answer - more often, than I could do it with angular code :) This is personal anecdote of course.
    - jhall1468 12y ago
      What's the long answer? I think it's laughable to say that you can take a part of a monolithic framework and drop it in as a replacement in a different framework. Actually a short answer will do fine. Ignoring Backbone, name ONE part of a major framework you can do that with?
      - hippich 12y ago
        very short answer - backbone. longer answer - there is rarely drop in replacement, but when framework uses other well designed technologies, instead of reinventing the wheel, knowledge about these technologies way more useful, than knowing details and gotchas of $digest loop. Examples: * handlebars templates used in many frameworks. Quite often you can literally copy templates over into new project. * usage of real promises allows you to use chai async tests without looking back at framework, instead of relying on right timing of firing $apply() (and making sure to not call it twice!) * not relying on dirty-checking, and instead use setters/getters quite often forces you to think and isolate model code from glue. * describing state via html (as it is proposed with ui.router - very popular component) can not be easily migrated at all, since most of frameworks define state in code and/or configs. This is paradigm shift. While I agree, the bigger framework, harder it gets to write portable code, but angular in practice tends to make it even harder in my experience.
        jhall1468 12y ago
        So basically, your problem is you like to pick and choose modular pieces from non monolithic frameworks and "Angular sucks" because it doesn't do what you like. There's nothing wrong with Backbone, particularly when you like to replace parts with other parts. But Angular is not bad simply because modularity wasn't a design goal. It's notable that your arguments aren't arguments against Angular persay but against every single non-modular framework ever made. I don't mind people disliking Angular. I mind it when people pretend their preconceived notions about software design are "right" and software that doesn't align with their notions are "wrong".
hippich 12y ago
There are different "level" frameworks are out there. Ember/Knockout/Angular gives you a lot of magic. Backbone - not so much. Most concepts in Angular came from Spring Java (server-side, one request at a time,) which is absolutely unique to client-side frameworks world at this time. Reason behind this is very likely that Misko himself was server-side engineer at Sun before coming up with Angular, and he invented framework without working with other client-side frameworks, so he could not learn from their mistakes. So these specifics are not transferable to other client-side framework. Moreover - this knowledge likely will not be transferable to Angular 2.x too.
- tegeek 12y ago
  You are completely wrong on your assumption when you are linking AngularJS's origin to Server-Side Java. Most of concepts in AngularJS directly came from Silverlight and WPF. Before even Angular came into existence, I used to use the same pattern for building Windows/Browser centric client side apps on WPF/Silverlight. When AngularJS announced in 2009, it took me 30 minutes to get my head around everything & there has not been much changes since then. The only thing AngularJS invented was Dependency Injection for JS.
  - hippich 12y ago
    If memory serve me well, WPF and Silverlight were brought around 2007-2008 by microsoft. Angular was released around 2009. Spring Framework in 2002. Misko was Sun employee and worked with Spring a lot and mentioned it a lot. I did not find any reference to silverlight and or wpf in his talks/posts so far. Next - I am not saying that idea of applying server-side mvc patterns as-is is unique, it is certainly not - your example of wpf and silverlight are good examples. Also, probably, reason why these did not stick well outside corporate environment, where decisions are made by managers and not people actually having to deal with it. If you have solid source explaining origin of angular - i will be happy to be corrected, but from everything i read so far to understand better motivation behind sometimes very questionable decisions I always find similarities between sun/java/spring.
randomdrake 12y ago
> Your latter two points are odd since they are directed at Angular when they can be used to describe literally every frontend framework ever created. I'm going to wager you haven't used, or are even aware of, "literally every frontend framework ever created," so we can agree you're being hyperbolic. There are plenty of front end frameworks that utilize JS, HTML, and little else, without introducing "magic" or vocabulary that isn't applicable. I agree with the OP that Angular, in particular, has a great deal of vocabulary to learn and a lot of things that are only applicable in the Angular world. This is one of the main reasons that I, and many other folks, have not spent much time with it. > The third point, in particular, is fundamentally what a framework does... it does some "magic" in the background to prevent you from HAVING to understand what's going on in the background. Just because you don't take the time to understand what's going on the background, doesn't mean the framework is "preventing" you from you having to understand what's going on in the background. Au contraire, we hear stories over and over about how the "magic" introduced by a framework caused issues that actually required knowledge of what's going on in the background. This isn't the fault of the framework, or the goal of the framework, it's a fundamental part of software development. For what it's worth, you're contradicting yourself by saying that "literally every framework ever created" applies to the OP's points, yet concede in your own point that "This does not necessarily translate from one framework to another, but can." Frameworks get in your way only as much as you let them. The underlying technologies are still there. > In the same way that learning Rails is not learning Ruby Learning Rails is a perfectly fine way to be introduced to Ruby. You're learning syntax, constructs, philosophies, and you can break out of Rails and do things with Ruby at any time. I mean, what do you think you're writing Rails code in? When learning to counter an argument, its best if you don't reiterate all of the points they made in some other way. You basically repeated all of their points, but I don't know if you're aware of it. OP: > This is Angular 1.x course. Angular 2, which is in the development right now, totally different. Your point: > Angular 2, an in-development long-term replacement for Angular 1 uses a very different approach to development, and will not translate well from 1.x to 2.x OP: > Much of the code abstracts away the DOM and some Javscript nuances, so don't expect learning a front-end framework to be the same as learning JS Your point: > Knowledge you learn from using Angular is unlikely to be applicable to any other client-side framework, as original creators invented many new terminology as well as their approach to many things is unique OP: > A lot of "magic" will prevent you from understanding what is really going on behind scene. Your point: > Much of the code abstracts away the DOM and some Javscript nuances, so don't expect learning a front-end framework to be the same as learning JS I'd be interested to hear some valid counterpoints to the OP, since I tend to agree with them, but these don't appear to be them.
pcthrowaway 12y ago
In the process of learning Backbone using Addy Osmani's excellent guide (http://addyosmani.github.io/backbone-fundamentals/ http://addyosmani.github.io/backbone-fundamentals/) as well as reading the heavily annotated Backbone source code (http://backbonejs.org/docs/backbone.html http://backbonejs.org/docs/backbone.html), I've learned a lot about javascript, the problems SPA frameworks have to solve, common patterns for solving those problems, and how they can be implemented. Before backbone, I tried my hand at angular and stopped when I realized the only understanding I was going to gain by learning Angular was how to use Angular. It's a very different kind of beast.
- cw0 12y ago
  I previously had no interest in Backbone but those are absolutely amazing learning resources.

lhorie 12y ago

> Your latter two points are odd since they are directed at Angular when they can be used to describe literally every frontend framework ever created. I disagree. There are abstractions whose knowledge is easily transferable (e.g. promises, looping through a list of DOM elements), and abstractions that are not (e.g. directives/transclusion/$compile/etc). Angular is notorious (and has received a lot of flak) for having a lot of the latter, so I think the non-portability/magic warnings are warranted.

debaserab2 12y ago
When have you ever picked up code that was written as an integral part of an application using a framework (not just a library) and dropped it into another completely different one without a fair amount of re-work?
- hippich 12y ago
  Short answer - more often, than I could do it with angular code :) This is personal anecdote of course.
  - jhall1468 12y ago
    What's the long answer? I think it's laughable to say that you can take a part of a monolithic framework and drop it in as a replacement in a different framework. Actually a short answer will do fine. Ignoring Backbone, name ONE part of a major framework you can do that with?
    - hippich 12y ago
      very short answer - backbone. longer answer - there is rarely drop in replacement, but when framework uses other well designed technologies, instead of reinventing the wheel, knowledge about these technologies way more useful, than knowing details and gotchas of $digest loop. Examples: * handlebars templates used in many frameworks. Quite often you can literally copy templates over into new project. * usage of real promises allows you to use chai async tests without looking back at framework, instead of relying on right timing of firing $apply() (and making sure to not call it twice!) * not relying on dirty-checking, and instead use setters/getters quite often forces you to think and isolate model code from glue. * describing state via html (as it is proposed with ui.router - very popular component) can not be easily migrated at all, since most of frameworks define state in code and/or configs. This is paradigm shift. While I agree, the bigger framework, harder it gets to write portable code, but angular in practice tends to make it even harder in my experience.
      - jhall1468 12y ago
        So basically, your problem is you like to pick and choose modular pieces from non monolithic frameworks and "Angular sucks" because it doesn't do what you like. There's nothing wrong with Backbone, particularly when you like to replace parts with other parts. But Angular is not bad simply because modularity wasn't a design goal. It's notable that your arguments aren't arguments against Angular persay but against every single non-modular framework ever made. I don't mind people disliking Angular. I mind it when people pretend their preconceived notions about software design are "right" and software that doesn't align with their notions are "wrong".

hippich 12y ago

There are different "level" frameworks are out there. Ember/Knockout/Angular gives you a lot of magic. Backbone - not so much. Most concepts in Angular came from Spring Java (server-side, one request at a time,) which is absolutely unique to client-side frameworks world at this time. Reason behind this is very likely that Misko himself was server-side engineer at Sun before coming up with Angular, and he invented framework without working with other client-side frameworks, so he could not learn from their mistakes. So these specifics are not transferable to other client-side framework. Moreover - this knowledge likely will not be transferable to Angular 2.x too.

tegeek 12y ago
You are completely wrong on your assumption when you are linking AngularJS's origin to Server-Side Java. Most of concepts in AngularJS directly came from Silverlight and WPF. Before even Angular came into existence, I used to use the same pattern for building Windows/Browser centric client side apps on WPF/Silverlight. When AngularJS announced in 2009, it took me 30 minutes to get my head around everything & there has not been much changes since then. The only thing AngularJS invented was Dependency Injection for JS.
- hippich 12y ago
  If memory serve me well, WPF and Silverlight were brought around 2007-2008 by microsoft. Angular was released around 2009. Spring Framework in 2002. Misko was Sun employee and worked with Spring a lot and mentioned it a lot. I did not find any reference to silverlight and or wpf in his talks/posts so far. Next - I am not saying that idea of applying server-side mvc patterns as-is is unique, it is certainly not - your example of wpf and silverlight are good examples. Also, probably, reason why these did not stick well outside corporate environment, where decisions are made by managers and not people actually having to deal with it. If you have solid source explaining origin of angular - i will be happy to be corrected, but from everything i read so far to understand better motivation behind sometimes very questionable decisions I always find similarities between sun/java/spring.

randomdrake 12y ago

> Your latter two points are odd since they are directed at Angular when they can be used to describe literally every frontend framework ever created. I'm going to wager you haven't used, or are even aware of, "literally every frontend framework ever created," so we can agree you're being hyperbolic. There are plenty of front end frameworks that utilize JS, HTML, and little else, without introducing "magic" or vocabulary that isn't applicable. I agree with the OP that Angular, in particular, has a great deal of vocabulary to learn and a lot of things that are only applicable in the Angular world. This is one of the main reasons that I, and many other folks, have not spent much time with it. > The third point, in particular, is fundamentally what a framework does... it does some "magic" in the background to prevent you from HAVING to understand what's going on in the background. Just because you don't take the time to understand what's going on the background, doesn't mean the framework is "preventing" you from you having to understand what's going on in the background. Au contraire, we hear stories over and over about how the "magic" introduced by a framework caused issues that actually required knowledge of what's going on in the background. This isn't the fault of the framework, or the goal of the framework, it's a fundamental part of software development. For what it's worth, you're contradicting yourself by saying that "literally every framework ever created" applies to the OP's points, yet concede in your own point that "This does not necessarily translate from one framework to another, but can." Frameworks get in your way only as much as you let them. The underlying technologies are still there. > In the same way that learning Rails is not learning Ruby Learning Rails is a perfectly fine way to be introduced to Ruby. You're learning syntax, constructs, philosophies, and you can break out of Rails and do things with Ruby at any time. I mean, what do you think you're writing Rails code in? When learning to counter an argument, its best if you don't reiterate all of the points they made in some other way. You basically repeated all of their points, but I don't know if you're aware of it. OP: > This is Angular 1.x course. Angular 2, which is in the development right now, totally different. Your point: > Angular 2, an in-development long-term replacement for Angular 1 uses a very different approach to development, and will not translate well from 1.x to 2.x OP: > Much of the code abstracts away the DOM and some Javscript nuances, so don't expect learning a front-end framework to be the same as learning JS Your point: > Knowledge you learn from using Angular is unlikely to be applicable to any other client-side framework, as original creators invented many new terminology as well as their approach to many things is unique OP: > A lot of "magic" will prevent you from understanding what is really going on behind scene. Your point: > Much of the code abstracts away the DOM and some Javscript nuances, so don't expect learning a front-end framework to be the same as learning JS I'd be interested to hear some valid counterpoints to the OP, since I tend to agree with them, but these don't appear to be them.

pcthrowaway 12y ago

In the process of learning Backbone using Addy Osmani's excellent guide (http://addyosmani.github.io/backbone-fundamentals/ http://addyosmani.github.io/backbone-fundamentals/) as well as reading the heavily annotated Backbone source code (http://backbonejs.org/docs/backbone.html http://backbonejs.org/docs/backbone.html), I've learned a lot about javascript, the problems SPA frameworks have to solve, common patterns for solving those problems, and how they can be implemented. Before backbone, I tried my hand at angular and stopped when I realized the only understanding I was going to gain by learning Angular was how to use Angular. It's a very different kind of beast.

cw0 12y ago
I previously had no interest in Backbone but those are absolutely amazing learning resources.