caitp

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.

--resist strong urge to speak ill of both products-- god, that is a very difficult temptation to resist :(

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.

yes, https://news.ycombinator.com/item?id=6747373 and likely other times too. (edit: this is more of a parody, but you could probably consider it trolling in some sense)

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:

The repository is at http://github.com/caitp/watchtower.js, and will probably be moved into the angular org once it's a bit more fleshed out.

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 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.

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.

Don't you hate it when the answer you want to give to a question isn't an option on the survey?

It would be a net benefit for everyone if people stopped believing San Francisco was some kind of "technology/business mecca" or something.

We need budding tech sectors all over the world, and we don't need everyone trying to move to California (and a lot of us frankly don't want to move to California, to begin with).

California doesn't offer anything which can't be found elsewhere.

You want to avoid making it look like it's actually "endorsed" by Google, or a product of Google's, despite interop with one of Google's products. The name can be an issue here, so you might want to come up with something spiffier and original, and point out that it works with Google's service elsewhere.

When recruiters contact you, GPA doesn't tend to come up at all, at least in my experience.

IQ is not "cognitive ability", it's a fallible (and arguably biased) quantification/quotient of a (not exhaustive) set of measures of (some form of) cognitive ability.

People generally don't have their IQs "measured", and even when they are, the things they are kind of good at predicting are only a small subset of important qualities, so it would hardly be a good measure by which to compare applicants.

I think the problem you have with this is that you're assuming "high IQ" and "smart" are automatically the same thing. A high IQ is only one slice of the "smart" pie.

Myself and plenty of other women are absolutely involved in technology (and loving it).

But, is software development really "power"? Is it really "changing the world"? Is it really all that meaningful? This is where I start to get a bit skeptical. If we are changing the world, we certainly aren't necessarily changing the world for the better. We are not eradicating poverty, disease, or violence and abuse by writing software.

Maybe people who are looking to change the world are looking to do that in more meaningful ways, where they can actually have a real impact on real peoples lives.

Maybe there are other, more cultural reasons why the field isn't entirely flooded with women. Maybe we aren't encouraging young girls to be curious. Maybe we aren't glamourizing it with TV and movies.

Maybe it's a lot of things, and maybe a lot of things have to change before this becomes something that your average 9 year old girl will want to take on.

In the mean time, lets not pretend that women aren't changing the world in important ways already. We can do better, but don't be dismissive of women who have decided to go into medicine, or city planning, or agriculture, or astronomy, or law, or architecture, or writing, or academia. They're changing the world too, and most likely in much more meaningful and valuable ways than we are in tech.

The angularjs.org sites are indexed, just by using a trivial nginx directive to selectively serve partials to crawlers. All of the angularjs.org apps still rank fairly well using this strategy.

This isn't always appropriate of course, those apps aren't really relying on data from a database, they're proper SPAs. But as noted by others, there are ways to fool crawlers if it's something you want to do.

Generally though, the feeling is that crawlers not executing JS is going to end, and the problem will go away on its own.

That might be a bit of an exaggeration, although on the Angular side, we'd certainly like to have it pref'd on by default this summer (as unlikely as that may be).

Anyways, I really think people are sort of attributing malice to Glazkov's remarks where none really ever existed, WRT shipping the shadow DOM in its current state.

Somehow, with stories like these being so common in the news, I just don't think I want to live in that country. Apart from warmer weather, I'm not sure there's anything worth moving for.

In addition to the big google projects using it (Chromium, V8, WebRTC/jingle, etc), there's also Joyent's Node.js (and forks, + numerous node packages containing native code), as well as numerous private projects that I've been involved with. Unfortunately, it hasn't taken off too much in the open source community apart from the above mentioned big name projects. Better documentation and more visibility could probably make that happen, though.

https://xkcd.com/927/

But on a serious note, I really want to see Gyp become more popular, for the simple reason that integrating multiple Gyp projects is essentially zero-effort.

It's a beautiful way of working, even though Gyp certainly has room for improvement.

FB React is a good example because it's living more in the presentation layer. But Custom Elements offer some things that React doesn't (as far as I'm aware).

One is better encapsulation, another is a well defined styling system (although obviously this article shows that this is not a super simple problem to solve, I'm certain that a good way of doing this will be around before too long) --- finally, and the most important thing, is that it's just baked into the platform itself, so interop between different frameworks is less of a pain.

For instance, suppose you want to use a particular Ember component in your Angular app. You probably don't want to include the entire Ember environment, and you want it to play nicely with Angular's idea of data binding and local scopes. Can you even do this? If you can, how much effort does it take, and how much does it degrade the application?

So, we've got: interoperable components/widgets. Easily style-able widgets. Elements with some semantic purpose. Simplified documents. Reusable templates (which, once HTML imports are pref'd on by default, should be easily host-able on CDN hosts).

There are a lot of benefits to baking this into the platform, despite making the platform an even bigger, crazier mess than it already is. It should hopefully give us better (and better designed) tools to work with.

Granted, I'm not saying it's going to solve every (web) problem ever, nothing ever does.

When you have time (and are allowed to), it would be really cool if you could submit a patch against http://github.com/angular/builtwith.angularjs.org. It's not necessarily the simplest process, but there's a simple server in the repository so you can preview the change.

Just ping me on the PR and I'll be happy to merge that for you

Are you able to identify the bank? Are any of the public-facing apps using AngularJS?

We'd like to showcase successful and interesting Angular apps on the website(s) (by which I mean angularjs.org/angulardart.org and builtwith.angularjs.org, etc)

While you're perfectly allowed to disagree, it sounds like what you're saying is this:

"Collections of div-soup activated by jQuery plugins are the way to write maintainable web applications that make sense"

It's not as though Javascript has no role whatsoever in custom elements, but really, there's a lot to be said about how this way of working will be a huge improvement over the current jQuery + div-soup status quo.

Heh, merged =)

We love you too, Sean Caetano Martin!

Just to address a point made towards the end of the blog, we do realize that Angular is not a flawless framework, and we are absolutely open to hearing feedback from users of the framework, get your bugs fixed, and ship some elegantly structured, easily testable code.

We are making an effort to do a better job of communicating with our users (apart from the big internal apps). This can be seen in the new Angular community working group, as well as my own and Pawel's frequent activity on the IRC channel and mailing lists. So let us know what your issues are. And if you have time, take a stab at implementing a fix, too. Community contributions are welcome.

Git provides some amazing tools in a very accessible way:

  1) A great way to find regressions which is easy to automate (bisect)
  2) light-weight branches
  3) nice tools for dealing with patches (am, format-patch)
  4) rebase (squash, amend, fix bitrot)
  5) Super-simple submodules (compare this with gclient DEPS to get around SVN
     limitations!)

These basics are easy to learn, not demanding at all, and just feel good to use. I have trouble comprehending when people say it's difficult, especially compared to things like Mercurial (and the mq extension), or SVN.

The 1.x injector is not a very difficult pattern to understand, so if you're working with Angular you should pick up on it quickly.

However, for production apps, you're probably not using "magic" function annotation, at least not without the help of ngmin or a similar tool.

It's just a nice way to quickly write demonstrations and explain code. Arguably, the explicit annotations would not really inform you any better than implicit annotation, if you were unfamiliar with the framework.

So, I agree that explicit annotation is important, but I think the "magic" annotation also makes the framework a bit more accessible to new comers, and is also very handy for producing small demos, reproductions, or other small apps. The fact that we can offer the choice here is great.

A little bit of experience with the framework and all this stuff becomes pretty much second nature. I expect Ember or Knockout would be similar in that regard.

Basically, 1) understand the fundamentals of your framework. 2) use the right tools/methods for the right job. You can certainly write maintainable and understandable apps using all of the annotation styles.

At least, in my opinion.