What I don't understand is all the whining about posting slides.
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?
To be fair, this is the first time I've seen this. Not everyone gets to see everything as it comes out and I would argue that June (3 months ago) isn't exactly old news. Having said that I am really excited to see the future of Javascript isn't as ugly and hacky as it currently is.
I 100% agree, I just started using AngularJS and I'm very happy to see a preview of what I'll have to learn in the future and how current practices will change.
Neato. Angular reimplementing it's own module system (when many developers already have a large body of code in existing module formats, particularly AMD) was one of the things that turned me off when first looking at it.
Do ES6 modules have all the dependency injection stuff the Angular developers wanted?
I don't know. In a large AngularJS application I want the Angular module system separated from other JS modules. They are completely different things if you ask me.
Module system =/= Dependency injection.
AngularJS modules =/= CommonJS modules
Module system = way to FIND object definitions physically(files) or logically(name). Python has one, NodeJS has one.
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.
And ES6 definetly DOESNT DO dependency injection, ES6 gives JS a module system which is configurable.
When ES6 gets it's module system , people wont need require JS anymore, but it has nothing to do with AngularJS.
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.
Unfortunately, I didn't see improved documentation in their future vision...
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.
hahaha. Did you ust say "compatibility with older versions of IE".
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.
Well, the thing is both Chrome and Firefox get updated automatically but IE doesn't.
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.
Ah yes, the "creaky old IT department"... Gosh darn it, if it weren't for those old fogies and their weird inclination to worry about making sure things actually work, and their bizarre insistence of mapping technological choices to the strategic concerns of the business (as opposed to just providing the coolest new toys for all the geeks to play with) - then, we might actually be able to get something done!
Maybe what we need is a general strike. Have every app go dark for these old browsers on January 1st 2014 for one hour a day. Then double it every day until its 24/7.
If they can deal with Y2K, they can deal with something this trivial.
If you must support outdated versions of IE then your future is grim. The working tools you have today are all you will ever get. An expectation for ongoing framework support for these legacy environments is wholly unrealistic.
> If you must support outdated versions of IE then your future is grim.
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 hate IE compatibility too, but there's still a lot of people using them; ~5% use IE8, ~2 use IE7. What business is willing to give up 7% of their revenue?
This varies widely by industry. We sell software to insurance companies. 40% of our pageviews are IE8. Sure, we can choose to ignore those customers, but in our world that's a lot of money to leave on the table.
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).
as a supporting piece of anec-data I worked for an education startup in the uk - and we had to support IE 6 (six) as upwards of 50% of our userbase of high schools had locked in contracts with suppliers like RIM (not blackberry) and could not upgrade without incurring costs - which meant it did not happen.
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.
And to expand on your points, is there anyone that is an entrenched IE 7 or 8 user because they just love that browser. My guess would be not, and that instead they are just using that because it's the latest version of IE that they can get on their OS. Anecdotally, I've seen a number of large organizations that I work with allow installation of new third party browsers even though they stay at an old version of IE for compatibility reasons.
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 clarify, I'm fully aware that there's business to be had related to legacy browsers. I'm not arguing against the business case. If you've got a significant customer base with this need, then you'll have to choose tools that let you deliver.
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?
As soon as it is impossible to browse the web with old ie, users will be forced to switch. If you support old ie, you are contributing to it continuing to hang around.
You can get around the IE problem by using classes to call your directives rather than element tags. <div class="ng-view"></div> isn't as pretty, but it works in IE8.
Attributes also work for directives, though I like using ng-cloak as a class. I think in the future (next year, when my company will probably drop ie8 support) I'll start using custom tags.
There is a limit to how long developers will support these old browsers, even if they sell to corporations and institutions with backwards IT policies.
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.
The Shadow DOM seems like beautiful for reading/blocking output but I see most of my time with the "Expand Shadow DOM" option in the dev tools to see what the heck is actually going on during development.
Same with "Security at <something>" meaning something bad happened. There's another story on the HN homepage right now where I assumed it was a break-in, when in fact is was a preemptive strike.
I don't know...these slides seem to make sense and only took a minute to go through them. But I understand your complaint in general, because there's some slides that don't make sense out of context of the speaker's presentation.
Yeah but I don't like watching actual presentation videos, because then there is audio and they move at their own pace. I'd love to see more slides + detailed notes though.
I really cannot understand why this whole phase of "posting my slides" is becoming a big thing. Powerpoint presentations are useful in context. This link was of no use to me apart from some bullet points
Worked fine for me too. I think it might do that if you've already been logged into a Google account and signed out. Try deleting your Google cookie(s) entirely.
Being able to avoid $scope.$apply() will certainly be nice.
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.
... how does this have anything to do with DRY? You're calling $scope.$apply because you're re-entering AngularJs with new data and need to start off the dirty checking process.
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.
Parse.com has a perfectly capable REST API[1] that you can use with Angular's $resource. If you use Restangular, then your life becomes even easier. It won't be as convenient as using their JS SDK, but your code will end up looking much cleaner.
I've spent my fair share of time pouring over Parse's REST docs[1][2]. It's a fairly large undertaking to fully support all REST features, so it's still a decent trade-off to just use the JS SDK. If there are any Parse + Angular REST client projects, I'd be happy to contribute some code.
What I want to know about the future of AngularJS is: what is the state of server side rendering? We have some of our own ideas as to how this could work at https://starthq.com but I am hesitant to start implementing anything so as to avoid duplication of effort.
This does sound useful, but I'm not sure what it has to do with Angular. Are they going to create more resources with the assumption that HTTP 2.0 will fix it?
Personally, I liked that the slides are up there publicly, even if I don't get to see the talk to go with them - they function nicely as a brief overview to the future of Angular, letting good devs fill in the rest. Much of this isn't new, but I liked seeing some example code snippets comparing current and future syntax.
I heard end of 2013 a year ago , unlikely , their spec has too many stuff. The only things devs need urgently is the module system , let , const , proxies and the new data types ( sets , maps , weakmaps , etc ... ), the rest can wait IHMO.
When ECMAScript 6 "happens" (any idea when that will be?), will we actually be able to use it or will we have to stick to old things due to browser compatibility?
does anyone know if there was a presentation that went along with these slides. it would be great to be able to see it. @briantford if you see this, we'd love to see more of the meat behind the bullet points. cool stuff though!
I would guess it was originally "ng" for next generation, and then they wanted to come up with some kind of pronounceable name when they made it public. I'm just glad it's easy to google!
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?