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.)
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.
It's really much more than that. There's an ecosystem around ClojureScript that's completely separate from Js, and I find the CLJS ecosystem to be far better in many respects.
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.
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.
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)
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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? :-)
Thanks. Saw this somewhere before but it's less known. The good part of feathers.js is that it does express4, and I think sails.js is still with express3.
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.
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.
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.
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.
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.
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.
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
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
