Angular 2 Fundamentals Course(courses.angularclass.com)
courses.angularclass.com
Angular 2 Fundamentals Course
http://courses.angularclass.com/courses/angular-2-fundamentals
119 comments
Angular 2 is great, just look at all the features you get: WebWorker, Server-Side Rendering, mobile, progressive web application, Lazy loading support, Router, Material Components, Precompile your app. Tree-Shaking support, fast rendering, CLI, and TypeScript. The framework is backed by Google and Microsoft
The funny thing about lists of features is that they tend to create their own focus illusion.
Here's what I want to know:
1) Are the various abstractions surrounding those things reasonably legible? Or are we back to talking about Factory Service Providers again or otherwise importing other bits of pattern hell idioms into a language where there's always been easier ways to get things done?
1a) What did they do to make scope legibility better? (Assuming we still have the same scoping concept)
2) Do the abstractions leak? Angular 1.x abstractions leak like hell. Even if you're not concerned about performance, you have to be careful about snakes breaking out from under them and providing unexpected behavior, if you are concerned about performance you'd better have a detailed understanding about how the digest cycle works and it's utterly laughable that people thought this was a reasonable tradeoff for two-way data binding.
3) Is the tooling better? Some versions of Batarang were just straight up broken.
Given that Angular 2 isn't really stable yet, I have my doubts these questions can have clear answers, but happy to receive surprise illumination.
(At the moment, though, still avoiding applying to work at anywhere that lists Angular as a requirement. There's going to be technical debt and likely enough an ongoing technical decision making deficit at anywhere that does.)
Here's what I want to know:
1) Are the various abstractions surrounding those things reasonably legible? Or are we back to talking about Factory Service Providers again or otherwise importing other bits of pattern hell idioms into a language where there's always been easier ways to get things done?
1a) What did they do to make scope legibility better? (Assuming we still have the same scoping concept)
2) Do the abstractions leak? Angular 1.x abstractions leak like hell. Even if you're not concerned about performance, you have to be careful about snakes breaking out from under them and providing unexpected behavior, if you are concerned about performance you'd better have a detailed understanding about how the digest cycle works and it's utterly laughable that people thought this was a reasonable tradeoff for two-way data binding.
3) Is the tooling better? Some versions of Batarang were just straight up broken.
Given that Angular 2 isn't really stable yet, I have my doubts these questions can have clear answers, but happy to receive surprise illumination.
(At the moment, though, still avoiding applying to work at anywhere that lists Angular as a requirement. There's going to be technical debt and likely enough an ongoing technical decision making deficit at anywhere that does.)
Angular is absolutely off in its own world of Factory Service Providers.
It all feels way too abstract and way too much "it's own thing" that is quite separate from the world of HTML and Javascript.
It all feels way too abstract and way too much "it's own thing" that is quite separate from the world of HTML and Javascript.
You don't need all that to create SPA app. it's bloated framework.
I wonder where the happy medium is. Setting up React/Redux/React-redux/react-router/react-redux-router/react-redux-router-thunk/webpack-hot-module-oh-my-god-what-am-i-doing takes forever.
Honestly, the fact that people put up with this in Js ecosystem amazes me to no end. I've been working with ClojureScript on the front-end for the past year, and it's just night and day.
There's a single build tool (http://leiningen.org/), and it manages dependencies, tests, builds, etc. Things just work.
Setting up a new project is as simple as:
lein new reagent-frontend myapp
I can go and start developing it by running
lein figwheel
After it starts I can open the browser at localhost:3449 and any changes I make in the source will be immediately reflected. Once I want to package for release I just do:
lein clean lein release
That's it, I now have minified and pruned Js file that's ready for production.
There's a single build tool (http://leiningen.org/), and it manages dependencies, tests, builds, etc. Things just work.
Setting up a new project is as simple as:
lein new reagent-frontend myapp
I can go and start developing it by running
lein figwheel
After it starts I can open the browser at localhost:3449 and any changes I make in the source will be immediately reflected. Once I want to package for release I just do:
lein clean lein release
That's it, I now have minified and pruned Js file that's ready for production.
This is pretty much what we’re doing with Create React App.
npm i -g create-react-app
create-react-app my-app
cd my-app
npm start # start devserver
npm run build # build for productionSure, but how do you go about doing things like managing dependencies, doing hot code loading, running tests, and so on?
You don't need all of that from scratch. You can just build React components, and when it comes time to add a store or a router the only thing you need to change are the glue components that bind things together. I think it works out nicely -- the dev process is as composable as the app itself.
Yea I've noticed that. The react community likes to focus on examples involving a sign up form with 3 fields where you "really don't need all of that". Except that is not what most of us SPA devs are building. We need most of that.
Either you need all of that, and the time to set it up is absolutely insignificant compared to the lifetime of the project.
Or you don't need all of that.
It's very, very rarely a different situation.
Or you don't need all of that.
It's very, very rarely a different situation.
Is that really an argument? that you don't need to write it at the beginning? you still have to do it...
My argument is that it's a net benefit. Composable architectures are not boilerplate. Remember that there was a time when almost all React apps where written with Flux -- this model is what allowed Redux gain traction.
create-react-app is their official attempt at a happy medium that basically does bare minimum basic configuration to start building React apps with the latest tools: https://facebook.github.io/react/blog/2016/07/22/create-apps...
HN Discussion link: https://news.ycombinator.com/item?id=12144371
HN Discussion link: https://news.ycombinator.com/item?id=12144371
Here's how to have a great starting point in less than 10 seconds:
npm install -g create-react-app && create-react-app hello-world
npm install -g create-react-app && create-react-app hello-world
A good way to start is to use polymer components :-)
You don't need to use all of that just because it's there and having it there is more reliable than having to cobble together your own, at least in a corporate setting.
I actually find it surprising that this is a Google project, if you just gave me the code/docs and didn't tell me what project it is I would have guessed this came from Microsoft (feels much more WPF/Silverlight like than GWT/Closure, hell it even uses Rx which came out of MS)
I actually find it surprising that this is a Google project, if you just gave me the code/docs and didn't tell me what project it is I would have guessed this came from Microsoft (feels much more WPF/Silverlight like than GWT/Closure, hell it even uses Rx which came out of MS)
Angular 2 uses Typscript which did come out of Microsoft.
having the option to precompile your framework to 20kb file size which is smaller than some libraries feels like a great feature
Just a note, that 20kb also includes the dependencies, such as the reflect metadata polyfill, zone.js polyfill, and an ES6 shim such as core.js. Once static template compilation lands (think of it like the JSX compiler), it will get even smaller.
Angular 2 is shaping up to be a framework like no other out there in its capabilities.
Angular 2 is shaping up to be a framework like no other out there in its capabilities.
20kb? Really? On last week I built NG2 application(rc.4) with one component and size was over 500kb, with all dependencies which needed to run it. Maybe @angular/core weight 20kb, but in order to run real world application need add many dependencies. rxjs, zoom.js, shims, and so on..
We have 75-100 components along with all the angular pieces, polyfills, and ngrx/rxjs. It's 250kb with a minimal build process. I haven't even started digging into any optimization/build tools. I think you're doing something wrong.
It's possible using smart techniques (standard minification/gzipping, Google Closure/Rollup, etc.).
I heard they are going to reduce final app size by doing smart analyzing of used features and getting not used stuff out of the final build. But I might be wrong.
Even if you don't need it for a one app you might get a need for the another app and it's fine that all that stuff is coming as an entire framework from the one team, which means that all listed features will work smoothly being put in a single app. So no need to find and integrate scattered over the interned 3-rd party libraries. I agree that Angular is more for the large (you can say enterprise) projects.
Can you suggest an alternative?
vue.js
https://vuejs.org/
Edit: I used NG1 a lot and liked it. But after trying NG2 I felt it to be really too complex for small to medium projects. Vue.js is what I hoped NG2 to become.
https://vuejs.org/
Edit: I used NG1 a lot and liked it. But after trying NG2 I felt it to be really too complex for small to medium projects. Vue.js is what I hoped NG2 to become.
If an alternative is not named, does that change the value of the opinion in any way?
I was just wondering what the author had in mind. But now that you ask, yes I think it does. Without a suggestion the opinion is pretty much worthless.
You really think we shouldn't criticize things if better alternatives don't currently exist? The fact that someone hasn't come up with a better approach doesn't imply that the status quo is the best possible solution.
Absolutely.
Here's an example: Human mortality sucks. However, since there is no alternative, complaining about it is an exercise in futility.
Here's an example: Human mortality sucks. However, since there is no alternative, complaining about it is an exercise in futility.
polymerjs is a great alternative.
Javascript?
ie for any mildly complex app, [re]implement a framework rather than using an existing framework that is battle-tested to a far higher degree than is possible if you roll it yourself?
So Angular is not made with Javascript then? Do you not write Javascript when you use it?
That's a bit like saying that the alternative to a roof is shingles.
That's a bit like saying that the alternative to a roof is shingles.
What exactly do you not need?
What does "single page app" mean to you? The term is not a description of the amount of features.
What does "single page app" mean to you? The term is not a description of the amount of features.
Just like Angular 1 was backed by Google. It boggles my mind that people are still falling for the "backed by Google" thing, after Google has shown time and again that it loves to abandon products.
And Dart :)
Interesting coincidence. This week I've been tasked with looking into a JavaScript framework to replace our pure-Clojure stack at work.
One of the front-end candidates is Angular. But we're considering cutting it from the race.
The three main things we're looking for in a front-end framework:
1. Longevity: we don't want to adopt yet another fad framework that we'll have to replace in 2017. The current trend looks to be moving towards React-style FRP, and Angular seems to be catching up in version 2, but nobody seems to be using that yet, which means nobody will start using it. It looks like another Python 3 problem to me. I don't see Angular lasting long.
2. Flexibility: we want to quickly be able to change what pages we have and what's on them, without needing to tear down and rewrite the entire front-end. If Angular is only just now beginning to adopt React-like patterns, how can I be assured that it got them right, and that I won't run into rigidity issues 2 weeks into writing Angular code?
3. Convention over configuration: our data will live in MongoDB, so all our models are straightforward JSON. I'm hoping to find a stack that assumes this and doesn't require me to write tons of boilerplate that should be assumed for me by my frameworks. I'm not sure how Angular fares in this, but so far none of the candidates really shine in this area.
For the record, we're currently looking into Sails + Ember + Mongo. But we're not super excited about this since it still doesn't look like it'll hit all three of our needs really well. I'm particularly concerned that Ember is going to have the same issues as Angular, especially if the community is looking to regularize tools around React.
One of the front-end candidates is Angular. But we're considering cutting it from the race.
The three main things we're looking for in a front-end framework:
1. Longevity: we don't want to adopt yet another fad framework that we'll have to replace in 2017. The current trend looks to be moving towards React-style FRP, and Angular seems to be catching up in version 2, but nobody seems to be using that yet, which means nobody will start using it. It looks like another Python 3 problem to me. I don't see Angular lasting long.
2. Flexibility: we want to quickly be able to change what pages we have and what's on them, without needing to tear down and rewrite the entire front-end. If Angular is only just now beginning to adopt React-like patterns, how can I be assured that it got them right, and that I won't run into rigidity issues 2 weeks into writing Angular code?
3. Convention over configuration: our data will live in MongoDB, so all our models are straightforward JSON. I'm hoping to find a stack that assumes this and doesn't require me to write tons of boilerplate that should be assumed for me by my frameworks. I'm not sure how Angular fares in this, but so far none of the candidates really shine in this area.
For the record, we're currently looking into Sails + Ember + Mongo. But we're not super excited about this since it still doesn't look like it'll hit all three of our needs really well. I'm particularly concerned that Ember is going to have the same issues as Angular, especially if the community is looking to regularize tools around React.
Can't comment on 2 and 3, but for 1... I'd say it's the opposite. I believe the Angular team took a long, hard look at what was working with React (and others) and that's why they decided to take their time to get Angular 2 right.
If anything, React-* is the stack that has a longevity problem from my point of view. Everything I do on the web I use React, and my impression is that even if I'm using a modern stack, everything breaks 6 months later because things have changed considerably. Many of the extensions React naturally need either fall out of fashion, or go through deep changes, or are just not that good. On every new project I assemble, I start from the assumption the architecture will be outdated very fast.
I hope Angular will make that kind of stuff a bit more solidified. We don't need a new store solution on every new project.
If anything, React-* is the stack that has a longevity problem from my point of view. Everything I do on the web I use React, and my impression is that even if I'm using a modern stack, everything breaks 6 months later because things have changed considerably. Many of the extensions React naturally need either fall out of fashion, or go through deep changes, or are just not that good. On every new project I assemble, I start from the assumption the architecture will be outdated very fast.
I hope Angular will make that kind of stuff a bit more solidified. We don't need a new store solution on every new project.
> Longevity: we don't want to adopt yet another fad framework that we'll have to replace in 2017.
No such thing. They're all pretty much fad frameworks.
No such thing. They're all pretty much fad frameworks.
Looking back, though, I might have said the same thing about Rails or Sinatra or Laravel, but they stood the test of time, and people still use them. A lot of what gives a framework longevity is just whether or not big players adopt them and developers love them, these two factors will go a long way in ensuring a framework continues to get upgrades and continuous maintenance. At least longer than Backbone, anyway.
So Angular is the COBOL of Javascript frameworks?
Actually, I think it's probably more comparable to some kind of Java FactoryProviderServiceFactory thing.
Actually, I think it's probably more comparable to some kind of Java FactoryProviderServiceFactory thing.
JavaScriptMVC/DoneJS has a pretty long history: http://blog.bitovi.com/longevity-or-lack-thereof-in-javascri...
CanJS, the MVVM part of DoneJS, is currently coming up to its third major/breaking version. I think that’s a pretty good track record for us/Bitovi.
CanJS, the MVVM part of DoneJS, is currently coming up to its third major/breaking version. I think that’s a pretty good track record for us/Bitovi.
If it's an internal app or if it otherwise doesn't need to be single-page-app, save yourself some brain cells and do something simple like Rails or Django. If JavaScript is absolutely required, stick with Sails/Mongo and skip the Ember/Angular SPA.
How does that help with a rich front-end? We're not looking to use JavaScript simply for the sake of using JavaScript. We want it in particular for a richer front-end. As far as I can tell, Sails isn't going to help with that any more than Rails does. That's why we're looking into Ember or Angular.
What is reach front end? The one where you wait your js to arrive only for it to issue own API calls, then wait data to arrive, then it to be parsed and finaly shown?
It would not surprise my if some dumb turbolinks staff would beat a lot of fancy frameworks performance an UX wise.
> What is reach front end? The one where you wait your js to arrive only for it to issue own API calls, then wait data to arrive, then it to be parsed and finaly shown?
No, that's your own straw man definition.
> It would not surprise my if some dumb turbolinks staff would beat a lot of fancy frameworks performance an UX wise.
Turbolinks absolutely does not beat a well written SPA UX-wise.
No, that's your own straw man definition.
> It would not surprise my if some dumb turbolinks staff would beat a lot of fancy frameworks performance an UX wise.
Turbolinks absolutely does not beat a well written SPA UX-wise.
OK, wasn't clear to me that "rich front end" was important or necessary. I see a lot of projects choose JS front-ends because they are neat or cutting edge, not because they are useful or necessary.
React is great, but it's just a lib. Angular 2 is in release candidate 4, and there are already ton of people using it. If you want a complete solution, I'd use Angular. TypeScript is awesome too. Angular comes with all the stuff you need, http, animations, routing, etc. I wouldn't cut it out just yet, seeing how it's on the horizon.
Could you share real projects(not todo-like applications) which use NG2?
Not NG2, but people for some weird reason try to ignore polymer here - and you have plenty of real-life appications starting from Google Music and Youtube to EA Battlefield1 and IBM and General Electric tools.
By pure-Clojure stack, do you mean you use ClojureScript on the front end currently? If so, Om and Reagent are both Clojure-y wrappers around React anyway, so that would probably the smoothest transition for your team. And if not, why not? :-)
Sounds like Aurelia might be a nice match. Much less boilerplate
sails + vuejs + postgresql will be my choice.
Interesting. How will you handle dynamic front-end routing though? Or will you rely entirely on Sails for server-side routing?
I've been reading Switching to Angular 2. Are collections still propagated via EventEmitter<Type>? Seems like the implementation is bleeding into the user code.
I maintain Angular continues to be a bad reimplementation of JSF except mostly on the client side.
I maintain Angular continues to be a bad reimplementation of JSF except mostly on the client side.
Not sure what you mean by collections, but the EventEmitter is just an alias for a Subscriber in RxJS. So it's an observable.
I heard angular is a framework and react is lib.
angular 2 or react.
Coming from nodejs, python, php, jquery experience which should I learn?
Angular is a more full featured than React by itself. To get React to equivalent features you have to add on (and learn) several other things (Redux, WebPack, etc, etc). As a bonus, there are lots of different conflicting flavors-of-the-week for things to use with React to build out your stack, so whichever you pick to go with React might not be cool next week.
This. In the end both work similarly, but with React you have to shop around to decide what to use. With Angular things are a bit more strict and directed.
This is not accurate. You don't need to learn Redux or WebPack to use React. With Angular you also need a build process so you can use gulp or WebPack. Maybe there's a pre baked process but you still need to know some build tool.
Because React doesn't care about how you manage your state, you can use Redux or other solutions. Not because they are cool , but because it fits your needs.
Because React doesn't care about how you manage your state, you can use Redux or other solutions. Not because they are cool , but because it fits your needs.
> To get React to equivalent features
That's the key part you ignored in your response.
That's the key part you ignored in your response.
I think the overall point that you have to fill in the gaps yourself still stands, though. Angular just comes with way more features than React does, so if you want an equivalent experience, you have to use third-party libraries with React, which increases the amount of things you have to learn. Not that this is entirely a bad thing, but you can't really compare bare React to bare Angular and say they're equivalent.
Not sure if your point about the amount of things to learn is true. I prefer learning small utilities and compose them. The cognitive load is much more smaller (for me) than having to learn a giant monolith. I guess it's a matter of preference.
There are tradeoffs. The advantage of learning smaller libraries is that you only have to learn what you need. However, the advantage of a monolithic framework is that everything is integrated so nicely that, once you learn the framework, everything kind of "just works", and you don't have to spend time figuring out how to glue everything together. I personally prefer the former approach, but I also understand the appeal of a framework like Angular or Ember that makes all the high-level decisions for you.
With Angular you get all you need out of the box. Easy to get going with ng-cli (creating an app, generating components etc.). Typescript is default, so you get type safety if you want it. I like a lot of what I see.
Conceptually, React and Angular are quite close. In both you build an app with components nested in a three structure. Angular let's you do two-way binding if you want — convenient, but makes state changes less explicit.
React is closer to bare bones JS and HTML. Templating in HTML only consists of a simple way to embed JS code and a few reserved keywords. In Angular, templating is much more elaborate, and therefore more complex and takes a longer time to learn.
React — both by design and community — favours FP priciples, while Angular is mor OOP oriented, though neither is strictly one or the other.
Personally I like both. React for its simplicity, Angular for its all-batteries-included approach and support for static typing as default.
Conceptually, React and Angular are quite close. In both you build an app with components nested in a three structure. Angular let's you do two-way binding if you want — convenient, but makes state changes less explicit.
React is closer to bare bones JS and HTML. Templating in HTML only consists of a simple way to embed JS code and a few reserved keywords. In Angular, templating is much more elaborate, and therefore more complex and takes a longer time to learn.
React — both by design and community — favours FP priciples, while Angular is mor OOP oriented, though neither is strictly one or the other.
Personally I like both. React for its simplicity, Angular for its all-batteries-included approach and support for static typing as default.
My experience is that Angular 2 is a great solution for enterprise-style shops who are looking for an all-in framework. With React, you benefit from greater flexibility outside the view layer, but ... well, you also suffer from greater flexibility outside the view layer.
In general, I'd say that the more comfortable you are with current FEAD practices and toolchains, the more power you'll get out of a React-based architecture. The more you want something that "just works" and has already made many architectural decisions for you, give ng2 a shot.
In general, I'd say that the more comfortable you are with current FEAD practices and toolchains, the more power you'll get out of a React-based architecture. The more you want something that "just works" and has already made many architectural decisions for you, give ng2 a shot.
What should you learn? both. But you should also be able to write "rich" single page applications without a framework and understand basic DOM manipulation.
Having used and studied both React and Angular2, Angular2 can do certain things that React can't. Two features at the forefront of this difference are:
1) Dependency injection
2) Direct support for using observables and promises in templates
However, I cannot think of anything major in the reverse direction.
There is also the fact that it is designed to be used with Typescript from the get-go, which can be a plus if type safety is your thing.
1) Dependency injection
2) Direct support for using observables and promises in templates
However, I cannot think of anything major in the reverse direction.
There is also the fact that it is designed to be used with Typescript from the get-go, which can be a plus if type safety is your thing.
You can inject stuff using props. DI is not unknown concept in react, note that angular1.x do not have true dependency injection.
React decouple data and view. You can achieve similar behaviour but using flux/redux to publish/subscribe.
React decouple data and view. You can achieve similar behaviour but using flux/redux to publish/subscribe.
Angular for job opportunities, react for more pleasant and forward looking web development practices.
Er.. https://github.com/angular/angular-cli
1. Open terminal
2.
> npm install -g angular-cli
> ng new app
> ng serve
4. Use the cli tool to generate components/pipes/services/etc., build, test, develop
5. Profit.
Find a more blissful and joyful experience than this in react land?
1. Open terminal
2.
> npm install -g angular-cli
> ng new app
> ng serve
4. Use the cli tool to generate components/pipes/services/etc., build, test, develop
5. Profit.
Find a more blissful and joyful experience than this in react land?
Well, react did come up with this https://facebook.github.io/react/blog/2016/07/22/create-apps... recently.
Also, one thing that is not enjoyable/straightforward with(angular-cli) is having to utilize System.js in order to include 3rd party libraries in your app.
Also, one thing that is not enjoyable/straightforward with(angular-cli) is having to utilize System.js in order to include 3rd party libraries in your app.
That is about to change to webpack on next release - a big PR landed in the angular cli to switch it to webpack from broccoli.
The number of steps it takes to get it "up and running" is relevant, but hardly the most important part of what makes a language/framework a pleasant experience. Also, you seem to assume I'm in react land? But I'm an angular developer. I know first hand the big problems of angular :P
Maybe, but it will take you 3 weeks to set it up.
This:
git clone https://github.com/Day8/re-frame-template
lein new re-frame <project-name>
lein figwheel
Ignore both. Learn vue.js to get shit done.
Wordpress goes with react, drupal picks angular2, and laravel favors vuejs.
This is no surprise, wordpress is extremely popular these days for all users, a huge angular2 client framework might be an overkill for many of its users. Drupal on the other hand is doing the more complicated websites, and its "ordinary" user base is shrinking, so angular2 might attract enterprise users.
Laravel is arguably the most popular PHP framework today, choosing vuejs as its client framework gave vuejs a strong boost for sure.
This is no surprise, wordpress is extremely popular these days for all users, a huge angular2 client framework might be an overkill for many of its users. Drupal on the other hand is doing the more complicated websites, and its "ordinary" user base is shrinking, so angular2 might attract enterprise users.
Laravel is arguably the most popular PHP framework today, choosing vuejs as its client framework gave vuejs a strong boost for sure.
Agreed, Vue.js and Riot.js are both brilliant for actually getting things done without having to read a 100 page manual.
As for Vue vs Riot, it's subjective, but I'm personally partial to Riot due to its simplicity (albeit with a smaller feature list) and focus on components without being opinionated at all (not even regarding the toolchain).
As for Vue vs Riot, it's subjective, but I'm personally partial to Riot due to its simplicity (albeit with a smaller feature list) and focus on components without being opinionated at all (not even regarding the toolchain).
That doesn't address the issues the comment just above you (at time of writing) brings up, namely that even with Vue you still need to set up all the tool chain around it, whereas Angular brings a lot of that to the table for you.
I handle a big React app at my job. It's messy as fuck with JSX. We made a transition to Vue. Couldn't be happier.
What in particular about JSX makes it messy compared to vue? Messy template code can happen in both.
Vue templates support conditional rendering (v-if/v-show/v-else) which I didn't realize I missed until using them. Also, conventions around component data are really nice and help keep markup tidy and very readable.
I like to think of Vue as React with sensible conventions. That said, both are terrific and solve UI problems very elegantly.
I like to think of Vue as React with sensible conventions. That said, both are terrific and solve UI problems very elegantly.
React handles conditional rendering better imo. You use regular JS instead of having to learn a new API. You can use control logic in your render methods to great effect.
I definitely agree that React is clean for the reasons you state and I always enjoy building UIs with it. I suppose my comment was just a reflection on the differences that I found refreshing - to my surprise.
So it's your engineer's fault. Plenty of companies get stuff done with React everyday.
If you want, you can use Vue.js just like jQuery. Pop it in a <script> tag and you're done. No tool chain needed. I do that all the time for small-medium sized projects and it works absolutely fine.
Learn both then decide for yourself which one you like better.
I don't have time to learn both.
TBH, I am forcing myself to learn cuz... all these examples I could accomplish with jquery...
You could get the end result of a lot of these smaller example applications with jquery but making anything bigger is going to get very unmanageable very quickly. Also considering how close angular 2 is to react I'd be surprised if by learning one you wouldn't be able to at least understand code in the other. I guess it really depends what your end goal is.
+1 for react
Both :-)
I have only one question - when NG2 will be released? Because now it is not possible build real applications, many libraries are not stable, and still in beta or rc... Four month I'm trying to do real application and I must say that it was my big mistake when I decided use Ng2., with every new release I always have troubles with some dependencies or with new API, and there are no many stable components which I can use without pain. Ng2 has good promotion however we need wait official release., and then make some conclusions about it.
I've been working on an enterprise app with Angular 2 for over a month now and it's been mostly ok. I think the only horrible problem was the change in the form framework that went largely undocumented (super secret doc: https://docs.google.com/document/u/1/d/1RIezQqE4aEhBRmArIAS1...)
Once you get to forms 0.2.0 and rc4 of everything else; the framework is beautiful and even though I hated Angular 1.x with a passion, Angular 2 is awesome.
Once you get to forms 0.2.0 and rc4 of everything else; the framework is beautiful and even though I hated Angular 1.x with a passion, Angular 2 is awesome.
What about new router? And yes NG2 much better than NG1, I agree with you.
The uncertainty over this question is one of the reasons my team decided to build our new application in Angular 1.5 (though using TS and Webpack). It's less fancy, but mostly rock-solid and well-supported and understood.
We'll upgrade in a year or two once Angular 2 is well-understood and all the 3rd-party libraries have updated or deprecated into something else. The course looks like a good way to start understanding the differences.
We'll upgrade in a year or two once Angular 2 is well-understood and all the 3rd-party libraries have updated or deprecated into something else. The course looks like a good way to start understanding the differences.
Watching the milestone burndown on github for RC5 looks like it should be here pretty soon (two weeks-ish maybe is my guess), after that it appears the team will be on the last sprint.
I've been writing a few greenfield apps on NG2 since late alhpas and the thrash from RC0 thru RC3 was pretty painful but now playing with the new Router and Forms I get the feeling that the pain was worth it. Things seem relatively stable in RC4 and I really like the Router and Forms apis.
I am staying away from the Angular CLI since I reallllly want the bundling and tree shaking but am moving forward without it for now since it is using the old Router and Forms libs. In my opinion the CLI is the only tool I wouldn't bother until NG2 is done and fully out of RC mode.
I am still optimistic that NG2 is the right solution long term.
I've been writing a few greenfield apps on NG2 since late alhpas and the thrash from RC0 thru RC3 was pretty painful but now playing with the new Router and Forms I get the feeling that the pain was worth it. Things seem relatively stable in RC4 and I really like the Router and Forms apis.
I am staying away from the Angular CLI since I reallllly want the bundling and tree shaking but am moving forward without it for now since it is using the old Router and Forms libs. In my opinion the CLI is the only tool I wouldn't bother until NG2 is done and fully out of RC mode.
I am still optimistic that NG2 is the right solution long term.
32% complete - I think release will be in December ).
It might be so, but it's not a reason to not getting start familiar with Angular 2 today :)
If anyone has ever tried Anthony Alicea's JS/NodeJS/Angular1 course, please let me know if AngularClass' or any other course is similar to it. I really really liked anthony's course as it gave quite a deep look into sub topics, which are usually only attainable from books, while at the same time keeping it very interesting and also contain lots of best practice material and keeping a healthy focus on understanding over imitating courses. Do let me know if you guys know any other courses of the same style.
Just wanted to say Thanks for the course link!
AngularClass knows what they're doing. This course is gonna be legit.