Angular 2 Fundamentals Course
courses.angularclass.com
courses.angularclass.com
Angular 2 is shaping up to be a framework like no other out there in its capabilities.
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)
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.
Here's an example: Human mortality sucks. However, since there is no alternative, complaining about it is an exercise in futility.
That's a bit like saying that the alternative to a roof is shingles.
HN Discussion link: https://news.ycombinator.com/item?id=12144371
Or you don't need all of that.
It's very, very rarely a different situation.
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.
npm i -g create-react-app
create-react-app my-app
cd my-app
npm start # start devserver
npm run build # build for productionnpm install -g create-react-app && create-react-app hello-world
What does "single page app" mean to you? The term is not a description of the amount of features.
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.)
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.
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.
No such thing. They're all pretty much fad frameworks.
Actually, I think it's probably more comparable to some kind of Java FactoryProviderServiceFactory thing.
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 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.
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.
I maintain Angular continues to be a bad reimplementation of JSF except mostly on the client side.
Wouldn't it be great to turn business requirements into code training documentation and crowdsource the development of things?
I like to think of Vue as React with sensible conventions. That said, both are terrific and solve UI problems very elegantly.
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.
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).
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.
That's the key part you ignored in your response.
Sure it's not like the 10x dev way to do it, but I do it for simple apps all the time.
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?
git clone https://github.com/Day8/re-frame-template
lein new re-frame <project-name>
lein figwheel
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.
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.
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.
React decouple data and view. You can achieve similar behaviour but using flux/redux to publish/subscribe.
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.
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.
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.
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.