9 ms·
If you don't know anything about client-side frameworks and consider Angular as your first one, keep in mind following: * This is Angular 1.x course. Angular 2
by hippich 12y ago
If you don't know anything about client-side frameworks and consider Angular as your first one, keep in mind following:
* 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.
- fridek 12y agoThis is Angular 1.x course because Angular 2 is nowhere near stability. It also won't be for another few years - that's how long it takes to build an ecosystem of packages around anything. I'd say apart from people wanting to contribute to Angular 2, or maintaining packages that may need to be ported to Angular 2, nobody should learn it right now. 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.
- lobo_tuerto 12y agoNot to rain on your parade but, would you call Google Cloud Platform's client-side a small site? What are your arguments for claiming that? https://www.youtube.com/watch?v=cVTN8msr5DE&list=PLOETEcp3DkCoNnlhE-7fovYvqwVPrRiY7&index=22 https://www.youtube.com/watch?v=cVTN8msr5DE&list=PLOETEcp3Dk...
- hippich 12y agoIs there place to look at actual product, without being paid client? I am looking right now at Console and it is indeed very simple app. I am desperately looking for indeed large projects made with angular 1.x because company I work for is in the middle of pretty large project where we stumble upon many angular shortcomings which I have no idea if even worth trying to search for solution.
- lobo_tuerto 12y agoHave you watched the video I posted? In there they explain the magnitude of the site. 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.
- hippich 12y agoI watched video, it is just overview. We currently solving same problems and a bit more (we do heavy localization.) And unfortunately level of details provided in this video are not enough to see how specifically they e.g. load module, how they load module dynamically with angular, how they update routes and trigger these again, how they update dependencies in run time for already loaded and registered modules. 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 :)
- lobo_tuerto 12y agoThen the problem has nothing to do with AngularJS per se, but how you package and deliver a web app in general. You need to learn about asset management. Take a look at webpack for example: http://webpack.github.io/ 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. ;)
- hippich 12y agoBelieve me, this is problem with AngularJS (mostly because they invented modules/dependencies and decided to stick with it despite obvious deficiencies instead of teaming up with other open source projects and using something like require.js 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.
- hippich 12y agoI would say 'magic' argument is controversial. On one hand you want people get easy start, on the other hand, you might not... Don't know :) 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)
- jhall1468 12y agoYour 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 agoWhen 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?
- 12y ago
- avinassh 12y ago> Knowledge you learn from using Angular is unlikely to be applicable to any other client-side framework Can you suggest any other JS framework (for a beginner) which fits above criteria?
- hippich 12y agoThis is tricky question. When I started there were framework like YUI, Ext.js, SproutCore which were... well... complicated and locking you up. 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 :)
- simplify 12y agoDefinitely Mithril.js – classical MVC that takes care of the view layer (and more!), with everything else pure JS. No "model" wrappers, no event publishing/subscribing, no made-up module system. The better you get with Mithril, the better developer you'll be overall.
- josh2600 12y agoYes it is Angular 1.x and as we all know the world is not static. It's fair to say that learning Angular 1.x is still probably a valuable skill. I do think that abstracting away nuances of JS is actually important in facilitating learning, but I could see how that might hamper your ability to apply this learning to the real world. 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.
- Jacqued 12y agoRegarding you first point, it was the community's perception after last year's ngEurope, but not so much after this year's ngConf. 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™.
- andrewstuart2 12y ago"Any sufficiently advanced technology is indistinguishable from magic." - Arthur C. Clarke [1] 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. [1] http://en.wikipedia.org/wiki/Clarke%27s_three_laws http://en.wikipedia.org/wiki/Clarke%27s_three_laws
- woah 12y agoNot to beat a dead horse here, but as others have said, Angular invents a ton of new terminology for no apparent reason.
- hippich 12y agoDon't get me wrong, by now I more or less versatile inside angular's guts. But the way stuff 'magically' appears in the html template might serve not so well to newcomers. The way it hurt - is when you stuck with some issue due design choices (dirty-checking loop) and have no clue how to proceed, nor there any really good sources to get answers, while reading angular code is plain painful. 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.