Git is distributed, but obviously you're going to have a canonical repository somewhere (git.kernel.org, for instance). Decentralization doesn't mean getting rid of a canonical place where approved patches end up, and you really aren't going to see canonical repositories disappear, we have them for a good reason.
However, there is something to be said about mirroring canonical repositories for accessibility.
> I wouldn't try to use Angular for an HTML 5 game, for example, though there's a good chance I wouldn't use jQuery either.
I actually did use Angular for an HTML5 game last week as part of a demo for a conference. Admittedly it was a really simple game (tic tac toe), and it did use Polymer as well as angular, as sort of an experiment. But it worked pretty well, and only took about a day and a half to hack together, with realtime multiplayer and chat using socket.io.
Obviously you're going to run into things that Angular is not really ideal for, but we are trying to make it do what it does very, very well, so in the future it should be suitable for pretty much any mobile or desktop app.
---
This sounds like evangelism, which is not my intent, you're absolutely right about what you're saying, but it's true, sometimes a framework works (and saves a ton of time) that you'd otherwise spend hacking together something awful. Hopefully this mithril thing also saves people a ton of time without them having to worry about numerous other issues.
It's not shocking at all that they make people uncomfortable, just like it's not surprising that it's uncomfortable when someone points their mobile phone at you on the train.
It's not rocket science, I think people should be aware of when it's appropriate to have these things on their face, and when it's not. It's not important whether or not you are recording people, they don't know if you are or not, and they have every reason to be suspicious.
I'd like to think Angular 2 will be well received, even if we are probably checking off more than a few of these boxes (not that AngularJS 1.x doesn't, though)
Even if they can't make this effective (and cost effective) for people who have had the disease for over a decade, that's still fantastic news and a good reason to be hopeful. I'll drink to that.
I'm glad you're finding Angular is working well for you!
You may be (okay, considering what this article is about, you probably are) aware of this, but we're making an effort to drastically improve the performance of the dirty-checking algorithm. Miško wrote a draft paper (you know this, I know) regarding the dirty-checking implementation, and there's an implementation of it in Angular.dart.
I've been working on porting the Angular.dart implementation over to ES6 for the next iteration of AngularJS over the past couple of days, and it's actually pretty challenging, so I'm reaching out to people who are interested for help:
Some things I'm looking for is assistance in improving the tests, and implementing a high quality performance test, possibly using our benchpress library (http://github.com/angular/benchpress). I also would greatly appreciate hearing from people who are a bit more involved/experienced with ES6 might be able to offer some suggestions on how to organize the code, because Dart does not translate 1:1 into ES6, so some help there would be a big deal.
Anyone who is interested in contributing in some fashion, please, you're more than welcome to. We want AngularJS 2.0 to be super-fast, and the more help with this, the better.
I'm not seeing it in the latest Harmony draft, but it is already available in some implementations, and polyfills tend to have it.
(one of) The issue(s) which is coming up for us WRT O.o is that current implementations don't seem to work well with computed properties (IE es5 getter/setter functions), which is possibly a point of contention in the draft. Better to ask someone who is seriously paying attention to that stuff, though.
While I haven't used it personally, I've heard of people shipping Node.js as part of iOS apps (and, for that matter, as part of Firefox extensions), but even without Node.js, most of these devices will have some JS runtime, in or outside of a browser/webview.
As for Python, I would be less hopeful about the presence of Python on smart phones and tablets, although I suppose anything is possible.
Usually you are cross-compiling to target mobile platforms, so you don't generally need to worry about a given toolchain being present on the device itself.
I doubt you would be able to do "systems" level programming in either JavaScript or Python.
If you are thinking of cross-compiling, then you could look at Go from Google - it has many of the advantages of C, yet a lot of conveniences afforded by Python and similar languages.
I'm fairly sure they're not writing device drivers or TCP/IP stacks, so they likely don't depend on a systems level language. A lot of work has gone into enabling people to write their apps using these interpreted languages, but the availability of one particular language or runtime on a mobile device is not always guaranteed.
I think they're asking what their options are, really.
However, there is something to be said about mirroring canonical repositories for accessibility.