caitp

However, there is something to be said about mirroring canonical repositories for accessibility.

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

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 think they're asking what their options are, really.

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

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.

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.

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.

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.

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.

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.

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.

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.

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

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)

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

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.

  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.

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.