Tag Archives: React

Angular 2 will not be a “failure” (whatever that is)

There’s lots of odd stuff I see here and there about Angular 2 being a “failure” or similar odd turns of phrase. I guess in order to really refute that we’d first have to come to an agreement on what success and failure constitute in the case of JavaScript application frameworks. React and Ember aren’t as big a success as AngularJS (at least not if you look at Stack Overflow questions, search volume on Google, etc.). Are they then failures? I certainly don’t think so. If so, most frameworks are going to get a big “failure” stamp on them.
Angular 2 may not sweep aside React, Ember, and AngularJS, however, there are reasons for some people to be interested in it and some of those people should probably adopt it in favor of  continuing with whatever they’re using today. Let me tell you why… Angular 2, or something like it, is the future.
I mean that in a very literal sense. Angular 2 is the future because it’s built from the future.

Angular 2 is built on future JavaScript

To adopt it you’re going to be strongly pushed in the direction of TypeScript. I’ll be the first to admit that I’m not in love with the “Type” part of TypeScript. I used strongly typed C++ and Java for a large part of my career and I’ve never mourned not having that strong typing in JavaScript.
But I love the extensive amount of ES2015 which it embraces and makes available to me now, today, for use in my apps. I could of course skip using TypeScript (or Babel) since Firefox, Chrome, Microsoft Edge, and (announced today as I write this) Safari are all ready to support ES2015.
However, there’s a fly in that ointment and it takes the form of IE11. Unlike IE8-10 which Microsoft effectively killed in January 2016, they’ve committed to continuing to support IE11 until they’ve end-of-lifed Windows 7, Windows 8, and Windows 10! Think about that for a second. That means that unless you’re willing or able to just blow off any user running IE11 (or an older version of Firefox/Safari/Chrome), you’re going to continue using JavaScript ES5 (circa 2009) for years and years or you can get used to using a transpiler like TypeScript.
Note: This is something which affects other frameworks just as much as it does Angular 2. Many developers are going to adopt a transpiling solution in the future to be able to start using modern JavaScript conventions even if they prefer to use React, jQuery, or whatever. Picking another framework doesn’t opt you out of this problem.

Angular 2 is built on future web browsers

The components you build with Angular 2 are designed in such a way that Google can easily leverage WebComponents technology to power them in the future for those browsers which support them. In fact, doing so will actually improve the quality of some aspects of the components because they will be able to use CSS contained very tightly to the component with no concern of outside CSS leaking in or contaminating the styling of pages which use them.
Again, WebComponents are part of the future for browsers. I want them today, I will want them in the future. In fact, I would like to imagine a beautiful future where I can build an app and mix-and-match WebComponents built using Angular 2, React, Polymer, etc. and it not be painful or slow to do so. Angular 2 is emulating a large part of what they offer today because they anticipate you’re going to want it anyway in a couple of years.

Angular 2 is built on modular JavaScript

Even if you’re using one of the fancy transpilers like TypeScript or Babel, or just the ES2015 support built into the cutting edge browsers, you still don’t have a great solution for loading JavaScript built in. The module loading recommended for the future of JavaScript is something you have to (again) emulate if you want to use it today. Angular 2’s solution for that emulation is SystemJS. It allows you to use import/export in your code so your HTML file only directly imports a small handful of .js files and the rest are handled by the emulated module loading code.
It’s the future; today. And, like the last two things I talked about, eventually it’s going to become an issue for developers of any framework. In this case no browser supports the functionality, even the cutting edge ones, so your choices are either emulate or do without.

Angular 2 continues the idea of a complete ecosystem

I credit Ruby on Rails for giving us the idea of a complete ecosystem which solves 80% of your problems out-of-the-box. You can say this isn’t “the future” like the three things above, but I would argue it is. I still believe that for most developers, a good framework which covers the bases well is a better bet than mixing together their own set of libraries for testing, routing, etc.
When you buy into Angular 2’s ecosystem, you don’t just get ES2015 JavaScript, modular JavaScript, and WebComponents. You also get solutions for unit testing, end-to-end testing, dependency injection, routing (though that sometimes appears to be the “router-of-the-day”… *sigh*), and event handling (RxJS is so much better than Promises, trust me). Also, you’ll get books and video courses (full disclosure, I’m working on Angular 2 Essentials right now), and be able to hire developers who already know most of your front-end stack before they start working. I consider that a powerful advantage.

In conclusion

Will Angular 2 be as popular or more so than all other frameworks? Maybe, maybe not. However, there’s enough here already to make it appealing to developers who are tackling multi-year projects and in need of a long runway without worrying that the framework they pick will likely become obsolete due to changes in the browser or language. For those developers, I doubt they’ll end up characterizing it as a failure.
Advertisements

The Best Part of Any AngularJS Troll Post

Any time I see the latest “I Hate AngularJS and So Should You” article I always skip straight to the end because that’s the very best part of all of them. It’s the fun part where we get to hear what the author of this particular piece is going to advocate you use instead. Here are the usual suspects and my highly uncharitable response to each one:

I’m writing my own framework now

Bonus points for this one if it’s accompanied by a link to their new half formed idea on Github. It should continue getting commits for at least a couple of months.

There are literally dozens of front-end frameworks at this point, but theirs is going to be way better than any of them. Look, there’s really only one or two guys who will work on it, but they are stellar programmers. God knows they are going to do a much better job than programmers at Google, Facebook, or the likes of Yehuda Katz and Tom Dale.

TodoMVC is beginning to look like one of those four page resumes you get these days with all of the “frameworks” that they have examples for. If you don’t believe me, be sure to look at their “Labs” tab. Yes, they have so many they had to put in tabs.

Backbone.js

Ha ha ha ha ha ha ha ha hahahaha haha ha ha ha ha. Oh god. I may have hurt myself. This person is so upset about how “heavy weight” AngularJS is and “complex”. Look for lots of mentions of how things should be “minimal” and “simple” and at least one mention of how many lines of code Backbone.js is vs. the object of their derision. I figure their house looks like this:Form_Gable_House5

I did Backbone.js for two years, that’s why when I went somewhere new I put them on AngularJS instead. I really hope the people who advocate going back to Backbone.js have to work on a large team of mixed skill level developers. The unskilled ones will make a hash of any framework but what they can do with Backbone.js is just amazing.

That New Framework That You Just Heard About on Hacker News Two Weeks Ago

This is the framework from author #1 above. It’s going to solve all the ridiculous mistakes that AngularJS made and probably all of those from the other major frameworks as well at the same time. Ultimately it won’t get anymore updates, but that’s OK because it only got used on one project before our author realized it not only had as many problems as the major frameworks but many many more. Plus it gives him/her an opportunity to tweet about the abandonment of this framework and the excitement for the next new one.

The Chinese Menu Framework

This is the idea that sticking together a bunch of different best-of-breed pieces to make your own framework is perfectly viable. Just pick something from columns A/B/C/D and start using it. You’ll find lots of people who can answer your questions, there are many books and videos for that particular combo of tech, and there are developers out there by the hundreds you can hire who will have no problem diving right into your projects.

Ha ha. I’m kidding. It doesn’t really work that way. Pick an arbitrary grab bag of stuff and maybe you’ll make some excellent choices. But you’ll have to live with that decision for quite a while. Even a less popular stack like Ember.js is going to get more third party support than whatever you decide upon for yourself.

Again, I council rationality

Above all, please do a quick experiment for me. The next time somebody tells you that AngularJS is a dead end and you can’t rely on it for years to come, ask them what they would have recommended back in 2013? Just two years ago. What set of stuff would they have advocated then that would be doing so well today and have this long lived future into 2017+ that wasn’t AngularJS? Backbone.js? I don’t know of anything.

My point is this, the front-end and JavaScript tech is changing at a rate way too high for anyone’s predictions about two and three years down the road to have a lot of merit. AngularJS seems like a reasonable bet to have done well and have lots of info available about migration from 1.X to 2.0 so at the moment I’m still on that path. In the meantime I hope to learn more about Facebook’s stuff to see if it gives me useful ideas or to see if I can incorporate parts of it into AngularJS (Flux seems interesting for instance and would likely slide into most of the frameworks). But the people who speak with such certainty about the future… Maybe they don’t see it as clearly as they think.

AngularJS is not perfect. I’m not about to say that it is. It has problems, over time they’ve been worked on and reduced. I’m sure if I went and picked up React/Flux/Relay/whatever (come on Facebook, give a name to your stack!) or Ember.js I’d see much the same things. Lots of great people are working on them and they have thousands of adopters. Most of the time for most projects it works pretty well.

If you’re having problems with AngularJS it may be that you need to learn more, look at some open source, maybe even pull in a mentor with more experience. Alternatively, if you’re struggling and you think you’ve put in more than enough effort, look at one of the major alternatives and see if it works better for you. I haven’t put in as much time on Ember.js but I’ve looked at Facebook’s offering and it is very different than what Google put together.