The Future of AngularJS
docs.google.com
docs.google.com
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.
Let me remind you then:
"Do ES6 modules have all the dependency injection stuff the Angular developers wanted?"
>Explaining in further detail: a feature of some module systems is dependency injection
An orthogonal, non relevant feature, that has nothing to do with the core role of a module system.
That some module systems have this frankensteinian stuff included doesn't mean much.
Again, read HN guidelines, your account is quite new and it's very obvious you haven't done so yet.
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.
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.
1) If it's actually 7% of your revenue as opposed to just global traffic stats.
2) If entrenched IE customers would actually stop using your product rather than just install another browser.
3) If the cost of maintaining shims, backwards compatibility and ultimately just falling behind the competition in both experience and features is less than that potential 7% market.
So my point is that of that 7% that are using older versions of IE, it's probably a much smaller number that would not be willing or able to use an alternate browser to run your web application if they find value in it.
To rephrase, makers of new tools, as a rule, tend to be forward-looking. This is what I'd expect. As corollary to this, at some point it no longer makes sense to support legacy technology. This produces a tradeoff within the aforementioned business case: is it worth the product constraints, effectively an externally imposed technical debt, to support that part of your market? How will you fare versus your competitors going forward if you do, or do not, support the legacy tail?
I'm not saying I think everyone should be building for IE8. I wish we could stop. But it's also not always just as easy as saying give up 5% of your potential users. The HN crowd is so often consumer focused and incredibly out of touch with the enterprise markets (this is not an argument against the parent comment, but an overall trend I notice on HN).
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.
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.
Of course, its those creaky old IT departments.
Stop catering to these old browsers and people who want your app will download a capable browser or pressure their IT or just use their phone.
If they can deal with Y2K, they can deal with something this trivial.
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.
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.
---