How Google broke the OSS compact with Angular 2.0(codebetter.com)
codebetter.com
How Google broke the OSS compact with Angular 2.0
http://codebetter.com/johnvpetersen/2014/10/27/how-google-broke-the-oss-compact-with-angular-2-0/
17 comments
From where I sit, it looks a lot more like python 2/3 stuff. Angular 1.3 will be around for a long time, there's talk about official google support for a year or more post-2.0 release. From there, the community can keep it up. It works fine.
Moving forward means moving forward. A 2.0 change is a lot of breaking changes, fine. And yeah, developing it all in secret (as the blog complains) isn't precisely the trad-FOSS way, but plenty of platforms and libraries get developed closed until they cross a critical threshold.
Would people rather Google didn't work on this stuff at all? Seems like they can't win.
Moving forward means moving forward. A 2.0 change is a lot of breaking changes, fine. And yeah, developing it all in secret (as the blog complains) isn't precisely the trad-FOSS way, but plenty of platforms and libraries get developed closed until they cross a critical threshold.
Would people rather Google didn't work on this stuff at all? Seems like they can't win.
And what is the deal with AtScript? If you are going to randomly "fork/borrow" a language you can at least consult the original authors. Typescript is inspired by C# not Java, so those are attributes - not annotations, and they are in square brackets not start with an @ character. And it's called 'reflection' not 'introspection' in C#.
Well.. annotations in VB.Net use <...> not [...] ... in the case of JS, [...] is deeply tied to arrays in the mindset, so using @ makes sense to me.
Honestly, I'd like to see some clear examples of how to consume/check for said annotations. Also, getting them in at least V8 in addition to traceur will go a long way.
Honestly, I'd like to see some clear examples of how to consume/check for said annotations. Also, getting them in at least V8 in addition to traceur will go a long way.
I was just having a conversation with a friend of mine regarding if we should spend more effort in learning Angular.
While I can understand making breaking changes, and sometimes very big ones, I feel like this timing is incredibly poor, and is coming when many people are just learning the framework. At this point in time I do not want to invest any more time in the framework or its changes: the stable version I use will soon be obsolete; I can't learn the "new" version or use the "new" version now; and I don't know when the point will come when the AngularJS core team - and Google - are happy with the decisions they have made, if the point EVER comes ( especially re: Google ).
I also feel that while they addressed many of the concerns that the community had, the decisions they made were not strictly speaking "necessary". For example, removing all the ng-* stuff "looks" nicer, but it is now less clear which code is repsonsible for handling that declarative behavior. I would have preferred a mechanism which allows you to specify other "included" directives in a directive definition in a clear and concise manner ( without hacking on compile or link functions ).
I think I'm going to try Ember or something else. I liked Angular for what it showed me - that a data binding approach could really ease the pain of radical design changes, for example - but I'm not going to be sticking with it after this project. Time to move on.
While I can understand making breaking changes, and sometimes very big ones, I feel like this timing is incredibly poor, and is coming when many people are just learning the framework. At this point in time I do not want to invest any more time in the framework or its changes: the stable version I use will soon be obsolete; I can't learn the "new" version or use the "new" version now; and I don't know when the point will come when the AngularJS core team - and Google - are happy with the decisions they have made, if the point EVER comes ( especially re: Google ).
I also feel that while they addressed many of the concerns that the community had, the decisions they made were not strictly speaking "necessary". For example, removing all the ng-* stuff "looks" nicer, but it is now less clear which code is repsonsible for handling that declarative behavior. I would have preferred a mechanism which allows you to specify other "included" directives in a directive definition in a clear and concise manner ( without hacking on compile or link functions ).
I think I'm going to try Ember or something else. I liked Angular for what it showed me - that a data binding approach could really ease the pain of radical design changes, for example - but I'm not going to be sticking with it after this project. Time to move on.
> timing is incredibly poor, and is coming when many people are just learning the framework
For a successful project, timing will always be "incredibly poor", for a popular project always attracts new developers, often at an accelerating rate.
If you only plan to make serious changes when very few new developers pick your project, it might be belated because your project is already dying.
For a successful project, timing will always be "incredibly poor", for a popular project always attracts new developers, often at an accelerating rate.
If you only plan to make serious changes when very few new developers pick your project, it might be belated because your project is already dying.
When the docs are still in such bad shape and the number of books doesn't even come close to other niches of our industry, it's really bad timing.
They need to solidify what they have and make sure they're the stable choice.
With the latest announcements, I'm tempted to check out React and just fall back to jQuery because the learning curve is too steep. I even run the Learning AngularJS newsletter and I'm saying this! :(
They need to solidify what they have and make sure they're the stable choice.
With the latest announcements, I'm tempted to check out React and just fall back to jQuery because the learning curve is too steep. I even run the Learning AngularJS newsletter and I'm saying this! :(
I had a lot of issues, from a conceptual standpoint that pushed me away from using angular... parts I really liked or wanted to like, but others were just cumbersome to use/implement. I'm using flux/react currently, but in 2-3 years that may change to Angular 2.
I think this article has a good point re community building. When a group of people move, it takes more effort to get them to start and stop (social momentum). Transparency of the source of software allows the external community to plan and train, and do other group-oriented things that a single-developer shop can do with more agility.
If Angular 2.0 is architected the way it says in the docs, then it's really scary. They obsoleted everything - something which many developer put a lot of time and effort into. It doesn't matter if the design is better; what matters is a nice clean migration.
Atleast for me, if this change goes through, I won't return to Angular. Angular 3.0 might rewrite everything again for all I care. I just wouldn't trust the angular devs anymore.
Atleast for me, if this change goes through, I won't return to Angular. Angular 3.0 might rewrite everything again for all I care. I just wouldn't trust the angular devs anymore.
I see it the exact opposite way. So many projects get encumbered by the decisions made early in their development. I have a current project using Angular 1.3, it works, and I will probably never upgrade it, and that's fine
My next project however will be able to use all of the lessons which led to 2.0. Innovation is a part of tech, either the Angular team will do it, or someone else will.
My next project however will be able to use all of the lessons which led to 2.0. Innovation is a part of tech, either the Angular team will do it, or someone else will.
I've grown kind of tired of these sorts of posts, where people assume that OSS means handling the community exactly the way you prefer.
Does it have an OSS license? Do they adhere to it in practice? If so, then your complaint isn't one of OSS, but rather community politics.
Does it have an OSS license? Do they adhere to it in practice? If so, then your complaint isn't one of OSS, but rather community politics.
There is some implicit expectation when people release a project as open source. As a OSS author if you don't understand this expectation, your project is going to hit massive roadblocks sooner or later.
The only expectation for me is that I can fork the project in accordance with their chosen license. Expecting anything else is a bit too entitled for me.
There are tons of different styles of project management. I don't see the point in claiming one as the "OSS way." I think it's fair enough to criticize someone for their management style in itself; additionally criticizing them for breaking the "OSS contract" or "going against the spirit of OSS" is kind of silly IMO, and a cheap way to score argument points and pageviews.
There are tons of different styles of project management. I don't see the point in claiming one as the "OSS way." I think it's fair enough to criticize someone for their management style in itself; additionally criticizing them for breaking the "OSS contract" or "going against the spirit of OSS" is kind of silly IMO, and a cheap way to score argument points and pageviews.
In this case, the Angular team both via angular-dart and via the proof of concept projects on github, and related issues lists has been very open in this process.
I'll feel the same pain as everyone else when 2.0 is released, but instead of wasting time complaining about it, I'll pick it up, embrace it, and keep my whimpering to myself.
NG Core is kind enough to share their work with me. Sure, I've invested time in learning it, but they don't owe me anything for that investment.
Feel free to apply down votes here to express your anguish.