This is fresh off the presses, answers hot questions in the angular community, and obviously people are upvoting it. If you're aware of what's happenning in Angular, every slide stands on its own and has useful info.
Can we please give all the moaning about format a rest please?
It's really exciting. This is a good summary of the future though.
Do ES6 modules have all the dependency injection stuff the Angular developers wanted?
Module system =/= Dependency injection.
AngularJS modules =/= CommonJS modules
Dependency injection = way to WRITE objects by creating dependencies between them in order to separate concerns.
RequireJS = gives Javascript a module system
( fetching files according to the module name to
find module definitions ),which is
configurable since JS doesnt have one.
AngularJS = instanciate objects according to their
defintion and the definition of its dependencies =>
doesnt look for files in a path to find the definitons.
When ES6 gets it's module system , people wont need require JS anymore, but it has nothing to do with AngularJS.
- Nowhere in my post did I say a module system was dependency injection
- Nowhere in my post did I say angular JS modules were CommonJS.
Please don't use uppercase for emphasis, see http://ycombinator.com/newsguidelines.html
Explaining in further detail: a feature of some module systems is dependency injection (yes, dependency injection can also be performed outside a module system, but the slides discusses module systems so we will too).
DI gives module systems the ability to instantiate objects using different dependencies. This is handy for things like testing, where eg, a name that would normally resolve to a network API module would instead be resolved to a stub module with pre-canned responses, so any calls to that network API module return consistent responses.
Lack of dependency injection in existing JS module systems (you can do it in AMD, but using file paths so it's kind of hacky) is cited in the angular docs as the reason Angular includes its own unique module system.
Weather people still use AMD or CommonJS or Angular modules after ES6 modules really depends on the feature set of ES6 modules. Hence asking about the feature set of ES6 modules.
I'm not sure how a lot of those ideas will work with compatibility with older versions of IE. You already have issues using the element tags for new attributes.
I'll probably get downvoted for this but.
If you want to maintain "compatibility with older versions of IE" try an older version of HTML, an older version of CSS, an older version of javascript and an older x86 processor, and an older version of windows (95 sounds nice).
Sorry.
If future features should try to remain compatible with older versions of IE we will get very little innovation.
So the problem will not IE versions that are already old (IE6, IE7) but current versions of IE - even future versions before they implement these new standards.
As these features roll out to Firefox and Chrome, users of these browsers will have to them because of the auto-update pretty quickly.
Eventually IE will implement them, maybe in version 12, and you'll have users still using IE10. Heck, maybe they won't be able to upgrade their IE because it won't run on their aging Windows 7.
Unless IE switches to the auto-update used by Firefox and Chrome, and stops dropping Windows versions in their new IE, I don't see the problem going away.
Hello from military industrial complex business world. A hundreds of billions of dollars market where exactly almost nobody uses latest firefox, chrome and quite a few use IE8.
What looks grim for you is a boon over here. Supporting IE8 puts money in the pocket, money in the pocket makes the future not so "grim" ;-) Saying you need latest Chrome or Firefox guarantees just getting laughed at and shown the door.
http://docs.angularjs.org/guide/ie
Agree that the documentation is still lacking.
Some companies and even healthcare institutions are seeing the light and upgrading their systems. As more and more do, it makes less and less business sense to support old browsers (fewer companies still using them, and it only gets harder to make a modern web-app work on them).
There is a huge cost to supporting old browsers. There IS a tipping point where it's just not worth it anymore.
So the companies/institutions that don't upgrade will soon enough be left behind. That's just the way it is.
Surely there is something to go with this slideshow?
(I won't go into the annoyance of having my focus split between the slide and the separate notes.)
Anyone got a link that is publicly accessible?
As it stands now, if you want to leave the Angular reservation and use something like the Parse JS SDK (which is a customized set of Backbone models) your code will be littered with $scope.$apply(). Not very DRY, and also adds, from the dev's point of view, a needless level of nesting functions.
This isn't repeated logic. This is a core function of the framework that's meant to be used exactly like that.
It's meant to be called that many times if you're doing that many things outside of Angular and need to sync your models.
---