TL;DR: Browserify automatically works out what code depends on what. It will bundle our code into a single file, and make sure that everything is run only once and in the correct order. We specify an order of execution in Browserify using require statements. If A requires B, B will be executed first, and the result will be passed into A.
TL;DR: Angular 1 had transclusion which allowed us to access the content inside a directive's tag. Angular 2 has contentChildren which does the same thing. contentChildren are bound to their own component, not to the component they are included in.
Transclusion in Angular 1
Angular 1 gaves us the concept of transclusion. Transclusion is made of 2 words:
trans- from cross
-clusion from inclusion
It is the ability to bring in content from somewhere else, specifically the parent template...
TL;DR: Using decorators and a Reflect.metadata polyfill.
Angular 2 comes with a brand new DI mechanism. The premier way to do DI in Angular 2 is using TypeScript "Magic". Most articles gloss over this magic. In this article, we dive through the magic and look at the mechanism.
TL;DR: Annotations and decorators are two competing and incompatible ways to compile the @ symbols that we often see attached to Angular components. Annotations create an "annotations" array. Decorators are functions that receive the decorated object and can make any changes to it they like.
Traceur gives us annotations. TypeScript gives us decorators. Angular 2 supports both.
One of the humps you'll likely run into when learning about Angular 2 is this initially non-obvious distinction between...
Angular 1 and Angular 2 are philosophically different.
Angular 1 is at heart a DOM compiler. We write HTML, and the Angular compiler takes care of compiling it into a web application.
If we want extra behaviour, we extend the compiler by adding more directives.
I should start out by saying that I have no axe to grind here. I'm just a guy who enjoys learning things and using new technology.
Mongo as a technology has taken some heavy flak, particularly from the SQL crowd. It's missing a few features, has bugs, and does things in an unfamiliar way. This has made a lot of people rather cross which has lead to a surprising outpouring of hate for a technology that is actually rather good.
I have very much enjoyed my Mongo journey. Perhaps you will too.
Rails concerns have come in for a bit of a kicking lately, service objects clearly being a better solution in many instances, but I think there are valid use cases.
Concerns address the "bloated model" problem that plagues older Rails instances, where more and more methods are added to your fat models until they become huge and unwieldy. This slows your development as you now need to spend longer reading through code in order to get work done.
A concern is simply a module that you can mix in...