Learn AngularJS
codecademy.com
codecademy.com
* This is Angular 1.x course. Angular 2, which is in the development right now, totally different.
* 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 (not necessarily in a good way)
* A lot of "magic" will prevent you from understanding what is really going on behind scene.
The other two arguments are actually not in favor of the point you are trying to make. For beginner wanting to just have something awesome working, Angular is a perfect way of getting hooked. Sure, for senior JS developers learning Angular is perhaps not the best move - it is very isolated, built on assumptions suited mostly for small websites and, as you said it, "magic". Those are the reasons why Angular 2 is so different.
What are your arguments for claiming that?
https://www.youtube.com/watch?v=cVTN8msr5DE&list=PLOETEcp3Dk...
And yes, it looks _simple_ that's the point. You don't want a bloated client, you architect a solution to only load what needs to be load. If your app is 25 MB you don't want to send ALL that to your client in one go. Watch the video please.
This proved to be more complicated than it should have been and I am looking to see real app in action to view code and learn from it. Paying (or becoming trial user) is not part of what I want to do to learn from that :)) That's why I was asking where actual app I can touch resides, if it is possible to try it without submitting my credit card details :)
You need to learn about asset management. Take a look at webpack for example: http://webpack.github.io/
In the video they explain the strat behind how they managed to make a big app load only the necessary parts. With that, and some researching on your part should be enough to get you on the right track.
In any case, your argument doesn't hold. It isn't only for small apps. ;)
Strategy is easy part, as this stuff done many times already. The devil is in details about how to actually get into guts of angular's dependency and routing systems.
As for very-angular specifics - it was right there is course outline - directives/services/etc. This knowledge is unique to Angular 1.x (i.e. most of it will be irrelevant even for Angular 2.x)
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.
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.
Actually a short answer will do fine. Ignoring Backbone, name ONE part of a major framework you can do that with?
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.
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".
The only reason you might not dislike angular is if you never had to deal with issues above OR you never had different experience, sorry.
The bottom line seems to be that your bad experience is relevant while all good experiences are irrelevant because they weren't your bad experience.
That tells me you simply don't know how to use it, sorry.
Unless you're using highly well-established APIs (such as promises), then of course, you'll have to rewrite things to match the new expected syntax.
Portability of knowledge is a different beast. For example, the vast majority of ng-repeat related concepts is completely non-portable (think `ng-repeat-start`, `track by`, `(x, y) in foo`, `$index`, etc). You learn that `ng-repeat="x in foo | filter: bar"` is equivalent to a for loop that displays only some items, but you can't really apply that knowledge anywhere outside of Angular.
You can't reuse your basic knowledge of for loops and if statements coming into Angular, and you can't use your knowledge about the pipe syntax anywhere else when you leave Angular.
In contrast, a framework that employs `.map` and `.filter` might teach you a bit about FP, and this is something you can use in Angular, Ember, React, and even vanilla js.
You are arguing that syntax equals mobility which is incorrect. .map and .filter can have different syntax depending on the language, just as ng-repeat (the equivalent to a for loop) has a different syntax than a for loop in Perl.
Knowledge and syntax are two different things as well.
No, I'm saying that the knowledge of the concepts of map and filter (as an example) is easily transferable even if syntax isn't. Once you understand those concepts, you can go look up the Ruby/Haskell/whatever syntax and you can reuse your new knowledge of higher order functions, and maybe learn about transducers, or maybe you can go look into point-free style, and the testability benefits of pure functions vs procedural style, etc, etc, etc. Not to mention that by knowing `.map`, you already know a great deal about the template languages for React, Mithril and Mercury.
In contrast, say I've learned about pipe operator precedence in ng-repeat expression clauses. Now I know I can write `x in (foo = (bar | filter: baz))` to memoize a filtered list for use later in that template. But only in Angular template expressions. But not in Javascript. Or Ruby. Or Haskell. And it's a terrible idiom to use in Angular anyways because [insert long rant about a bunch of unrelated topics].
Aside from the knowledge that operators can be recursively composed into god-awful expressions, what part of all that is useful if I migrate to Ember?
Or, say I learn about directives, and transclusion and the ngModel attribute micro language, and $compile and priority and the ngModelController API and ...
These are most certainly not syntax-related concepts. What does learning that get me?
Also, as a framework, it's got a lot less magic than Angular, and lets you write javascript code that's much more like normal JS code than angular does. (IMHO).
Also, the articles by the Mithril main author about JS & development philosophy are really good. I really like his style and approach to front-end development.
lichess.org is another relatively large project that uses it (I mention this one because it's also open source)
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.
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.
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.
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.
The definition of a framework is abstraction. That's not hyperbole, that's fact. Frankly abstraction is programming since all programming languages are is an abstraction of machine code.
I'm not going to bother responding to you point to point, since I made valid counterpoints that you are hardly qualified to dictate as "not valid". The OP's post was opinionated half-truths designed to be pissy about Angular because that's what the Cool Kids(TM) do these days. It's gotten boring...
But hey, it won't be but a moment before more boring people have more boring complaints about React. Naivety has no end.
It's actually "a basic structure". Which seems to work much better. Your definition would make this:
trait Storage {
def put(path: String)(bytes: TraversableOnce[Byte]): Unit
def get(path: String): TraversableOnce[Byte]
def rm(path: String): Unit
}
Reusing a basic structure to short circuit some engineering tasks and hopefully accelerate the development of others. That's a Framework.
But the funny part:
"Reusing a basic structure to short circuit some engineering tasks"
So, you mean abstracting away some difficult task?
Also it is not "Cool Kids" thing, it is personal observation how backwards some angular solutions are from working for a year on large team and large angular project and reading ALOT on all possible best practices.
To me much of this "this is better because this" is a lack of understanding your tool and/or personal bias leaking into the design decision for a piece of software.
I like Angular for what it is and using it on a year long project with a large team on a large project suggests that your decision makers did virtually NO research on what Angular excels at.
The problem (judging based on your small comment history on this thread) suggests that Angular isn't a problem, it's that EVERYTHING is over-engineered if it's not modular. And while I appreciate the modular approach having many benefits over non-modular frameworks, pretending that it's "The Only Way" is just as silly as pretending Angular is the answer for everything.
In fact if you spend a bit of time to see where from creator came, you understand why he did what he did. Also, if you had experience with server-side mvc frameworks you find all these concept very familiar. Also, if you built any type of complex client-side application, you will find, that server-side MVC concepts, based on single request = single response are not appropriate for long living client-side apps.
Sorry, there is just lack of perspective on your side and there is not much we can argue about.
Can you suggest any other JS framework (for a beginner) which fits above criteria?
After that I found Backbone.js and it just clicked. Most of the code produced for it is pretty portable, as there not much of framework given to begin with. So it was very easy to start hacking with.
Small size of Backbone.js comes at its own costs, like lack of memory-management. But with small apps memory management should not be a problem, and by the time it become a problem, you probably will understand issues at hands well enough, as well as will be aware of Marionette.js.
Backbone.js/Marionette.js (and similar size frameworks like Mithril.js) still requires quite a lot of boilerplate code, that what react.js and higher level frameworks try to solve, each in their own way. So by that time you either find one to fit how your brain works, or find your own combination of lower level components which essentially will form your own framework, which you will understand very well by that time.
That is my vision. Why I tried to warn about angular - while most of the terminology/architecture choices you learn from most client-side frameworks are very transferable to others, angular's - does not. Therefore knowing angular is important if you day job is UI engineer, since it is very popular choice, especially in corporate environment lately, I would not recommend it as very first and, especially, the only one, framework to learn. Hope this make sense :)
Do you think that the concealing of complexity is harmful in the long run? I certainly don't. I think there will be some shock when you try to go straight from codeacademy to the real world, but it's probably less of a shock than going from 0 to real world coding.
In the long run, I can easily see codeacademy building a suite of courses that get progressively less and less "magical" until there are no longer any training wheels. That's going to be quite compelling if they can make it work.
Full disclosure: Terminal powers codeacademy's production and staging workloads.
With the current focus on component-based design in Angular 1.x, the meat of your app would be fairly easy to move to angular 2. Much of the job involves removing code and I believe it can, and will be automated in due time (with some shortcomings, to be sure).
Moreover, the core team has put a focus on making 1.x modules compatible with 2.0 and 2.0 modules compatible with 1.x so that you can migrate progressively.
Unlike with React, you don't start off with a clean slate and that's a major shortcoming, but I think right now Angular is still a solid choice of client-side framework, mainly because of its enormous community and iteration speed.
The main trouble is, you need to be following the latest developments and best practices, otherwise you'll probably end up Doing It Wrong™.
Not having taken the time to understand how something works doesn't give you an excuse to decry it as "magic" and move on. Clearly, Angular is constrained by computability as every other computer program also is. There's no magic involved, just dirty checking, which is a well-established pattern.
As engineers, designers, developers, whatever, we ought to know better than to claim anything as magic. It obscures the real problems and breeds a culture that says it's okay to do so.
Compare this to small scope of Backbone.js, whose source code can be read easily, and you might see why i am against angular's magic for newcomers.
If you're looking for your very first single-page application library, try MithrilJS. It's small and easy to pick up quickly: https://lhorie.github.io/mithril/
If you haven't ever worked with MVVM, do so. It is a treat.
I don't understand. Mithril also allows for clean separation of view and model, typically in a functional and declarative manner.
>If you haven't ever worked with MVVM, do so. It is a treat.
I worked with it for quite some time at a past job which gave me my strong opinions about the uselessness of Angular.
`ng-model` is actually one of the "magic" things that @hippich is warning against. Having used Angular (and built Mithril based on lessons learned from using it for a few years), I agree bindings are handy in a lot of cases. That is, until you need to work around them (maybe because your inputs are laggy, or you've hit the infamous 2000-binding-ceiling, or whatever). Then, they're not such a treat anymore.
With Mithril (and fwiw, other virtual dom libraries as well), you can choose to add the convenience of bindings where you find appropriate.
The points about POJOs and HTML syntax are, similarly, aspects that you have control over.
What eventually pushed me away from Angular is the performance of the scope digest cycle (which you won't even notice until you've built a large enough app to have a problem) and the odd state management issues that arise as a result of two way data binding.
Compared to managing the DOM in both your HTML and your JavaScript files, AngularJS seems so much better organized.
This is achieved with some custom syntax and also a fake/virtual DOM that you work with. The gain from all this is speed. It's impressively fast, in fact.
So, aren't they two different things? (Honest question since I haven't play with React yet).
The main issue stemmed from research, development, and training costs from what I understand.
One thing that's surprised me is I get nearly as much attention from recruiters for Angular work as for Rails. I think this is mostly due to the .NET world embracing it, they tend to be enterprisey gigs.
Give it a few years, and Angular 1.x is going to be like COBOL in the early 90s. Lotsa code out there to maintain...
Also, React Native is the new way they're proposing to build native mobile apps; definitely new but worth it to learn React in case this works out.
I would definitely push people towards learning Meteor. I know it's a full stack framework instead of just a front end framework but for rapid prototyping, it's fantastic. The community for Meteor is a bit hit or miss because it's so "magical" but it's worth a look too.
Disclaimer: I've only ever done about a week of Angular so I cannot compare features.
It is more like:
* React
* React-Router
* JQuery (for the AJAX functionality)
* A library for or to help build Observables like EventEmitter, RxJS, or BaconJS
* Immutable.js is useful in many projects
There are also many patterns that have cropped up with React like Flux or Container-Component.
For a newbie, getting started with Angular is much easier.
React doesn't need a router for many uses (extending existing sites), but does need lodash/ramda and an AJAX library. ImmutableJS is useful for both angular and react (as is rxjs/baconjs). For a beginner, I would simply say React, Reflux, Ramda, and jQuery will do 90% of the things. Learning all four of these libraries (they probably already know jQuery) will take less time than Angular and be more flexible if they want to swap one out later.
Finally, adding these is much easier with commonJS than the angular dependency injection (often on top of commonJS).
Moreover, Backbone is a great example of MVC, the understanding of which is useful and highly transferrable to other (even non-JS) frameworks.
Angular: http://www.letscodejavascript.com/v3/blog/2015/01/angular_re...
React: http://www.letscodejavascript.com/v3/blog/2014/09/react_revi...
I've also heard good things about Knockout, but I haven't reviewed it. Ember is also popular; I've used it and prefer React.
Some people will say that it's unfair comparison because React does so much less than Ember and Angular. To that I can only say: Yes, and that's part of why it's better.
After using it for a few years, "passive-aggressive architecture" really is the best way to refer to it.
So, the point is, don't believe the hype, try yourself and then decide if it is for you or not.
[1]http://angularjs.blogspot.com/2014/10/ng-europe-angular-13-a...
I feel less bad about companies being screwed over by this sort of massive change - any tech manager/architect/lead who is researching what JavaScript stacks to choose for future projects should either already know about Angular 2.0 or have the available means to find out about it (and if they either don't or can't, they're basically just bad at the job they're being paid to do) - but for students, in any sense of the word, it's a different matter.
ETA: http://www.codecademy.com/learn/learn-angularjs "Learn how to build web apps using AngularJS 1.x. By the end of the course, you'll be able to use AngularJS to create powerful apps of your own."
Also, the job market for Angular developers is high, and a lot of those companies wont be migrating instantly. If you're looking to get into the field 1.x isn't a bad bet.
You'll have to learn Angular2 someday, but then again, the life of a front end developer is constantly learning new frameworks / technologies.
Anarchy!
Angular has been created by the illuminatis to drive people crazy, help them, help the chaos spread the world.
Mouhahahahah
(Yes I can do angular, and yes it is insanely complex and shitty with a lot of Java desgin patterns like IoC from the GoF that are very suitable for java, but totally useless in javascript... Someone still must think we are in the 90's and that the java in javascript means they are related)