Angular 2 Core(docs.google.com)
docs.google.com
Angular 2 Core
https://docs.google.com/presentation/d/1XQP0_NTzCUcFweauLlkZpbbhNVYbYy156oD--KLmXsk/
278 comments
> Sometimes I think Angular is mainly popular because it's supported by Google. If any regular developer made these drastic changes in HTML with non valid tags and attributes people would not be happy with that project.
This is a pretty interesting statement and I want to give it more thought. I've used Angular on plenty of projects and admittedly, It's felt a bit dirty to go back to spaghetti DOM that we worked for years to get rid of. All the books were saying to separate logic from our views. Now we're calling it declarative and it's acceptable again. I've been yelled at by other developers as if I should just forget the past few years and just get in line with what's currently the new hotness. Fine, I'm totally okay with embracing whatever is new and hot. But not just because it came from the same people that gave us Wave, Gears, GWT, etc. Let's not get involved in hero worship. All of those technologies had great ideas, yet were (overall) marked as failures. I'd love to have seen this same proposal come from some random Susan/Joe on their GitHub and see if it had been laughed off the stage for the same reasons I mentioned earlier.
This is a pretty interesting statement and I want to give it more thought. I've used Angular on plenty of projects and admittedly, It's felt a bit dirty to go back to spaghetti DOM that we worked for years to get rid of. All the books were saying to separate logic from our views. Now we're calling it declarative and it's acceptable again. I've been yelled at by other developers as if I should just forget the past few years and just get in line with what's currently the new hotness. Fine, I'm totally okay with embracing whatever is new and hot. But not just because it came from the same people that gave us Wave, Gears, GWT, etc. Let's not get involved in hero worship. All of those technologies had great ideas, yet were (overall) marked as failures. I'd love to have seen this same proposal come from some random Susan/Joe on their GitHub and see if it had been laughed off the stage for the same reasons I mentioned earlier.
> All the books were saying to separate logic from our views
It doesn't matter what the books say. Or rather - you've got to understand the reason for the advice - not just learn to follow the advice.
Programming abounds with maxims. However you can't capture a complex truth with a glib catchphrase. Everyone is trying to achieve the same ends - ease of development without sacrificing maintainability (to give a very simple example).
Catch-phrases such as "separate your logic from your views" was meant in a specific context. If you etch it in granite and pass it on to future generations it won't always embody the practical truth it was meant to convey.
So - we should remember the catch phrases but understand their context - and therefore we might hope to understand the more subtle and less easily stated truth behind the one-liners.
It doesn't matter what the books say. Or rather - you've got to understand the reason for the advice - not just learn to follow the advice.
Programming abounds with maxims. However you can't capture a complex truth with a glib catchphrase. Everyone is trying to achieve the same ends - ease of development without sacrificing maintainability (to give a very simple example).
Catch-phrases such as "separate your logic from your views" was meant in a specific context. If you etch it in granite and pass it on to future generations it won't always embody the practical truth it was meant to convey.
So - we should remember the catch phrases but understand their context - and therefore we might hope to understand the more subtle and less easily stated truth behind the one-liners.
Exactly. There is almost no advice in programming which applies to all situations. The trick is knowing when not to follow the advice, and that cannot be explained in a one-liner.
Or, as the tao of programming says:
There once was a Master Programmer who wrote unstructured programs. A novice programmer, seeking to imitate him, also began to write unstructured programs. When the novice asked the Master to evaluate his progress, the Master criticized him for writing unstructured programs, saying, "What is appropriate for the Master is not appropriate for the novice. You must understand Tao before transcending structure."
Or, as the tao of programming says:
There once was a Master Programmer who wrote unstructured programs. A novice programmer, seeking to imitate him, also began to write unstructured programs. When the novice asked the Master to evaluate his progress, the Master criticized him for writing unstructured programs, saying, "What is appropriate for the Master is not appropriate for the novice. You must understand Tao before transcending structure."
It is also a very productive solution to front-end development. Regarding the mix of logic and views there seems to be more and more projects that thinks this is ok. React also mixes the two, maybe even harder than Angular. If you want to create component you have to have a component-view and component-logic as one pair and they will probably always be depending on each other. That said you can say that all single page applications can put a lot of their logic on the server, very clearly separated from the views.
> Sometimes I think Angular is mainly popular because it's supported by Google. If any regular developer made these drastic changes in HTML with non valid tags and attributes people would not be happy with that project.
Yes, the Google Cargo cult is frightening. Things that previously where scorned at is now raised to the skies.
But we have to remember that is also a completely new generation of developers out there who have not lived thru the entire painful history of web development, so therefore the same mistakes will repeat it selves.
It should be obvious now by most rational people that Angular 1.x is a dead end and if you build your own architecture around it you will continue to dig yourselves a deeper and deeper hole that will become harder and harder to get up from.
Angular 2 looks more promising with it's modularity and that should be the lessoned learned.
The web is just a way too fast moving target that any framework can keep up with, because the idea of a framework is the opposite for fast moving progress, i.e. stabilization of risks. And thats why so many javascript frameworks have already died even thou the web is really young.
The road ahead must be modularity and not the the way of the monolithic frameworks. Interoperability and interchangeability. Things we ought to have learned after the Prototype.js years. Or after the Dojo years. Or after the ExtJS years. Or ...
Yes, the Google Cargo cult is frightening. Things that previously where scorned at is now raised to the skies.
But we have to remember that is also a completely new generation of developers out there who have not lived thru the entire painful history of web development, so therefore the same mistakes will repeat it selves.
It should be obvious now by most rational people that Angular 1.x is a dead end and if you build your own architecture around it you will continue to dig yourselves a deeper and deeper hole that will become harder and harder to get up from.
Angular 2 looks more promising with it's modularity and that should be the lessoned learned.
The web is just a way too fast moving target that any framework can keep up with, because the idea of a framework is the opposite for fast moving progress, i.e. stabilization of risks. And thats why so many javascript frameworks have already died even thou the web is really young.
The road ahead must be modularity and not the the way of the monolithic frameworks. Interoperability and interchangeability. Things we ought to have learned after the Prototype.js years. Or after the Dojo years. Or after the ExtJS years. Or ...
Angular is meant for complex application development.
For example, say you want to create an online assessment player for taking exams. You need a service that can maintain state for the whole application (example: time elapsed, which questions the person got right/wrong, etc.), and then you need highly modular question components that can plug into a common question model to generate common answer objects for answer submission, display of common question elements such as the question #, etc.
Say you were then handed requirements that you needed to support taking some assessments while offline and submit the answers as soon as the user goes back online (say for a self-study assessment and not a high stakes exam). All of this then has to be completed in two months, and from scratch since it would be impossible with the previous code.
From my experience, Angular has facilitated meeting these deadlines with each team I have been on (my example is a real world experience of mine) & allowed companies I have worked at to maintain a high level of quality - the clients have raved about the quality of the applications. Part of this is because Angular has allowed the companies I have been at to think about high level architecture, but the other half has been with the ease of unit testing with Angular. I have no doubt that other companies can tout similar experiences with [insert framework here], which only serves to emphasize that team work is more important than developer opinions - if most of your team prefers doing something [insert different way] & it doesn't have huge technical ramifications, then it's worth deviating from your opinions to the different way in order to keep things moving.
For example, say you want to create an online assessment player for taking exams. You need a service that can maintain state for the whole application (example: time elapsed, which questions the person got right/wrong, etc.), and then you need highly modular question components that can plug into a common question model to generate common answer objects for answer submission, display of common question elements such as the question #, etc.
Say you were then handed requirements that you needed to support taking some assessments while offline and submit the answers as soon as the user goes back online (say for a self-study assessment and not a high stakes exam). All of this then has to be completed in two months, and from scratch since it would be impossible with the previous code.
From my experience, Angular has facilitated meeting these deadlines with each team I have been on (my example is a real world experience of mine) & allowed companies I have worked at to maintain a high level of quality - the clients have raved about the quality of the applications. Part of this is because Angular has allowed the companies I have been at to think about high level architecture, but the other half has been with the ease of unit testing with Angular. I have no doubt that other companies can tout similar experiences with [insert framework here], which only serves to emphasize that team work is more important than developer opinions - if most of your team prefers doing something [insert different way] & it doesn't have huge technical ramifications, then it's worth deviating from your opinions to the different way in order to keep things moving.
> On most projects handlebars and correct proper design patterns in code is enough to keep HTML out of javascript and keep basic organization.
Yes, but as a team you have to come up with a correct proper design pattern like that, and get everyone to follow that. I've done that in a Backbone project (which we're moving to Angular atm), and it's a lot of work - not to mention you feel like you're re-inventing the wheel there. AngularJS is a lot more opinionated about how your application should be built, which for new team members is very useful - they don't have to learn Backbone + your own application design, but just AngularJS.
And in large projects / large teams, this is important.
Yes, but as a team you have to come up with a correct proper design pattern like that, and get everyone to follow that. I've done that in a Backbone project (which we're moving to Angular atm), and it's a lot of work - not to mention you feel like you're re-inventing the wheel there. AngularJS is a lot more opinionated about how your application should be built, which for new team members is very useful - they don't have to learn Backbone + your own application design, but just AngularJS.
And in large projects / large teams, this is important.
I see Angular 2 as more of going native, conforming with the Web Components API as well as adopting modern ES6 (since it's being finalized this year and being implemented almost everywhere).
I like that they've modernized their API, because of how it is designed currently it would be hard to take it to the next level using ES6, Angular 2 is a good call.
I like that they've modernized their API, because of how it is designed currently it would be hard to take it to the next level using ES6, Angular 2 is a good call.
I've been using Vue.js recently, it's a lot like Angular (inspired by?), without all the crazy nonsense: http://vuejs.org/api/
Is it really comparable? The two-way binding is just a small part of Angular and not something you use that often in most applications.
Well, one-way binding is pretty important for most frameworks. The reason I say it is inspired by Angular is that it has a similar separation of concerns with directives etc.
Terrible name.
Edit: Other framework name ideas ~ Modil.js, Controllr.js, Framework.js, Class.js, js.js
Edit: Other framework name ideas ~ Modil.js, Controllr.js, Framework.js, Class.js, js.js
You might want to have a look at Mithril, it's extremely minimalistic and fast: lhorie.github.io/mithril/mithril.html
Would you be able to embrace Angular if it became a de facto standard? Because it seems pretty close to doing that. Interesting stuff.
No way. And I very much doubt it is anywhere close to becoming any kind of standard.
If Angular would become standard then the fast paced progress in browser technologies will definitely grind to a halt. It will be Pax Microsoft all over again.
This was my thought, as well. On the one hand, I want to position myself where the jobs are plentiful. It's not a choice, but a necessity.
On the other hand, I lived through Pax Microsoft and it was often not pretty.
It's interesting living through times of viciously fast change in one's field of endeavor.
On the other hand, I lived through Pax Microsoft and it was often not pretty.
It's interesting living through times of viciously fast change in one's field of endeavor.
I've been using Knockout.js and it's wonderful. Way better than Angular, which is too opinionated for me. I can read the entire source code and understand it.
I'm a fan of Knockout too, but it only handles part of Angular's functionality. It doesn't do routing, DI, resources... and you have to build all that from other libraries.
There is a library called "Durandal" that is built on top of knockout, and pulls in routing, DI, etc. : http://durandaljs.com/
Unfortunately, the developer has joined the Angular team and has basically said the next version of durandal is angular.
Unfortunately, the developer has joined the Angular team and has basically said the next version of durandal is angular.
I used knockout in a previous project, and it was really good, but (going from memory of using knockout), Angular has quite a bit with respect to managing your entire app and modularizing it. Knockout seems more like react to me, and I suspect it just didn't get as much support because it was from Microsoft.
Knockout didn't come from Microsoft, it's not a Microsoft product, but it did come from a Microsoft employee. I suppose for the Silicon Valley crowd that's enough of a "black mark" to avoid it. Meh. I don't care if tons of people use it because it's just one simple piece of the puzzle (that I can maintain myself if needed). Also Knockout added a feature called "Components" to version 3.2 which enables modularization similar to Angular.
That Angular wants to manage the whole app is exactly why I probably won't use it for my own projects. I don't want to build "Angular apps" I want to build web apps. Angular seems unstable too, with regards to backward compatibility - barely supporting IE8 in 1.2, dropping it in 1.3 and then introducing all sorts of major breaking changes in 2.0 - no, this kit is not for people like me who want stability. Meanwhile, even Knockout's newest features work all the way back to IE6.
That Angular wants to manage the whole app is exactly why I probably won't use it for my own projects. I don't want to build "Angular apps" I want to build web apps. Angular seems unstable too, with regards to backward compatibility - barely supporting IE8 in 1.2, dropping it in 1.3 and then introducing all sorts of major breaking changes in 2.0 - no, this kit is not for people like me who want stability. Meanwhile, even Knockout's newest features work all the way back to IE6.
I want to be excited, but at the moment there's just so much new and unknown stuff I'm seeing that I'm just not sure. I don't like the new template syntax; html attributes with parentheses and whatnot just look non-standard and I don't really see why they did all that. I really need to dig into the design documentation and find out the whys behind all of these new features.
ES6 is also new, of course; when I first saw Angular 2.0 code, I didn't like it - mostly due to DI, which instead of a single argument in a simple function, now consisted of three different statements to have one service injected, which just feels non-DRY.
ES6 is also new, of course; when I first saw Angular 2.0 code, I didn't like it - mostly due to DI, which instead of a single argument in a simple function, now consisted of three different statements to have one service injected, which just feels non-DRY.
I've spent some time with di.js [0], and it actually allows a few different ways of handling injection, one of which is simple type annotation, i.e.:
If anything, I think the upshot is that DOM handling has been pushed further to the edges, and the emphasis is on pure composition of classes and data structures, with less boilerplate, hand-waving, and framework-centricity.
[0] https://github.com/angular/di.js
class Foo {
constructor(bar: Bar, baz: Baz) {
...
}
}
If anything, I think the upshot is that DOM handling has been pushed further to the edges, and the emphasis is on pure composition of classes and data structures, with less boilerplate, hand-waving, and framework-centricity.
[0] https://github.com/angular/di.js
I disagree. New syntax actually gives much more for compatibility with other technologies and IDE integration. Also clean visual difference between events and properties - big thing.
Not valid HTML... Well, not so high price.
That's a fair point. Being able to differentiate complex directives from attributes greatly helps separate the concerns visually.
Even though this is still called "Angular", this new version has barely any resemblance with the previous one, it's really a totally new framework.
It's a bit sad to think that all this knowledge I have of Angular 1 is now obsolete but I'm excited to dive into this new framework. If it's half revolutionary as Angular 1 was, it's going to be a pretty interesting time.
It's a bit sad to think that all this knowledge I have of Angular 1 is now obsolete but I'm excited to dive into this new framework. If it's half revolutionary as Angular 1 was, it's going to be a pretty interesting time.
I have to agree. Will there be backwards compatibility? If not, upgrading to angular 2 is going to require so much work and we'll probably end up switching frameworks. This could end up like Python 2 & 3.
It is not an upgrade if your old stuffs stop working. Man, 1.0 used to mean something.
What did 1.0 used to mean? I thought that major version upgrades typically mean that backwards-incompatible API changes have been made.
It used to mean that it is stable and it will carry on working as far as it can to the future major versions or until it is end of line of the product.
So I can understand if Angular 1.0 stopped working on Angular 4.0 or 5.0. Breaking apps just on one major revision number is really a bad way to manage frameworks.
So I can understand if Angular 1.0 stopped working on Angular 4.0 or 5.0. Breaking apps just on one major revision number is really a bad way to manage frameworks.
It's what killed Drupal for me (and many others). Frameworks should provide for either a porting tool or backwards compatibility between major versions. Otherwise you alienate the people that trusted your in the first place.
Really? Well when it came to programs, one used to expect that older versions of the files used with that program would themselves be upgraded, or would just work. However, when it comes to languages, the major version number is used to indicate breaking changes.
So where does angular lie on that continuum?
So where does angular lie on that continuum?
You are probably thinking Python 2 and Python 3. For languages like C#, you can compile C# 1.0 code on C# 6.0 compiler mostly just fine. I bet this applies to C as well.
Hard to compare languages and frameworks in this respect. I think a better comparison is frameworks and operating systems. Imagine every major release of the linux kernel killing backwards compatibility with all older binaries and software written.
I think it is pretty exciting, in a way it is about the migration off the desktop. Over the last year we have transitioned from WPF thick clients to a SOA with a SPA front end using Durandal. Using Durandal along with knockout felt very natural to us. We chose Durandal in a large part because it was written by someone that thought like us and leveraged years of desktop best practices and applied it to what we viewed as the "wild west" that is web development. Glad to see Durandal concepts will be making it into a great project like Angular [0], Hope it is a peaceful revolution.
[0] http://eisenbergeffect.bluespire.com/angular-and-durandal-co...
[0] http://eisenbergeffect.bluespire.com/angular-and-durandal-co...
You just made your "python 2/3" syndrome. This will most probably kill AngularJS.
Yes, I think I will keep the reference to the slides for the case when people state Microsoft is the only company changing their mind about libraries.
I'm quite disappointed by this presentation, I see only new syntax everywhere for approximately zero benefit.
There is not even any mention to the Object.observe integration which would be the most exiting feature to improve Angular apps.
Angular looks and feels now like a Java framework, with ugly decorators and bloated APIs, that's really sad...
There is not even any mention to the Object.observe integration which would be the most exiting feature to improve Angular apps.
Angular looks and feels now like a Java framework, with ugly decorators and bloated APIs, that's really sad...
Came here to say this. In the last slide, when they were piling "RIP Directives", "RIP DI", "RIP Modules", etc., the only thing I had in mind was "RIP Angular". Very disappointing.
Really? Because I found angular to be highly convoluted in practice (and I have implemented it in practice).
Most of my team eventually settled on the conclusion that "the cognitive load of working through the implications of how these nested directives play out in an application is simply not worth it". Or something to that effect.
We all studied angular studiously, we all did our best to implement it in an effective and sound manner, and when things went wrong, and they always go wrong, the shear complexity of the framework tied our hands and forced us to do some very ugly hacks.
I look at our application as it stands, and I regret using angular.
If angular 2 is simplifying it's framework, the only thing I have to say to that is "Thank god, maybe I'll try it again"
Most of my team eventually settled on the conclusion that "the cognitive load of working through the implications of how these nested directives play out in an application is simply not worth it". Or something to that effect.
We all studied angular studiously, we all did our best to implement it in an effective and sound manner, and when things went wrong, and they always go wrong, the shear complexity of the framework tied our hands and forced us to do some very ugly hacks.
I look at our application as it stands, and I regret using angular.
If angular 2 is simplifying it's framework, the only thing I have to say to that is "Thank god, maybe I'll try it again"
Ever since reading Angular 2's goals, I put 2 and 2 together, the API was definitely going to have to change massively to accommodate ES6.
I'm sure they're using Object.observe it just wasn't mentioned in the presentation.
I'm sure they're using Object.observe it just wasn't mentioned in the presentation.
This is not even ES6, its some weird abomination (AtScript) on top of ES6.
We definitely wont be switching to Angular 2.0. Hello React.
We definitely wont be switching to Angular 2.0. Hello React.
I like how a lot of people see React as a full-on alternative to AngularJS. It's not, React is just for the view (think jQuery), you'll need other components or a lot of manual work to build a full application with React.
The awkward DI/module system, I'm fine with loosing that.
The router I will probably miss, but there are decent router components for react.
Services, factories and providers? Rather big words for some insignificant differences.
The only thing I'll really miss is simple data-binding - but it has too high of a performance cost anyway. Simpler server-side rendering and testing will more than make up for that.
Looking at directives vs react components, it seems like many Angular features are just workarounds for some of its design choices.
What bugs me the most is the cognitive dissonance caused by what I'm reading about the new Angular. Its supposed to be more modular. Yet the thinking shown on these slides is quite the opposite:
* it introduces attribute changes in the markup that seem disharmonious with CSS selector syntax.
* it now also coupled with a new language in order to be used sensibly, which reintroduces annotations - another language-in-language that may lack the proper design care to make it composable and usable (e.g. how do you combine 5 annotations into one? I have no idea, guess you'll have to copy-paste them)
In short, to me it seems like Angular 2.0 is intent on going forward with adding even more complexity while breaking backward compatibility. "More modular" is not what I'm seeing here at all.
The router I will probably miss, but there are decent router components for react.
Services, factories and providers? Rather big words for some insignificant differences.
The only thing I'll really miss is simple data-binding - but it has too high of a performance cost anyway. Simpler server-side rendering and testing will more than make up for that.
Looking at directives vs react components, it seems like many Angular features are just workarounds for some of its design choices.
What bugs me the most is the cognitive dissonance caused by what I'm reading about the new Angular. Its supposed to be more modular. Yet the thinking shown on these slides is quite the opposite:
* it introduces attribute changes in the markup that seem disharmonious with CSS selector syntax.
* it now also coupled with a new language in order to be used sensibly, which reintroduces annotations - another language-in-language that may lack the proper design care to make it composable and usable (e.g. how do you combine 5 annotations into one? I have no idea, guess you'll have to copy-paste them)
In short, to me it seems like Angular 2.0 is intent on going forward with adding even more complexity while breaking backward compatibility. "More modular" is not what I'm seeing here at all.
Oh, now I get it. The whole reason that AtScript exists is because they just can't give up the desire to have that bizarre Javaesque IoC container.
React's V and Angular's V aren't entirely compatible, in fact it's be nasty to use them together. Sure it's not a full alternative, but I believe when people are saying React, they are inferring that they will be using Flux with React (Or Backbone, Knockout, etc).
React can be much more than just a view. Even before integrating Flux or a lightweight library, React can be powerful.
React can be much more than just a view. Even before integrating Flux or a lightweight library, React can be powerful.
> React is just for the view (think jQuery)
That is comparing apples to oranges. I agree that React is a view layer, but jQuery is most definitely not. The only thing they have in common is that they (usually) act on the DOM in some way.
Agreed on your point about needing other components/architecture to use React.
That is comparing apples to oranges. I agree that React is a view layer, but jQuery is most definitely not. The only thing they have in common is that they (usually) act on the DOM in some way.
Agreed on your point about needing other components/architecture to use React.
While terribly written and in poor format, it has some semblance to ES6.
Object.observe is ES7
Yes but it's in Chrome Stable right now, I'm sure that when ES6 is implemented by vendors next year, they might throw in a few ES7 bits.
Agree 100%. Things like dependency injectors have no real place in JavaScript, where programmatic wiring and modules already solve the problem in an idiomatic way. Angulars modules factories services etc are absurd and attempt to reinvent what the language naturally provides.
>> where programmatic wiring and modules already solve the problem in an idiomatic way
Can't agree with that. Not sure what you mean by 'programmatic wiring' as it sounds vague, but certainly modules do not solve the same problem that DI solves.
Modules, (assuming you mean stuff you require() or equivalent), provide module-level dependencies but do not provide object instances. For example, if an instance of House requires a Door it is not enough to just require('Door'). You still have to do the equivalent of `new Door()` in your House module to get an instance. By doing so within the House module you just tightly coupled House to Door (your House now knows how to create Doors).
DI allows you to provide an object with object instances it depends on without tightly coupling said object to those dependencies (pass a Door instance into a House instance, advantage being you can pass in any type of Door and House doesn't need to care - thanks polymorphism)!
I'm not sure that's a great explanation, but it's worth trying every now and then right?
You seem to be making the argument that the language provides alternatives, and it's true that in dynamic languages you can eschew some of the benefits of DI by doing monkey patching instead (e.g. to mock out an object's 'tightly coupled' dependencies during testing), but to myself and many OOP proponents DI leads to cleaner design and simpler tests.
Can't agree with that. Not sure what you mean by 'programmatic wiring' as it sounds vague, but certainly modules do not solve the same problem that DI solves.
Modules, (assuming you mean stuff you require() or equivalent), provide module-level dependencies but do not provide object instances. For example, if an instance of House requires a Door it is not enough to just require('Door'). You still have to do the equivalent of `new Door()` in your House module to get an instance. By doing so within the House module you just tightly coupled House to Door (your House now knows how to create Doors).
DI allows you to provide an object with object instances it depends on without tightly coupling said object to those dependencies (pass a Door instance into a House instance, advantage being you can pass in any type of Door and House doesn't need to care - thanks polymorphism)!
I'm not sure that's a great explanation, but it's worth trying every now and then right?
You seem to be making the argument that the language provides alternatives, and it's true that in dynamic languages you can eschew some of the benefits of DI by doing monkey patching instead (e.g. to mock out an object's 'tightly coupled' dependencies during testing), but to myself and many OOP proponents DI leads to cleaner design and simpler tests.
For example, if an instance of House requires a Door it is not enough to just require('Door'). You still have to do the equivalent of `new Door()` in your House module to get an instance. By doing so within the House module you just tightly coupled House to Door (your House now knows how to create Doors).
So what? What is so bad about House and Door being "tightly coupled"? Here's a House constructor that can take any kind of Door instance:
So what? What is so bad about House and Door being "tightly coupled"? Here's a House constructor that can take any kind of Door instance:
function House(door){
this.door = door;
}
What you just wrote as a code example is Dependency Injection, it's just manual dependency injection as opposed to using an IOC container or any of the mechanisms Angular provides.
I am very much in favour of the approach you posted. That's exactly how I write my code (I don't currently use Angular), but yep ... that's DI. As James Shore said 'Dependency Injection is a 25-dollar term for a 5-cent concept'. [1].
What you show in that code example is what in my head I call "poor man's DI" or ... "passing stuff in" but it's actually my favourite kind as it demonstrates the fundamental idea and is easy to explain to people - as soon as you start talking about IOC and service providers things start to get murkier. I think that's definitely where Angular is losing some people. You can get a long way with the basic "poor man's" approach.
[1] http://www.jamesshore.com/Blog/Dependency-Injection-Demystif...
I am very much in favour of the approach you posted. That's exactly how I write my code (I don't currently use Angular), but yep ... that's DI. As James Shore said 'Dependency Injection is a 25-dollar term for a 5-cent concept'. [1].
What you show in that code example is what in my head I call "poor man's DI" or ... "passing stuff in" but it's actually my favourite kind as it demonstrates the fundamental idea and is easy to explain to people - as soon as you start talking about IOC and service providers things start to get murkier. I think that's definitely where Angular is losing some people. You can get a long way with the basic "poor man's" approach.
[1] http://www.jamesshore.com/Blog/Dependency-Injection-Demystif...
>When I realized it was "passing stuff in" I wanted to shout, I have done that for years!
Well, it's the "automatic" part that is important, not just the DI.
Well, it's the "automatic" part that is important, not just the DI.
So the setter gets called automatically, but now you have to store the object names as strings or in an XML file. How is that better?
I remember the first time I heard the term Dependency Injection. I sounded really advanced and I felt like a fool not knowing about. Like have been living under a rock for last years.
When I realized it was "passing stuff in" I wanted to shout, I have done that for years!
When I realized it was "passing stuff in" I wanted to shout, I have done that for years!
I felt the same way about DI until I watched this video: http://www.youtube.com/watch?v=_OGGsf1ZXMs
Fantastic video. I think it nails what DI is good for, and furthermore, what a DI framework is good for. Not only that, but it's a faaaaar more elegant solution than what's been in Angular so far.
var prod_dependencies = {
obj0: require('obj0'),
obj1: require('obj1')
};
var test_dependencies = {
obj0: require('mockobj0'),
obj1: require('mockobj1')
};
var dependencies = test_dependencies;
some_func(dependencies.obj0,dependencies.obj1);
You're slightly off on your definitions - what you show in that example is dependency injection.
You are injecting dependencies into `some_func` by passing them in. See my response to kyllo below.
I think what you are arguing against is using further patterns to facilitate dependency injection, e.g. IOC containers, or what Angular uses (service locators).
You are injecting dependencies into `some_func` by passing them in. See my response to kyllo below.
I think what you are arguing against is using further patterns to facilitate dependency injection, e.g. IOC containers, or what Angular uses (service locators).
Not all JSON are valid javascript: http://timelessrepo.com/json-isnt-a-javascript-subset
It isn't quite a solved problem in the regular ecosystem. Currently importation is rigid - you end up testing the functionality of what you are importing instead of purely the logic of your modules. The tests are polluted with logic that really tests both the details of how an api provided by another library functions under the hood.
DI is the solution to that. It has every place in a language like JS, and I am excited with having it available.
DI is the solution to that. It has every place in a language like JS, and I am excited with having it available.
The topic of DI and/or IOC in dynamic languages is an interesting one.
I've seen a similar debate play out in the Python world and the debate seems to polarize into two camps:
"You have never built anything complex enough and therefore you don't understand the benefits of DI/IOC"
vs.
"You've come to a dynamic language from some verbose public static void main hell-hole and are suffering from some form of Stockholm Syndrome"
I've seen a similar debate play out in the Python world and the debate seems to polarize into two camps:
"You have never built anything complex enough and therefore you don't understand the benefits of DI/IOC"
vs.
"You've come to a dynamic language from some verbose public static void main hell-hole and are suffering from some form of Stockholm Syndrome"
I'm not sure I've seen a framework with such a drastic API change, particularly such a young API. I find that very threatening. Having spent a considerable amount of time learning and working with Angular.js, not only does this appear to be massively breaking changes, but it would also break 3rd party directives which has been a great benefit to building the Angular community.
This makes me think that Angular didn't think through their API for the 1.0 release. I would have thought Angular could have been written to improve the performance where needed without such drastic changes to the framework.
This makes me think that Angular didn't think through their API for the 1.0 release. I would have thought Angular could have been written to improve the performance where needed without such drastic changes to the framework.
Angular was started 5 years ago.. Node was barely a proof of concept, and the JavaScript tooling at the time was centered around jQuery.. version 2 looks to be 1-2 years away, and the changes they make are really nice. I've chosen React + Flux for my current development, but in 2-3 years may well be looking to Angular 2.
There's a lot to by critical about Angular... least of which is that it's own dependency system doesn't play well with others. The reliance of jquery is pretty heavy (since most wind up including the full version, and the light version is loaded). There's a lot of extra boilerplate that the new design will tear down.
With node's tooling in current JS development, package management and modularization have become really easy to do. Testing has also gotten easier with this. Yes, browserify and traceur add some overhead to the mix, but it's still lighter than using the mega tooling stuff like jQuery. And don't get me wrong, I like jQuery a lot, and it's a really nice toolkit... but sometimes you only need a screwdriver, and an adjustable wrench for a job, not the whole huge craftsman toolbox.
Another issue is simply that the current angular would be unlikely to have a story around server-side rendering, and I think that's especially important for any next generation tools.
There's a lot to by critical about Angular... least of which is that it's own dependency system doesn't play well with others. The reliance of jquery is pretty heavy (since most wind up including the full version, and the light version is loaded). There's a lot of extra boilerplate that the new design will tear down.
With node's tooling in current JS development, package management and modularization have become really easy to do. Testing has also gotten easier with this. Yes, browserify and traceur add some overhead to the mix, but it's still lighter than using the mega tooling stuff like jQuery. And don't get me wrong, I like jQuery a lot, and it's a really nice toolkit... but sometimes you only need a screwdriver, and an adjustable wrench for a job, not the whole huge craftsman toolbox.
Another issue is simply that the current angular would be unlikely to have a story around server-side rendering, and I think that's especially important for any next generation tools.
> Angular was started 5 years ago..
quoted just to remind people that Angular as we know it is older than most other single-page app frameworks - even if it only became popular a year or two ago.
quoted just to remind people that Angular as we know it is older than most other single-page app frameworks - even if it only became popular a year or two ago.
Yeah I heard of Angular a long time ago, but then everyone started using it in the last year. What happened? Did they change something that all of the sudden made it popular?
It takes a while for concepts to actually catch on. .Net and C# for example (iirc) were started in late 1999, with .Net 1.0 released in 2001, 1.1 in 2002, but it wasn't until 2003 that people really started using it. I think Java got some use pretty quickly, because of some of its' niches. Node was a proof of concept in 2009, and only in the past two years is seeing some broader use.
I think it really comes down to more developers actually embracing JavaScript and the tools that the system offers. I think the JS renaissance is upon us, and that's what has people looking to Angular, Flux/React, Meteor and other new frameworks and tooling.
I think it really comes down to more developers actually embracing JavaScript and the tools that the system offers. I think the JS renaissance is upon us, and that's what has people looking to Angular, Flux/React, Meteor and other new frameworks and tooling.
Data binding, directives, MVC front end + the adoption of Node is what made it popular IMHO.
Cappuccino has been around since 2008 :) And although at this point it has not much in common, Ember is the direct ancestor of a project from the same time.
I agree. There is virtually no way you can smoothly upgrade an Angular 1 project to this. You'd have to redo most of it from scratch. There are a lot of huge projects that are built on Angular 1 -- many enterprise products too. And this is a huge blow to maintenance. It might be a reason for a lot of people dropping Angular and going for something that makes more business sense. Maybe it's React's time to shine.
The thing with React is that either Facebook's engineers are incredibly prescient or lucky. React very is really well designed and feels natural with ES6.
It's so incredibly designed, even without the ES6 optimizations of 0.12.0 (coming soon) you can code today in ES6 (I use 6to5 with JSX transformer harmony just in case).
It's so incredibly designed, even without the ES6 optimizations of 0.12.0 (coming soon) you can code today in ES6 (I use 6to5 with JSX transformer harmony just in case).
Yeah I am betting on React. I am not a Web GUI developer and learned about Angular and now React just out of curiosity. Well I tried to learn Angular and got stuck at the termology soup of "directives", "digest cycles", "factories", "services", "dipendencies", "scopes". I understand all those English words but I still don't quite have an idea of how they are helping me.
With React somehow the whole data flow and how components work and even JSX make a lot more sense.
With React somehow the whole data flow and how components work and even JSX make a lot more sense.
Facebook uses React in production (a lot) and has to migrate any code just like you would as a user of the library. Facebook is effectively always running React master.
Facebook also has members on TC39 and is quite involved with evolving the language.
Facebook also has members on TC39 and is quite involved with evolving the language.
It has been talked about for almost a year that Angular 2.0 is going to be bringing such breaking changes. 2.0 is going to require complete app rebuilds if you want to migrate to 2.0.
The good news is that if your code is clean, a migration shouldn't be too painful. The danger comes when you have unmodular code that sticks everything on $rootScope (for example).
The good news is that if your code is clean, a migration shouldn't be too painful. The danger comes when you have unmodular code that sticks everything on $rootScope (for example).
Except in a modular app, I should be able to upgrade module-x to Angular2 without having it break the entire app. With this change I have to re-write every module in my app.
We've been looking at React at work over the last week, and were considering moving some of our angular directives to react. Now there is a larger case for building a complete app in Flux.
We've been looking at React at work over the last week, and were considering moving some of our angular directives to react. Now there is a larger case for building a complete app in Flux.
I was at ng-europe last week and couldn't help thinking that the way Angular 2.0 was being talked about was rather reminiscent of the chat around Python 3 back in the day.
Angular 1.0 was released on Jun 13, 2012, and was built on the API developed much longer ago (and was compatible with it).
So this is the first massive API change in probable well over five years, with lots of technology changes happening around (most importantly ES6).
So this is the first massive API change in probable well over five years, with lots of technology changes happening around (most importantly ES6).
They have do it otherwise Angular will end up the elephants' graveyard like yui, dojo, extjs, javascriptmvc, cappuccino etc.
The problem is of course that this will lead to a big divide between 1.x and 2.x that eventually will undermine the entire project like what happened in python and Volapück.
The problem is of course that this will lead to a big divide between 1.x and 2.x that eventually will undermine the entire project like what happened in python and Volapück.
I am literally working on a new project, starting to code the front end as of a day ago... I using Flux+React (nearstack.io, plug) around the Yahoo implementation of Flux's model. The down side, is this will be how things are for the next 3-5 years for the life of the site/application.
Angular 2 looks really cool... they seem to be embracing the shadow-dom concepts (like polymer) as well as es6-style import directives and expansion. I still think I made the right decision, but this is really cool and looks to be something that can work really well on current/next-gen browsers, but maybe not so well on currently supported browsers such as limited support for IE8 in my case :-(
I've been saying for a while that React/Flux is probably the best solution today for web applications, and that something similar to Polymer would be the best option in 3-5 years. I'll be watching this with great anticipation as Angular 2 actually changes most of my complaints about the framework today, and is really something that will come to work well.
Though, I'm not sure if they have or plan on a server-side component to handling server rendering, which is a huge part of why I went with React+Flux.
-- adding to my post --
More Info: http://ng-learn.org/2014/03/AngularJS-2-Status-Preview/
Looks like they are indeed using Traceur as a migration path, and embracing many ES6 features. Not sure how they will go with Promises, or if they'll wind up going down the generator path. There's definately some interesting reading and watching for the next year or two on this. Also, really curious where Polymer is heading in the light of this as well.
Angular 2 looks really cool... they seem to be embracing the shadow-dom concepts (like polymer) as well as es6-style import directives and expansion. I still think I made the right decision, but this is really cool and looks to be something that can work really well on current/next-gen browsers, but maybe not so well on currently supported browsers such as limited support for IE8 in my case :-(
I've been saying for a while that React/Flux is probably the best solution today for web applications, and that something similar to Polymer would be the best option in 3-5 years. I'll be watching this with great anticipation as Angular 2 actually changes most of my complaints about the framework today, and is really something that will come to work well.
Though, I'm not sure if they have or plan on a server-side component to handling server rendering, which is a huge part of why I went with React+Flux.
-- adding to my post --
More Info: http://ng-learn.org/2014/03/AngularJS-2-Status-Preview/
Looks like they are indeed using Traceur as a migration path, and embracing many ES6 features. Not sure how they will go with Promises, or if they'll wind up going down the generator path. There's definately some interesting reading and watching for the next year or two on this. Also, really curious where Polymer is heading in the light of this as well.
FWIW, React will be in ES6 (with native classes and imports) before they tag 1.0. In fact, React 0.12 has some breaking changes to prepare for that transition.
Interesting... though not surprising... Honestly, I'm not a big fan of class hierarchy in JS. It tends to weight things down imho more than it helps. I'm generally in favor of decorating against object literals, which has some overhead, but less so than deep inheritance chains.
Angular 1 developers should see this as an opportunity to abandon Angular and move on to React.
React is by far and away the best the market has to offer right now. From my perspective client-side applications are a solved problem thanks to React.
React is by far and away the best the market has to offer right now. From my perspective client-side applications are a solved problem thanks to React.
Not to mention, it's much simpler than Angular. You can get upto speed with React in 2 or 3 days. Once you make the shift to specifying single states for your interactions and letting React rebuild the DOM on changes, you'll never go back to anything else.
> you'll never go back to anything else.
React completely changed the way I thought about rich clients. It took me a little longer than 2 days, I went into React with an absolute hatred of anything Javascript and came out 2 weeks later loving it. There is something to be said for a library that can wash away over 10 years of built up anger for a particular technology. It's not just another revamped library thrown into the frying pan, it's a complete rethink of how rich clients can be developed almost effortlessly with code that anyone can read. When I got into react, all I could think was "yes, this makes sense, this is how it should have been all along." Moving into the future I expect most libraries will unify under the concepts introduced by React in the same way that most web applications frameworks are different flavors of MVC.
React completely changed the way I thought about rich clients. It took me a little longer than 2 days, I went into React with an absolute hatred of anything Javascript and came out 2 weeks later loving it. There is something to be said for a library that can wash away over 10 years of built up anger for a particular technology. It's not just another revamped library thrown into the frying pan, it's a complete rethink of how rich clients can be developed almost effortlessly with code that anyone can read. When I got into react, all I could think was "yes, this makes sense, this is how it should have been all along." Moving into the future I expect most libraries will unify under the concepts introduced by React in the same way that most web applications frameworks are different flavors of MVC.
You are absolutely right. Which is why I'm so excited about Angular2. It's the first post-React client-side framework to come along. (as opposed to React which is more of a library than a framework, although it definitely pushes the boundaries of that...)
Technically you're right - it is post-React. But in order for it to really have learned from React I think we'd have to wait a little while longer, because the industry is still learning what React and Flux can really bring to the table. For me, one of those things is simplicity, and that's something that I feel Angular sorely lacks.
Given the choice between two solutions capable of helping you solve a problem, why would you ever choose a framework over a library? I would never choose a framework when a library suffices.
It's not really a post-React framework though, it has been designed at the same time as React was starting to take mind share so it's not clear if they have built something that responds to what React + Flux provide.
I disagree (about never going back) - I spent some time playing around with React (I authored https://github.com/wesleycho/angular-react ), and I found the lack of a framework for application development to be a massive void. Code organization and modularity is becoming an increasingly important problem with JS as more logic is happening in the client and more components need to be modular for fast changing requirements. Neither Angular or Flux quite solves this, but Angular provides more useful tools for managing an application.
Angular has a void with the lack of a useful enough eventing solution - $scope eventing has specific use cases, but you don't want to use it as a general event bus, mainly due to performance. This is important for Angular since you don't want to couple modules together with hardcoded state keys that you may want to alter in different applications.
Flux does offer a way around the eventing problem at a lower level within React components, but on a higher level, there is no application level of control - you have to construct exactly the control you want, which while liberating, also is an easy way to create a hole in architecture when designing an application if you're not careful. Angular exposes that problem directly in many ways (for example handling transitions between two urls in the application), as well as forces thinking about module dependencies with dependency injection.
HTML mixed in with JS via JSX is also an abomination, that originally made me want to run far away from React when I first looked at it. I'm not a huge fan of it still, but it's not an extremely terrible thing as long as you keep higher level templates slim, which React forces you to do in order not to have huge chunks of HTML mixed in with complex JS...although I'm sure there are developers out there who do it anyway (just like there are plenty of Angular developers who will toss plenty of jQuery in an Angular controller).
Angular has a void with the lack of a useful enough eventing solution - $scope eventing has specific use cases, but you don't want to use it as a general event bus, mainly due to performance. This is important for Angular since you don't want to couple modules together with hardcoded state keys that you may want to alter in different applications.
Flux does offer a way around the eventing problem at a lower level within React components, but on a higher level, there is no application level of control - you have to construct exactly the control you want, which while liberating, also is an easy way to create a hole in architecture when designing an application if you're not careful. Angular exposes that problem directly in many ways (for example handling transitions between two urls in the application), as well as forces thinking about module dependencies with dependency injection.
HTML mixed in with JS via JSX is also an abomination, that originally made me want to run far away from React when I first looked at it. I'm not a huge fan of it still, but it's not an extremely terrible thing as long as you keep higher level templates slim, which React forces you to do in order not to have huge chunks of HTML mixed in with complex JS...although I'm sure there are developers out there who do it anyway (just like there are plenty of Angular developers who will toss plenty of jQuery in an Angular controller).
> Angular has a void with the lack of a useful enough eventing solution - $scope eventing ...
I've found that using a publish/subscribe system for communicating between components makes them more loosely coupled and modular. In most cases, the components I've written are naturally somewhat slightly coupled so I just pass around functions as props from parent to child components.
> HTML mixed in with JS via JSX is also an abomination ...
Totally agree. I use the default React.DOM elements instead. I find them more transparent and easy to read, and manipulation of these are much easier using the map, filter, folds etc.
I've found that using a publish/subscribe system for communicating between components makes them more loosely coupled and modular. In most cases, the components I've written are naturally somewhat slightly coupled so I just pass around functions as props from parent to child components.
> HTML mixed in with JS via JSX is also an abomination ...
Totally agree. I use the default React.DOM elements instead. I find them more transparent and easy to read, and manipulation of these are much easier using the map, filter, folds etc.
> I've found that using a publish/subscribe system for communicating between components makes them more loosely coupled and modular. In most cases, the components I've written are naturally somewhat slightly coupled so I just pass around functions as props from parent to child components.
I agree - my company is going to open source an event machine for Angular sometime in the next couple of months which should address this hole.
> Totally agree. I use the default React.DOM elements instead. I find them more transparent and easy to read, and manipulation of these are much easier using the map, filter, folds etc.
Unfortunately it doesn't seem like React documented React.DOM :( . I would rather just use HTML, but I would rather have it in a separate file. Perhaps a build tool for grunt/gulp where you can register keys with the path to the template being the value, and the tool converts the value into the React.DOM elements would be a good idea.
I agree - my company is going to open source an event machine for Angular sometime in the next couple of months which should address this hole.
> Totally agree. I use the default React.DOM elements instead. I find them more transparent and easy to read, and manipulation of these are much easier using the map, filter, folds etc.
Unfortunately it doesn't seem like React documented React.DOM :( . I would rather just use HTML, but I would rather have it in a separate file. Perhaps a build tool for grunt/gulp where you can register keys with the path to the template being the value, and the tool converts the value into the React.DOM elements would be a good idea.
> Unfortunately it doesn't seem like React documented React.DOM :(
React.DOM.div(), etc. are part of React's public API -- if we didn't document them, that's a mistake.
React.DOM.div(), etc. are part of React's public API -- if we didn't document them, that's a mistake.
At the least, I cannot find any mention of the specifics anywhere on the main GitHub page - this is the best that I can tell: http://facebook.github.io/react/docs/top-level-api.html#reac... . I do know the recommendation is to use JSX, and I can see why, but more visibility of the API would be better.
Edit: As a note, I did find out how it worked by doing source code diving two months ago.
Edit: As a note, I did find out how it worked by doing source code diving two months ago.
I think there's a page or two that describes what the jsx transformer does(which is it converts them to React.DOM elements IIRC). I think that's where I learnt that you could use raw JS functions instead of jsx, even though it said that jsx should be preferred or something to that effect.
"HTML mixed in with JS via JSX is also an abomination"
Why?
Why?
> HTML mixed in with JS via JSX is also an abomination,
Ha! It made sense to me. It was very easy to explain its purpose and it is entirely optional.
Ha! It made sense to me. It was very easy to explain its purpose and it is entirely optional.
You can reinvent Angular concepts in ReactJS using RxJS. If you do that, the code to do so is very small and is much more logical that AngularJS nonsense.
100x that.
Never got beyond all the directives, digests, factories, services, scopes, dependency injentions, all the ng-* tags and so on. That is a lot of terminology for something that is supposed to make developing web appliclations easy.
Granted I am not a Web UI developer was just curious what everything was excited about.
Maybe all this complexity just makes sense to someone who already did all the more complex stuff wiht jQuery? Not sure.
Anyway React made sense to me. The whole data flow ideas, minizing mutable state and inter-dependencies between components, VDOM and even JSX.
So I like React a lot better.
Never got beyond all the directives, digests, factories, services, scopes, dependency injentions, all the ng-* tags and so on. That is a lot of terminology for something that is supposed to make developing web appliclations easy.
Granted I am not a Web UI developer was just curious what everything was excited about.
Maybe all this complexity just makes sense to someone who already did all the more complex stuff wiht jQuery? Not sure.
Anyway React made sense to me. The whole data flow ideas, minizing mutable state and inter-dependencies between components, VDOM and even JSX.
So I like React a lot better.
Can you elaborate on 'specifying single states for your interactions and letting React rebuild the DOM'...
- this feels like it is a key conceptual difference but I'm not clear on what this means.
- this feels like it is a key conceptual difference but I'm not clear on what this means.
Actually, I see it as the opposite.
It's really not that huge of a jump from Angular 1.0 to Angular 2.0. Small example:
<button ng-click="addTodo()">+</button>
becomes
<button (click)="addTodo()">+</button>
and
<div ng-controller="SantaTodoController">
literally becomes
<div>
Getting the advantage of 1 framework that's batteries included + universal (i.e. taught in CodeSchool, Tuts+, etc.) vs. an eclectic selection of libraries all over the place, gives Angular an advantage IMO.
It's really not that huge of a jump from Angular 1.0 to Angular 2.0. Small example:
<button ng-click="addTodo()">+</button>
becomes
<button (click)="addTodo()">+</button>
and
<div ng-controller="SantaTodoController">
literally becomes
<div>
Getting the advantage of 1 framework that's batteries included + universal (i.e. taught in CodeSchool, Tuts+, etc.) vs. an eclectic selection of libraries all over the place, gives Angular an advantage IMO.
Angular 2 steals the best ideas from React and Meteor and everything else that has come along in the 5 years since Angular 1 came along, and puts them together in a really nice fashion. IMO, definitely the best of breed for the time being. A few months later, something new and shinier will come along.
Really the choice comes down to whether you're a "single big framework" or "lots of little libraries" type of guy. The former should go with Angular2, the latter with React, IMO.
Really the choice comes down to whether you're a "single big framework" or "lots of little libraries" type of guy. The former should go with Angular2, the latter with React, IMO.
I have zero knowledge of Angular, just skimmed through the presentation but didn't find it very similar to React. What ideas does it steal? Specifically, does it internally do diffing thing as React?
The consensus seems to be that Angular 2 won't really be ready for use until a year or two from now. I'm sticking to Flux + React for now, but looking forward to seeing Angular 2 mature. I'm hoping they gain the same client-server (shared code) capabilities that React offers.
> From my perspective client-side applications are a solved problem thanks to React.
React is very cool, no doubt, and I use it in my own app, but let's not get ahead of ourselves. React is far from perfect:
- the Virtual DOM is a leaky abstraction: you sometimes need to get your hands on a real DOM node: http://facebook.github.io/react/docs/working-with-the-browse...
- if you're updating the virtual DOM from anywhere other than React's event loop (for example from a setTimeout() or XHR callback), batching doesn't happen properly which can lead to inefficiency. Needing to be aware of what runs inside a React event loop vs. what doesn't can add application complexity. More info: https://groups.google.com/forum/#!topic/reactjs/LkTihnf6Ey8
- writing manual event handlers is a somewhat more manual and less expressive than some of the two-way data binding approaches like Knockout.js or Angular.js.
React is very cool, no doubt, and I use it in my own app, but let's not get ahead of ourselves. React is far from perfect:
- the Virtual DOM is a leaky abstraction: you sometimes need to get your hands on a real DOM node: http://facebook.github.io/react/docs/working-with-the-browse...
- if you're updating the virtual DOM from anywhere other than React's event loop (for example from a setTimeout() or XHR callback), batching doesn't happen properly which can lead to inefficiency. Needing to be aware of what runs inside a React event loop vs. what doesn't can add application complexity. More info: https://groups.google.com/forum/#!topic/reactjs/LkTihnf6Ey8
- writing manual event handlers is a somewhat more manual and less expressive than some of the two-way data binding approaches like Knockout.js or Angular.js.
Not sure what in react would replace all the other angularjs part not related to directives. How does react deal with routing, web service querying, unit testing, etc...
It seems to me that the integrated approach of angular isn't answered by react.
It seems to me that the integrated approach of angular isn't answered by react.
See: Flux .. I'm partial to the Yahoo implementation myself, which has a really good client-server story behind it. React would be the "View" system in the Flux workflow.
You are correct that React alone won't replace Angular, but with other tools (Ampersand, Flux, etc) you can use the pieces that you want and put them together. It's the difference between a library and a framework.
You are correct that React alone won't replace Angular, but with other tools (Ampersand, Flux, etc) you can use the pieces that you want and put them together. It's the difference between a library and a framework.
Just looked at the flux presentation from facebook, and it seems to me that it's basically a set of best practice on how to wire your view actions to your controller's model and refresh. Having a single unidirectionnal "loop" model=>view=>action=>model... is something that i have been doing inside my angular controllers for a while...
Now react may help with the performances of refreshing the dom in that scenario, but so far i didn't encounter that issue myself.
Now react may help with the performances of refreshing the dom in that scenario, but so far i didn't encounter that issue myself.
I think the performance issues tend to come when you have a lot of controls and associated bindings via angular on a page. The use of jQuery (improperly) tends to exacerbate the issue. Most people won't come across the issue, to be honest. Facebook has a lot of points of display and interaction on their pages, so it quickly becomes an issue. Not to mention the simpler flow is easier to track.
I do find that the flux model makes more sense to me. Flux is a set of best practices, they use React for the rendering/view portion, and since their talks there have been several implementations of the workflow. Some using Ampersand or Backbone, others implementing their own pieces. Now Facebook has been releasing their own implementation...
It's all pretty interesting.
I do find that the flux model makes more sense to me. Flux is a set of best practices, they use React for the rendering/view portion, and since their talks there have been several implementations of the workflow. Some using Ampersand or Backbone, others implementing their own pieces. Now Facebook has been releasing their own implementation...
It's all pretty interesting.
ReactJS just focuses on creating DOM nodes, routing etc are up to you. This is a good thing! Because then you can choose whatever other frameworks you want for routing, rest, etc.
AngularJS does too much, and nearly all of that too much poorly.
AngularJS does too much, and nearly all of that too much poorly.
There are tons of javascript libraries that are out there that offer the things you want. In most cases, they are more featureful and more stable than Angular's implementations.
Router - Backbone's router, page.js etc
Web service querying - simple jquery ajax calls or you could use breeze.js, pouchdb etc
Unit testing - React has one built in, but you could use others too.
Router - Backbone's router, page.js etc
Web service querying - simple jquery ajax calls or you could use breeze.js, pouchdb etc
Unit testing - React has one built in, but you could use others too.
> There are tons of javascript libraries that are out there
And there you have your answer :)
What the JS people don't seem to grasp is that I don't care how many libraries are out there. I care even less about the incompatibilities and the different release cycles of all those libraries. By now, I hope you understand that my interest in maintaining and integrating all those into a coherent system approaches zero.
I am a software engineer and not a JS technologist. The front-end is just 1-10% of any serious system and yet, in the JS world, it takes 90% of the time building it and maintaining it. It just doesn't add up.
Imagine 10-15 years ago if we had to build GUI apps by mixing and matching 100 incoherent libraries, that in 1-5 months some of them will be obsolete, abandoned or whatnot. This is what JS has accomplished today and people just take it for granted.
Now I am sad and I will return to my crying corner.
And there you have your answer :)
What the JS people don't seem to grasp is that I don't care how many libraries are out there. I care even less about the incompatibilities and the different release cycles of all those libraries. By now, I hope you understand that my interest in maintaining and integrating all those into a coherent system approaches zero.
I am a software engineer and not a JS technologist. The front-end is just 1-10% of any serious system and yet, in the JS world, it takes 90% of the time building it and maintaining it. It just doesn't add up.
Imagine 10-15 years ago if we had to build GUI apps by mixing and matching 100 incoherent libraries, that in 1-5 months some of them will be obsolete, abandoned or whatnot. This is what JS has accomplished today and people just take it for granted.
Now I am sad and I will return to my crying corner.
Engineering is taking all the bits and pieces out there and choosing the right ones for the problem you're trying to solve with engineering. It's not just choosing those components, but doing all the work to figure out how they should work together to solve your problem and building the pieces that bring them all together.
Using something that does all that for you is tantamount to outsourcing all the engineering work to the makers of that thing.
If you're given and entire system and just have to put the pieces together according to what the client needs, then you're basically a plumber.
Now there is nothing wrong with that, it makes good business sense, which is the justification you provide, but its not really engineering. Or if it is, it's only a small subset of the problems engineering solves.
Do you think the builders of the Golden Gate Bridge, the Hoover Dam or the Space Shuttle didn't have to think about all the bits and pieces they would need source and bring together into one coherent whole? That's engineering.
Using something that does all that for you is tantamount to outsourcing all the engineering work to the makers of that thing.
If you're given and entire system and just have to put the pieces together according to what the client needs, then you're basically a plumber.
Now there is nothing wrong with that, it makes good business sense, which is the justification you provide, but its not really engineering. Or if it is, it's only a small subset of the problems engineering solves.
Do you think the builders of the Golden Gate Bridge, the Hoover Dam or the Space Shuttle didn't have to think about all the bits and pieces they would need source and bring together into one coherent whole? That's engineering.
You are in a different conversation.
Unless you're trying to tell me that people who build e.g. KDE with the Qt framework are plumbers and people who develop with Backbone.js are engineers. In which case I wouldn't want to engage in such a discussion.
Unless you're trying to tell me that people who build e.g. KDE with the Qt framework are plumbers and people who develop with Backbone.js are engineers. In which case I wouldn't want to engage in such a discussion.
Nice strawman.
Neither Angular nor React nor Backbone are equivalent to KDE or Qt, so those are false equivalencies use to construct a poor excuse for a strawman.
The user agents (browsers) and the web as a platform is the closest equivalent to Qt, since collectively, they abstract away all the differences between platforms as Qt does. Collectively and individually they represent excellent examples of engineering. The problem with them is that the problem they are trying to solve basically changed from what Tim Berners-Lee originally tried to solved. He tried to make a hyperlinked document platform, not an app platform. The web is now trying to evolve to supporting apps while also remaining a good documentation platform.
React would be most closely equivalent to added the paint/draw and retain-mode graphics part of Qt to the web. Flux and its different implementations and the various libraries out are likely equivalent to different solutions for events and data stores available in the Qt ecosystem, but I'm not a Qt developer so I wouldn't know. Those who built react are doing engineering as are those who build with react, it's just that the latter are absolved from solving the engineering problems related to render/paint/layout and retain-mode graphics.
Angular is an attempt to bundle everything together (render/draw, events, data) into one monolithic framework solution, doing reasonably well, but none exceptionally well. Those who built angular are doing engineering. However, those who build with angular are basically doing plumbing.
People who build with KDE and people who build with angular are basically performing the same type of work.
I don't know what backbone is equivalent to in the KDE or Qt world, but I would imagine it's probably some early library/quasi-framework in the Qt world when it was still the wild west and there weren't very good engineering practices and project organization strategies in Qt projects.
I can't believe I wasted my time responding to your logical fallacy.
Neither Angular nor React nor Backbone are equivalent to KDE or Qt, so those are false equivalencies use to construct a poor excuse for a strawman.
The user agents (browsers) and the web as a platform is the closest equivalent to Qt, since collectively, they abstract away all the differences between platforms as Qt does. Collectively and individually they represent excellent examples of engineering. The problem with them is that the problem they are trying to solve basically changed from what Tim Berners-Lee originally tried to solved. He tried to make a hyperlinked document platform, not an app platform. The web is now trying to evolve to supporting apps while also remaining a good documentation platform.
React would be most closely equivalent to added the paint/draw and retain-mode graphics part of Qt to the web. Flux and its different implementations and the various libraries out are likely equivalent to different solutions for events and data stores available in the Qt ecosystem, but I'm not a Qt developer so I wouldn't know. Those who built react are doing engineering as are those who build with react, it's just that the latter are absolved from solving the engineering problems related to render/paint/layout and retain-mode graphics.
Angular is an attempt to bundle everything together (render/draw, events, data) into one monolithic framework solution, doing reasonably well, but none exceptionally well. Those who built angular are doing engineering. However, those who build with angular are basically doing plumbing.
People who build with KDE and people who build with angular are basically performing the same type of work.
I don't know what backbone is equivalent to in the KDE or Qt world, but I would imagine it's probably some early library/quasi-framework in the Qt world when it was still the wild west and there weren't very good engineering practices and project organization strategies in Qt projects.
I can't believe I wasted my time responding to your logical fallacy.
Take a deep breath and relax.
First of all I stupidly thought that the part about KDE/GTK which is in this comment of mine https://news.ycombinator.com/item?id=8508094, was included in the comment to which you replied. So my bad and -1 for me.
What I meant is I don't think that anyone sees Qt or GTK as monolithic systems and they are about 1000 times more complex than any JS library you could name, as they solve a myriad problems to which JS is oblivious and wouldn't be able to solve anyway.
Contrast that with the web situation today, where they can't even decide which is the view, which the controller or "hey, maybe these don't map very well on the web side of things". Yes I agree about Tim Berners-Lee and the http stuff. But at some point things have to converge into something coherent, because the problem we have to solve is quite elementary, compared to other technologies.
Also if you honestly believe that people who developed KDE and people who develop with AngularJS are performing the same type of work... it just betrays the fact that you're just a JS programmer and haven't seen some real engineering work.
Javascript touches the tip of the iceberg with regards to technical challenge and Software Engineering, so please... just take a breath :)
First of all I stupidly thought that the part about KDE/GTK which is in this comment of mine https://news.ycombinator.com/item?id=8508094, was included in the comment to which you replied. So my bad and -1 for me.
What I meant is I don't think that anyone sees Qt or GTK as monolithic systems and they are about 1000 times more complex than any JS library you could name, as they solve a myriad problems to which JS is oblivious and wouldn't be able to solve anyway.
Contrast that with the web situation today, where they can't even decide which is the view, which the controller or "hey, maybe these don't map very well on the web side of things". Yes I agree about Tim Berners-Lee and the http stuff. But at some point things have to converge into something coherent, because the problem we have to solve is quite elementary, compared to other technologies.
Also if you honestly believe that people who developed KDE and people who develop with AngularJS are performing the same type of work... it just betrays the fact that you're just a JS programmer and haven't seen some real engineering work.
Javascript touches the tip of the iceberg with regards to technical challenge and Software Engineering, so please... just take a breath :)
> The front-end is just 1-10% of any serious system and yet, in the JS world, it takes 90% of the time building it and maintaining it. It just doesn't add up.
Wow, I want you to come work for me for a week. The front end is what interfaces with the user - your client - the one whom is paying money. You may hate JS, but it is the tool that we use to build interaction.
Wow, I want you to come work for me for a week. The front end is what interfaces with the user - your client - the one whom is paying money. You may hate JS, but it is the tool that we use to build interaction.
You misunderstood or I didn't express myself correctly.
I don't want to underplay the importance of the front-end, or in general the interfaces and what that means for bringing value to a product.
But however you spin it it's not the core technology. You could make the same point you made, by saying the same about the marketing/sales department. Yes, it's how you bring customers and without it you'll probably fail to reach a large audience. But again, it's not the core of your product.
Also keep in mind that mobile platforms(which are quickly becoming much more important than the web) also have a user interface. Take a guess at which of the 2(web/mobiles) are more costly to develop and maintain. The web, by far. That can't happen for much longer, that's all that I'm saying.
I don't want to underplay the importance of the front-end, or in general the interfaces and what that means for bringing value to a product.
But however you spin it it's not the core technology. You could make the same point you made, by saying the same about the marketing/sales department. Yes, it's how you bring customers and without it you'll probably fail to reach a large audience. But again, it's not the core of your product.
Also keep in mind that mobile platforms(which are quickly becoming much more important than the web) also have a user interface. Take a guess at which of the 2(web/mobiles) are more costly to develop and maintain. The web, by far. That can't happen for much longer, that's all that I'm saying.
That depends very much on what type of product you're building. I work on two "serious" enterprise products using Angular, and for one of them the "core technology" is evenly split between the Java backend and the Angular application, while for the other the Angular application is clearly the "core technology."
Indeed. I work in a similar kind of product. I was talking about the
majority of cases though. There are even cases where the mobile app is
the core and only technology.
Now what would be interesting questions though are: 1) How many people work in the backend and how many work in each of the respective front-ends.
2) Suppose that you had 2 front-end interfaces, angular(for the web) and an android app(it could be an iPhone app, it doesn't matter). How many backend devs would need to know or actively interact with the angular front-end and how many would need to interact with the android app.
In my case, none of the backend people(a lot) need to interact with the mobile codebase(2-people team for every mobile type), while all of us need to help or interact with the web front-end.
I see similar scenarios with most of the companies I interact or know about. The mobile team is almost always autonomous and can accomplish a lot with just a few people. While hords of people are thrown into the web frontend, even if it's not their primary specialty. Hence the need for fullstack developers. Why? Because the JS ecosystem sucks and we still don't have a real integrated solution. I hope that this will change, preferably before I retire.
Now what would be interesting questions though are: 1) How many people work in the backend and how many work in each of the respective front-ends.
2) Suppose that you had 2 front-end interfaces, angular(for the web) and an android app(it could be an iPhone app, it doesn't matter). How many backend devs would need to know or actively interact with the angular front-end and how many would need to interact with the android app.
In my case, none of the backend people(a lot) need to interact with the mobile codebase(2-people team for every mobile type), while all of us need to help or interact with the web front-end.
I see similar scenarios with most of the companies I interact or know about. The mobile team is almost always autonomous and can accomplish a lot with just a few people. While hords of people are thrown into the web frontend, even if it's not their primary specialty. Hence the need for fullstack developers. Why? Because the JS ecosystem sucks and we still don't have a real integrated solution. I hope that this will change, preferably before I retire.
Stop trying to shoehorn your backend into your web frontend, and treat the web frontend like the mobile one. That means, one single HTTP API to access the backend for both. I bet you already have this for your mobile app.
More often than not, the web frontend ends up being client side HTML/JS and some sort of intermediate middle-end server that hosts that HTML/JS. That way it turns into a fullstack app that does some processing on the middle-end to pass it on to the front-end JS.
You can make the frontend 100% static HTML/JS (and serveable off any static file CDN), so all you have to worry about is the API between them.
More often than not, the web frontend ends up being client side HTML/JS and some sort of intermediate middle-end server that hosts that HTML/JS. That way it turns into a fullstack app that does some processing on the middle-end to pass it on to the front-end JS.
You can make the frontend 100% static HTML/JS (and serveable off any static file CDN), so all you have to worry about is the API between them.
If you're using something like Angular, Ember or React, it's safe to assume that you'll be building a Single Page Application with the majority of code in Javascript. So evaluating libraries for stability, functionality etc is time well-spent, not wasted.
While it is true that there are far too many frameworks that come and go in JS land, you can find very stable, well-maintained and clean libraries too. For anything that's essential to your stack(DOM interaction, routing, UI elements etc), typically you'll find multiple well tested and stable libraries. Atleast, that has been my experience.
With well designed libraries, integration is rarely a problem. They are designed to be interoperable and don't make too many assumptions about things they aren't good at.
It takes a little bit of work upfront, but I find it's far better than relying on monolithic frameworks that tries to do everything under the sun(and usually fail).
Switch to React, I guarantee you that your front-end dev time(and overall) dev time will drop drastically to 20% :)
While it is true that there are far too many frameworks that come and go in JS land, you can find very stable, well-maintained and clean libraries too. For anything that's essential to your stack(DOM interaction, routing, UI elements etc), typically you'll find multiple well tested and stable libraries. Atleast, that has been my experience.
With well designed libraries, integration is rarely a problem. They are designed to be interoperable and don't make too many assumptions about things they aren't good at.
It takes a little bit of work upfront, but I find it's far better than relying on monolithic frameworks that tries to do everything under the sun(and usually fail).
Switch to React, I guarantee you that your front-end dev time(and overall) dev time will drop drastically to 20% :)
I had invested time in Angular. I don't think it was wasted time. If nothing else,
it made me hate the JS world about 1% less.
For every well maintained JS "technology" there are 100 others that aren't and they occupy the same playground. Evaluating them takes more time than one might think and at the end of the day, what you choose carries a huge risk. Yes this also happens in other aspects/technologies, but with JS stuff the risk is almost always higher.
A word about monolithic systems; You give too much credit on what a JS framework does. It's just one job. Do you ascribe the same term to GTK or Qt for example?
To be honest, React seems decent. I don't necessarily disagree with you, you just touched... a nerve of mine :)
If I ever have to evaluate JS frameworks again, React will have its turn then.
Cheers
For every well maintained JS "technology" there are 100 others that aren't and they occupy the same playground. Evaluating them takes more time than one might think and at the end of the day, what you choose carries a huge risk. Yes this also happens in other aspects/technologies, but with JS stuff the risk is almost always higher.
A word about monolithic systems; You give too much credit on what a JS framework does. It's just one job. Do you ascribe the same term to GTK or Qt for example?
To be honest, React seems decent. I don't necessarily disagree with you, you just touched... a nerve of mine :)
If I ever have to evaluate JS frameworks again, React will have its turn then.
Cheers
Having tons of libraries and multiple alternatives with unclear criteria for choosing A over B - that's a problem, not an advantage.
It creates unneeded wasted work in evaluating and comparing the alternatives; it makes maintenance harder and slower as people moving between projects have to get used to different components and styles every time, etc. Opinionated frameworks have a valid engineering reason for being and staying opinionated.
It creates unneeded wasted work in evaluating and comparing the alternatives; it makes maintenance harder and slower as people moving between projects have to get used to different components and styles every time, etc. Opinionated frameworks have a valid engineering reason for being and staying opinionated.
I remember when I looked into React that I was basically writing HTML templates into javascript code. Are there ways around doing that now with React? Because I find that to be a pretty big affront to separation of concerns
Having used React for a year now, I have long concluded that React doesn't violate any separation of concerns at all.
React implements UI views and controllers. You write views that know how to render themselves, and then you write views that control them; the latter type of view fulfills the role of the classical MVC controller.
For example, consider how Cocoa works. It's a classical MVC framework: You have a view controller, which mediates between data and views. The controller doesn't know how to render anything, but it listens to data modifications, and sends update commands to the views; it also listens to changes to views and propagates those changes to the data model. (You can also let Cocoa Bindings do it for you, for the most part.)
In a single app, you typically end up with many such controllers, typically one per window, and controllers can reference each other to facilitate communication; also, there are often controllers that individually control just a single view, because it's easier to encapsulate reusable components that way. For example, if you need a text field that autocompletes, you could subclass NSTextField and build this special behaviour into the view itself, but it's cleaner to create a controller that can bind to any normal NSTextView.
In React, you have the same distribution of controllers (some handling big, multi-view layouts, some targeting discrete views), but the controller actually takes part in the view hierarchy: A controller has views as its children. It may not even use DOM elements, but consist entirely of custom view components. And it does exactly the same stuff as a controller would. For example, it may contain this:
This is very much like building out a form in Interface Builder and connecting the actual controls to variables using IBOutlets. In fact, I would argue that there is hardly any distinction at all. The difference is that the UI is declared in the controller. And why not? Interface Builder is separate, and keeps its view data stored separately, because a WYSIWYG editor can't touch code. (Actually, Delphi showed that it was possible, but that's another story.)
The fact that there is a separation isn't actually useful to anyone. You generally cannot edit the view layout without breaking code, and you can't edit the code without breaking the view: They have to be maintained completely in sync with each other. So you might as well just keep the view layout in the same file as the controller. Which is what React does.
React implements UI views and controllers. You write views that know how to render themselves, and then you write views that control them; the latter type of view fulfills the role of the classical MVC controller.
For example, consider how Cocoa works. It's a classical MVC framework: You have a view controller, which mediates between data and views. The controller doesn't know how to render anything, but it listens to data modifications, and sends update commands to the views; it also listens to changes to views and propagates those changes to the data model. (You can also let Cocoa Bindings do it for you, for the most part.)
In a single app, you typically end up with many such controllers, typically one per window, and controllers can reference each other to facilitate communication; also, there are often controllers that individually control just a single view, because it's easier to encapsulate reusable components that way. For example, if you need a text field that autocompletes, you could subclass NSTextField and build this special behaviour into the view itself, but it's cleaner to create a controller that can bind to any normal NSTextView.
In React, you have the same distribution of controllers (some handling big, multi-view layouts, some targeting discrete views), but the controller actually takes part in the view hierarchy: A controller has views as its children. It may not even use DOM elements, but consist entirely of custom view components. And it does exactly the same stuff as a controller would. For example, it may contain this:
<Form>
<TextField label='Name' minLength={3} ref='nameField'
value={this.state.name}/>
<NumericField label='Age' min={0} ref='ageField'
value={this.state.value}>
</Form>
This is very much like building out a form in Interface Builder and connecting the actual controls to variables using IBOutlets. In fact, I would argue that there is hardly any distinction at all. The difference is that the UI is declared in the controller. And why not? Interface Builder is separate, and keeps its view data stored separately, because a WYSIWYG editor can't touch code. (Actually, Delphi showed that it was possible, but that's another story.)
The fact that there is a separation isn't actually useful to anyone. You generally cannot edit the view layout without breaking code, and you can't edit the code without breaking the view: They have to be maintained completely in sync with each other. So you might as well just keep the view layout in the same file as the controller. Which is what React does.
>The fact that there is a separation isn't actually useful to anyone. You generally cannot edit the view layout without breaking code, and you can't edit the code without breaking the view: They have to be maintained completely in sync with each other
As someone working on a team that practices a good amount of separation of concerns, this is patently false. This is more dependent on how good your template language is than anything, but this separation helps to assure that we're not introducing new bugs or the like.
The main arguments for React along what you're saying is that people seem to abuse the "view model" concept. It's rarely as necessary as people seem to want to make it (though again, dependent on template language).
As someone working on a team that practices a good amount of separation of concerns, this is patently false. This is more dependent on how good your template language is than anything, but this separation helps to assure that we're not introducing new bugs or the like.
The main arguments for React along what you're saying is that people seem to abuse the "view model" concept. It's rarely as necessary as people seem to want to make it (though again, dependent on template language).
The fact that you're able to do it doesn't mean it's a good idea. On the contrary, I believe it's a bad idea.
It has nothing to do with how good your template language is. It's simply that a controller's main controller (not talking about partials here) has an implicit dependency on the controller, and the controller has a dependency on the template. Unlike, say, data models, the relationship is not unidirectional.
But really, what is this separation for? What does it gain us? We generally separate stuff out into declarations and files because it gains us modularity ("separation of concerns") and reusability. Data models are constantly reused, for example, as are views. But that one template belonging exclusively to the controller isn't reusable. It's separated out for no particular reason other than the fact that, historically, it has been expressed in a different language and must be parsed and "compiled" separately, so it has not been about "concerns" but about implementation details.
React removes that step, and because the template is unequivocally tied to the controller, there is nothing gained by separating them. The point of React is that the "template" is the component. The component's rendering is intimately tied to how its internal state and data model is wired up because the one half wouldn't work without the other, and vice versa.
(As an aside, in a well-designed, pure component, there is little state and the component is mostly template, anyway.)
(As an aside, most template languages don't even let you validate a template's inputs — that is, declaring that it requires specific named inputs and what their types/structure are. No idea why, seems pretty obvious defensive functionality to me. But React does this.)
It has nothing to do with how good your template language is. It's simply that a controller's main controller (not talking about partials here) has an implicit dependency on the controller, and the controller has a dependency on the template. Unlike, say, data models, the relationship is not unidirectional.
But really, what is this separation for? What does it gain us? We generally separate stuff out into declarations and files because it gains us modularity ("separation of concerns") and reusability. Data models are constantly reused, for example, as are views. But that one template belonging exclusively to the controller isn't reusable. It's separated out for no particular reason other than the fact that, historically, it has been expressed in a different language and must be parsed and "compiled" separately, so it has not been about "concerns" but about implementation details.
React removes that step, and because the template is unequivocally tied to the controller, there is nothing gained by separating them. The point of React is that the "template" is the component. The component's rendering is intimately tied to how its internal state and data model is wired up because the one half wouldn't work without the other, and vice versa.
(As an aside, in a well-designed, pure component, there is little state and the component is mostly template, anyway.)
(As an aside, most template languages don't even let you validate a template's inputs — that is, declaring that it requires specific named inputs and what their types/structure are. No idea why, seems pretty obvious defensive functionality to me. But React does this.)
> Interface Builder is separate, and keeps its view data stored separately, because a WYSIWYG editor can't touch code. (Actually, Delphi showed that it was possible, but that's another story.)
Oooh, do tell!
Oooh, do tell!
Delphi automatically synchronized itself with your code. They called this "two-way editing" and it was magical, and worked wonderfully.
Let's say you created a form, which in Delphi parlance was a surface that could inhabit controls, typically an actual application window. You would get this empty window:
http://www.vwlowen.co.uk/basicdelphi/images/theide.jpg
You would also automatically get a source file containing the class definition for that form, roughly corresponding to a window controller class in Cococa. This class would be completely empty, mind; no init code needed or anything:
http://136513.jakero00.web.hosting-test.net/wp-content/uploa...
(The GUI layout would live in a separate binary "form file" you never needed to edit directly. This file contained serialized objects that you could read and write in code, similar to OS X bundles, except more easily extensible.)
This class would be, by virtue of having the same base file name, automatically linked up with the corresponding form, so you could quickly switch between code and UI.
Then if you added a button the form, Delphi would automatically add a private member variable declaration "FButton1: TButton" to your class definition, as glimpsed here:
http://www.delphisources.ru/pages/faq/master-delphi-7/conten...
The framework would know, from the GUI definition, that FButton1 was that button. You could edit it and move it around in your code, and it would still be bound correctly.
Same thing with event handlers: If you went into the button's inspector and double-clicked on the "click" handler, it created the method for you, and placed the cursor in the right place so you could immediately fill it out with code.
This system made developers insanely productive, because the "boilerplate interactions" were reduced to almost nothing, and all the work was actual work. No "IBOutlet" stuff needed, no manually connecting the variable to the right thing in the GUI builder, and very little setup.
A few more brilliant, deceptively minor details made this even more magical. First, the form you edited was truly "live". Delphi actually rendered real controls in the editor. If you created a control that did custom rendering, it would render like that in the GUI editor, live. Interface Builder sort of does this, but not quite, and custom controls are a pain and apparently no longer supported.
The second thing was the object inspector:
https://www.ibm.com/developerworks/data/library/techarticle/...
Interface Builder has a very poor one; Delphi's felt natural. Every property exposed by a control would be visible there through reflection: Delphi would actually parse properties out of your code. It supported structured properties, so if something was a TFont, it expanded into sub-properties for font name, font size and so on.
If you created a new class TGradientButton or something, and exposed two properties FromColor and ToColor, they would show up in the object inspector, automatically, and since these properties would be something like TColor, it would know to display an RGB widget for them.
You could also register custom object inspector behaviour, so that, instead of FromColor/ToColor, perhaps there was only one property "Gradient" of type TGradient. Your custom object inspector thingy could then render a gradient editor for that property.
XCode + Interface Builder is about 10% of what Delphi was. I say "was", it still exists, but I haven't touched it since around 2000-2001. It's insane that Delphi 1.0 in 1995 was more powerful than XCode + Interface Builder today.
(I suppose it lives on in the Visual.NET tools; after creating Delphi, Anders Hejlsberg joined Microsoft and created C#. But I haven't used any of it.)
Let's say you created a form, which in Delphi parlance was a surface that could inhabit controls, typically an actual application window. You would get this empty window:
http://www.vwlowen.co.uk/basicdelphi/images/theide.jpg
You would also automatically get a source file containing the class definition for that form, roughly corresponding to a window controller class in Cococa. This class would be completely empty, mind; no init code needed or anything:
http://136513.jakero00.web.hosting-test.net/wp-content/uploa...
(The GUI layout would live in a separate binary "form file" you never needed to edit directly. This file contained serialized objects that you could read and write in code, similar to OS X bundles, except more easily extensible.)
This class would be, by virtue of having the same base file name, automatically linked up with the corresponding form, so you could quickly switch between code and UI.
Then if you added a button the form, Delphi would automatically add a private member variable declaration "FButton1: TButton" to your class definition, as glimpsed here:
http://www.delphisources.ru/pages/faq/master-delphi-7/conten...
The framework would know, from the GUI definition, that FButton1 was that button. You could edit it and move it around in your code, and it would still be bound correctly.
Same thing with event handlers: If you went into the button's inspector and double-clicked on the "click" handler, it created the method for you, and placed the cursor in the right place so you could immediately fill it out with code.
This system made developers insanely productive, because the "boilerplate interactions" were reduced to almost nothing, and all the work was actual work. No "IBOutlet" stuff needed, no manually connecting the variable to the right thing in the GUI builder, and very little setup.
A few more brilliant, deceptively minor details made this even more magical. First, the form you edited was truly "live". Delphi actually rendered real controls in the editor. If you created a control that did custom rendering, it would render like that in the GUI editor, live. Interface Builder sort of does this, but not quite, and custom controls are a pain and apparently no longer supported.
The second thing was the object inspector:
https://www.ibm.com/developerworks/data/library/techarticle/...
Interface Builder has a very poor one; Delphi's felt natural. Every property exposed by a control would be visible there through reflection: Delphi would actually parse properties out of your code. It supported structured properties, so if something was a TFont, it expanded into sub-properties for font name, font size and so on.
If you created a new class TGradientButton or something, and exposed two properties FromColor and ToColor, they would show up in the object inspector, automatically, and since these properties would be something like TColor, it would know to display an RGB widget for them.
You could also register custom object inspector behaviour, so that, instead of FromColor/ToColor, perhaps there was only one property "Gradient" of type TGradient. Your custom object inspector thingy could then render a gradient editor for that property.
XCode + Interface Builder is about 10% of what Delphi was. I say "was", it still exists, but I haven't touched it since around 2000-2001. It's insane that Delphi 1.0 in 1995 was more powerful than XCode + Interface Builder today.
(I suppose it lives on in the Visual.NET tools; after creating Delphi, Anders Hejlsberg joined Microsoft and created C#. But I haven't used any of it.)
You don't have to use JSX. You can use React.DOM directly or use react-hyperscript as a shorthand method for React.DOM
Also pay attention to the new createFactory method which aims to make it easy to separate your changing HTML from the static HTML (which you would have previously used a templating library for)
My recommendation is to not use JSX ever since it breaks a lot of your tooling. The first impression people get is that "Hey this makes my code easier to read", but that is only because JSX introduces the problem that it attempts to solve.
Basically most HTML structures are 80% unchanging and 20% changing (the reason we use templates in the first place). React.DOM was a pain previously because you'd define a complicated HTML structure in Javascript, which isn't really any harder or more complex, but then you'd have all this code that was never changing distracting you from the code that was changing (i.e. your app behavior). JSX fixed this problem by turning all the static bits to html like templates do so it was visually easy to separate from your behavior code. This was the wrong solution because it's over engineered and breaks compatibility with a lot of things.
createFactory essentially allows you to "partially apply" the static parts and get a function that only needs to deal with the dynamic parts (like compiled template functions but for virtual DOM)
Anyways, check out the following links:
https://github.com/mlmorg/react-hyperscript
https://gist.github.com/sebmarkbage/d7bce729f38730399d28
Also pay attention to the new createFactory method which aims to make it easy to separate your changing HTML from the static HTML (which you would have previously used a templating library for)
My recommendation is to not use JSX ever since it breaks a lot of your tooling. The first impression people get is that "Hey this makes my code easier to read", but that is only because JSX introduces the problem that it attempts to solve.
Basically most HTML structures are 80% unchanging and 20% changing (the reason we use templates in the first place). React.DOM was a pain previously because you'd define a complicated HTML structure in Javascript, which isn't really any harder or more complex, but then you'd have all this code that was never changing distracting you from the code that was changing (i.e. your app behavior). JSX fixed this problem by turning all the static bits to html like templates do so it was visually easy to separate from your behavior code. This was the wrong solution because it's over engineered and breaks compatibility with a lot of things.
createFactory essentially allows you to "partially apply" the static parts and get a function that only needs to deal with the dynamic parts (like compiled template functions but for virtual DOM)
Anyways, check out the following links:
https://github.com/mlmorg/react-hyperscript
https://gist.github.com/sebmarkbage/d7bce729f38730399d28
Separation of concerns is different from separation of technologies. For more details, view Pete Hunt's excellent talk at http://2013.jsconf.eu/speakers/pete-hunt-react-rethinking-be...
The question is whether those concerns need separating. I've come to believe that the price to pay for that "separation" is too big and ends up being a re-implementation of shared scope (see angular's $scope)
Likewise the price to pay is yet another template language. ReactJS uses JavaScript as its template language. No more exporting filters, weird looping and conditional constructs. Just use Javascript. It just makes sense.
To everybody trying to make this into a tech fight about Angular vs. React/whatever, I've been repeating this like a mantra and even mentioned it in a talk on javascript once[0]:
You can argue about the minor details of the tech stack till you turn green and blue, but Angular wins because it succeeds in the only metric that really counts.
jQuery: (for reference)
I am absolutely confident that they are making good calls and the way they have handled the transition periods so far (and the way they are going about these new "big" changes) only increases my confidence.
I would be very surprised if in a few years, Angular wasn't on the same level of "you can basically assume that it's loaded" as jQuery is.
[0] https://www.flickr.com/photos/valanx/14136669418/in/set-7215...
You can argue about the minor details of the tech stack till you turn green and blue, but Angular wins because it succeeds in the only metric that really counts.
jQuery: (for reference)
5,656 commits
7 branches
122 releases
199 contributors
3,003 commits
10 branches
18 releases
226 contributors
7,490 commits
35 branches
90 releases
412 contributors
5,988 commits
12 branches
111 releases
1,044 contributors <---
I am absolutely confident that they are making good calls and the way they have handled the transition periods so far (and the way they are going about these new "big" changes) only increases my confidence.
I would be very surprised if in a few years, Angular wasn't on the same level of "you can basically assume that it's loaded" as jQuery is.
[0] https://www.flickr.com/photos/valanx/14136669418/in/set-7215...
A lot of contributors could also mean that Angular was buggy or lacking features from the start, and that people had to contribute to fix it themselves.
It could also mean that the code was easy enough to understand so that more people could contribute.
I don't think you can reasonably say that there's "the only metric that really counts". All these metrics are indicators of activity anyway, not quality.
I don't think you can reasonably say that there's "the only metric that really counts". All these metrics are indicators of activity anyway, not quality.
I can only quote myself to clarify, here:
> They get community right and at the end of the day, that's the only thing that really counts.
> They get community right and at the end of the day, that's the only thing that really counts.
I disagree. The only metric that counts is how productive you are with it. We use something else because it just fits our mindset better.
Sure, but peopke often fall into the trap of only considering short term productivity. Choosing something that won't be maintained in a few years will be a big lose in productivity.
If popularity is the only metric that counts, then logically you should also dismiss anything other than PHP, MySQL, and Apache for the server side out of hand.
I could live with that. That said, they are obviously not the best for every application but swapping out MySQL for the next up contender (Postgres) and Apache with Nginx and PHP with Ruby or python would not change the picture dramatically. Switching to Java+Tomcat or a javascript framework on the serverside would change the picture in a dramatic way.
Popularity is not the most useful measure but it is a useful metric to determine the viability of a framework and it also gives an idea about how open a team is to outside contributions which is a huge factor in eventual success. (See: Linux vs Minix).
I'm not a fan of Javascript either on the clientside or on the serverside but I agree with the GGP that they seem to get community right and even if every other decision they make is wrong in the long turn that may make them the equivalent of PHP in their domain.
Popularity is not the most useful measure but it is a useful metric to determine the viability of a framework and it also gives an idea about how open a team is to outside contributions which is a huge factor in eventual success. (See: Linux vs Minix).
I'm not a fan of Javascript either on the clientside or on the serverside but I agree with the GGP that they seem to get community right and even if every other decision they make is wrong in the long turn that may make them the equivalent of PHP in their domain.
Every Angular documentation page has a link to edit the doc right in github.
The same is true for React but not for Amber nor jQ.
However React's docs are much simpler than Angular since it only provides the View and the docs are only a few pages really.
The same is true for React but not for Amber nor jQ.
However React's docs are much simpler than Angular since it only provides the View and the docs are only a few pages really.
Interesting.
But I see the comparisons is between Apples and Oranges here.
jQuery is a DOM library.
Angular and Ember are client-side MVC libraries.
React is an [isomorphic] UI library.
IMHO Angular/Ember and React and jQuery don't even compare in the same planes.
I'm not supporting React here, but its quite new and off late its getting a lot of traction. So the number of contributors and commits for a library that's quite new is astonishing!
And frankly I feel Angular team made a huge mistake by completely changing the syntax which makes it difficult to be adopted by anyone that knows/uses Angular 1.x.
But I see the comparisons is between Apples and Oranges here.
jQuery is a DOM library.
Angular and Ember are client-side MVC libraries.
React is an [isomorphic] UI library.
IMHO Angular/Ember and React and jQuery don't even compare in the same planes.
I'm not supporting React here, but its quite new and off late its getting a lot of traction. So the number of contributors and commits for a library that's quite new is astonishing!
And frankly I feel Angular team made a huge mistake by completely changing the syntax which makes it difficult to be adopted by anyone that knows/uses Angular 1.x.
You say "everybody trying to make this into a tech fight", but the truth is that you are the one opposing communities based on important but not essential metrics.
Some like Angular, some like React, some like Ember. Companies are successful with all 3 of these frameworks. And that's what counts. What's important is whether the tools help us get things done. And all 3 frameworks do exactly that, in different ways.
You can try to say "I win", but you only win if your product works better than your competitors, not if you have a "better" framework.
Some like Angular, some like React, some like Ember. Companies are successful with all 3 of these frameworks. And that's what counts. What's important is whether the tools help us get things done. And all 3 frameworks do exactly that, in different ways.
You can try to say "I win", but you only win if your product works better than your competitors, not if you have a "better" framework.
The only thing that matters wrt software libraries is if it helps deliver and maintain software more efficiently and with less frustration than others. There are three dimensions to this, how great is the library today (with regards to efficiency of construction and maintainability of software), how much better (or worse) will it get in the future, and how long will it be around. Unfortunately these things are hard to measure and predict.
The number of committers only gives you some insight to any three of these things, and can actually mislead you. The Javascript ecosystem is ridiculously fast moving (which is a nice way to put it :)) so number of committers doesn't tell me if all those folks will just jump onto the next thing that comes along. Also, the Javascript community has developers of a wide variety of skill levels, so the number of committers doesn't necessarily say much about the quality of the library without understanding who these committers are. I'd argue there is often a small number of key contributors to any open source project, with other folks contributing small patches to fix bugs or minor enhancements, so the total number of committers doesn't tell you a much more important thing: who are the key contributors, what is their background and views on software engineering, and how likely are they to remain committed to the project over the long term?
It seems to me the main thing Angular has going for it is that Google has bought in to it, so that means no matter how flawed it is (or not), it's not going anywhere anytime soon so you can be sure security fixes and bugs will continue be addressed over the long term. Then again, Facebook seems all-in on React (and I'm not sure about Ember) so maybe this isn't much of a differentiator.
The number of committers only gives you some insight to any three of these things, and can actually mislead you. The Javascript ecosystem is ridiculously fast moving (which is a nice way to put it :)) so number of committers doesn't tell me if all those folks will just jump onto the next thing that comes along. Also, the Javascript community has developers of a wide variety of skill levels, so the number of committers doesn't necessarily say much about the quality of the library without understanding who these committers are. I'd argue there is often a small number of key contributors to any open source project, with other folks contributing small patches to fix bugs or minor enhancements, so the total number of committers doesn't tell you a much more important thing: who are the key contributors, what is their background and views on software engineering, and how likely are they to remain committed to the project over the long term?
It seems to me the main thing Angular has going for it is that Google has bought in to it, so that means no matter how flawed it is (or not), it's not going anywhere anytime soon so you can be sure security fixes and bugs will continue be addressed over the long term. Then again, Facebook seems all-in on React (and I'm not sure about Ember) so maybe this isn't much of a differentiator.
React is just newer. Give it some time.
Indeed. If number of contributors is the only metric that counts then, since React has more contributors than jQuery, I guess that means we shouldn't bet on jQuery. Nobody's gonna be using that fly-by-night project in a year!
That's why I wrote "for reference". jQuery, of course, is a different kind of library.
A proper argument would be: jQuery has about three times the contributors that mootools has. If I had to decide between mootools and jQuery, I'd pick the second because of that metric alone, yes. (And this is how the market ended up playing out.)
Angular (born Jan 2010) has 2.5 times the number of contributors of ember (born Apr 2011), 5 times of React (born May 2013). I'm not just trying to find a reason to dismiss React and I do realize that it is still young. From a business standpoint, though, the choice couldn't possibly be any clearer.
I do agree that React has gathered a sizable crowd in a short time and it's definitely on my list of projects that I keep an eye on. But it's simply too young to warrant the same kind of investment that I have personally made into Angular.
A proper argument would be: jQuery has about three times the contributors that mootools has. If I had to decide between mootools and jQuery, I'd pick the second because of that metric alone, yes. (And this is how the market ended up playing out.)
Angular (born Jan 2010) has 2.5 times the number of contributors of ember (born Apr 2011), 5 times of React (born May 2013). I'm not just trying to find a reason to dismiss React and I do realize that it is still young. From a business standpoint, though, the choice couldn't possibly be any clearer.
I do agree that React has gathered a sizable crowd in a short time and it's definitely on my list of projects that I keep an eye on. But it's simply too young to warrant the same kind of investment that I have personally made into Angular.
> But it's simply too young to warrant the same kind of investment that I have personally made into Angular.
Sure .. it makes sense. Though one of the main selling points of React is that it's dead easy.
Sure .. it makes sense. Though one of the main selling points of React is that it's dead easy.
Pro-tip: Instead of pointing to forks and contributors, and complicated metrics, you'd do better advocating for Angular on this site if you instead point to benefits of the technology itself.
We are big boys and girls here we can take the technical details. No need to use all these external proxies.
We are big boys and girls here we can take the technical details. No need to use all these external proxies.
Those that can't evaluate the technology for what it is have to find other proxies. Number of forks. Number of meetups per year. Blog posts. What color shoes does the creators wars. Etc.
I think once proponets start to point to all these other things and not to nherent benefits or advantages of the technologies, they have already lost me.
I think once proponets start to point to all these other things and not to nherent benefits or advantages of the technologies, they have already lost me.
Interesting view point, but number of contributors is just proxy for the real metric, which is number of users. You can have a relatively closed group of developers make something that a lot of people use.
Isn't this misguided? A better metric would be to look at the project age as well.
Actually I think there are a few metrics that may be interesting. And different teams and organisations may put different weight to each metric.
Have you seen Sarah Mei's talk about metrics and choosing a technology? She talks about Ruby but it seems to work the same for any technology choice.
https://www.youtube.com/watch?v=dE4toi7y1MM
What if all 1,044 contributors were non-technical 4 year olds? My point is that you clearly don't mean this literally.
The number of contributors is an indicator of the terminal goal. It's not the terminal goal itself. It's very important to remember that.
The number of contributors is an indicator of the terminal goal. It's not the terminal goal itself. It's very important to remember that.
You made a good point about the community.
[deleted]
I totally agree on the community point. I was thinking just yesterday how it's strange that when I think of Angular, a single person doesn't come to mind. This is probably a good thing, along the lines of the new way in which protests are developing in a decentralized way, like in Hong Kong. Maybe the model of the BDFL is finally getting superseded by the crowdsourced platform, with all the warts of that latter process. The problem with the BDFL is that there's a lot of trust necessary in the person in charge.
Except Igor Minar is pretty much that guy.
Guys, relax and stop whining. You are probably wrong about what is going to happen with Angular, because you underestimate how massive Angular has become.
I recently began searching for a new JavaScript job. I don't like Angular at all and I am skipping all positions that mention it. I have to skip ~90% of all ads. Think of it – 90% of companies that are expanding their web development use Angular.
So, even if this change will kill Angular, it will probably take years. It has become too big to fail.
If you like Angular, get excited about it. Look at how .NET or Java guys accept everything coming from Microsoft or Oracle. You are in a similar ship now. No one got fired for choosing Angular. No one will.
I recently began searching for a new JavaScript job. I don't like Angular at all and I am skipping all positions that mention it. I have to skip ~90% of all ads. Think of it – 90% of companies that are expanding their web development use Angular.
So, even if this change will kill Angular, it will probably take years. It has become too big to fail.
If you like Angular, get excited about it. Look at how .NET or Java guys accept everything coming from Microsoft or Oracle. You are in a similar ship now. No one got fired for choosing Angular. No one will.
Is this right? I can't believe for a millisecond that 90% of all new JS jobs relate to Angular, it's a horrible and overblown framework with a high barrier to entry. Were you looking at a particular subset of jobs, a particular industry or in a particular location?
> it's a horrible and overblown framework with a high barrier to entry
Listen, if I can figure it out and get lots and lots of work done with it, it's neither horrible nor overblown and the barrier of entry was there but I got over it. By all means, keep ignoring it, but drop the shtick where you know better than thousands and thousands of us out here building things with it.
Listen, if I can figure it out and get lots and lots of work done with it, it's neither horrible nor overblown and the barrier of entry was there but I got over it. By all means, keep ignoring it, but drop the shtick where you know better than thousands and thousands of us out here building things with it.
>if I can figure it out and get lots and lots of work done with it, it's neither horrible nor overblown
That's a weird argument. Just because you think it's not horrible or overblown doesn't really mean much. That's just an opinion.
I've worked full-time with AnguarJS over a year, and I know it pretty well. It's easily better than jQuery spaghetti code, and probably better than most data-binding frameworks. It has lots of issues, though. From bad documentation and performance to the mess of $scope.$apply/digest loop and a lot of moderate design problems.
Anyway, the biggest problem is the boat. AngularJS is really trying to "eat" other libraries and actually doesn't try to be modular. A data-binding/MVC framework shouldn't invent it's own module system, and recently it's own programming language. Apparently Google is trying to kill of jQuery too and substitute their own system. And they want to reinvent everything as AngularJS modules instead of "plain" JavaScript code that can be used across multiple frameworks.
What I'd like to see in AngularJS 2 is a tiny core which does data-binding without $scope.$apply, is fast and modular and could be used with a wide range of other frameworks. What I don't want to do is start writing AngularJS modules with AtScript and using their forced(?) ES6 classes.
That's a weird argument. Just because you think it's not horrible or overblown doesn't really mean much. That's just an opinion.
I've worked full-time with AnguarJS over a year, and I know it pretty well. It's easily better than jQuery spaghetti code, and probably better than most data-binding frameworks. It has lots of issues, though. From bad documentation and performance to the mess of $scope.$apply/digest loop and a lot of moderate design problems.
Anyway, the biggest problem is the boat. AngularJS is really trying to "eat" other libraries and actually doesn't try to be modular. A data-binding/MVC framework shouldn't invent it's own module system, and recently it's own programming language. Apparently Google is trying to kill of jQuery too and substitute their own system. And they want to reinvent everything as AngularJS modules instead of "plain" JavaScript code that can be used across multiple frameworks.
What I'd like to see in AngularJS 2 is a tiny core which does data-binding without $scope.$apply, is fast and modular and could be used with a wide range of other frameworks. What I don't want to do is start writing AngularJS modules with AtScript and using their forced(?) ES6 classes.
Angular 2 definitely aims to be more modular - the Angular team acknowledges the problem that it isn't modular enough itself. Stuff like di.js, watchtower.js, zone.js, etc. are all built with modularity in mind & are framework agnostic. I think once Angular hits 2.0 and it becomes highly modular, we are going to see a boom in development productivity. Some of what is currently in Angular is unique for JavaScript, such as the change listener pattern and dependency injection. These are things that we'd like to take advantage of with other libraries. Combining stuff like di.js with React sounds very appetizing to me.
In addition, it would appear that we would be able to use these libraries with Node.js as well.
I can only see this being a good thing.
In addition, it would appear that we would be able to use these libraries with Node.js as well.
I can only see this being a good thing.
> That's a weird argument. Just because you think it's not horrible or overblown doesn't really mean much. That's just an opinion.
A contrary opinion to the OP's opinion. Are you asking me "where's the data" (?), because this whole thread is opinions.
edit:
> It has lots of issues, though.
No argument here. Providing validation feedback on forms, for instance. I'm not arguing that it's perfect and that I'll never love again, but it has opened up my head this year and for that I'll go to the mat for it.
A contrary opinion to the OP's opinion. Are you asking me "where's the data" (?), because this whole thread is opinions.
edit:
> It has lots of issues, though.
No argument here. Providing validation feedback on forms, for instance. I'm not arguing that it's perfect and that I'll never love again, but it has opened up my head this year and for that I'll go to the mat for it.
I'm not ignoring it, please don't put words in my mouth. If people want to use it then that's their choice, albeit one I find fairly baffling. Given the other replies to my comment it seems I'm not alone.
Hey pal, drop the chip on your shoulder. Just because AngularJS has wide adoption doesn't change the fact that it is an extremely poorly designed framework. I also refuse to consider AngularJS jobs. Many developers have had to suffer through bad frameworks like GWT because of industry trends. Those bruises are not badges of honor. ReactJS is a framework that is clearly better designed. Why waste time learning and suffering through AngularJS absurdities when ReactJS exists?
I don't have a chip on my shoulder. It just reminds me of that old comeback for people who are complaining about how terrible PHP is - "oh, I'm sorry. I couldn't hear you over all the work I was getting done with it."
> Why waste time learning and suffering through AngularJS absurdities when ReactJS exists?
Because I'd have to suffer through learning and integrating Backbone or Flux in addition to React to accomplish what I could by learning just Angular. And then I'd have to hope that my choices remained compatible with each other through version updates. Anyway, I may find React to be a better designed lib when I get around to using it, but it's definitely not an apples to apples comparison when it's only attempting to tackle 1 of the pieces that Angular handles.
> Why waste time learning and suffering through AngularJS absurdities when ReactJS exists?
Because I'd have to suffer through learning and integrating Backbone or Flux in addition to React to accomplish what I could by learning just Angular. And then I'd have to hope that my choices remained compatible with each other through version updates. Anyway, I may find React to be a better designed lib when I get around to using it, but it's definitely not an apples to apples comparison when it's only attempting to tackle 1 of the pieces that Angular handles.
... because jobs?
I'm in agreement with your point, but... if 'the market' wants angular... 'the market' is going to have a hell of a time dealing with a mess in a couple of years when many of the decision makers that mandated angular move on to something else and leave piles of mess behind for someone else to clean up.
I'm in agreement with your point, but... if 'the market' wants angular... 'the market' is going to have a hell of a time dealing with a mess in a couple of years when many of the decision makers that mandated angular move on to something else and leave piles of mess behind for someone else to clean up.
There may not be moving on. Or it may take a very long time. Angular is that big already.
Previously there was no the framework for web frontend development (like Rails for Ruby). From now on you will need convincing reasons to use anything else, even if it is clearly better. Moving on to something else will be much harder.
Previously there was no the framework for web frontend development (like Rails for Ruby). From now on you will need convincing reasons to use anything else, even if it is clearly better. Moving on to something else will be much harder.
Is it big in production deployments or only in hiring managers wishes?
I would like to know an answer to that question.
On the other hand my wish is not to get into stupid arguments at my new job :)
On the other hand my wish is not to get into stupid arguments at my new job :)
I don't think that problem is restricted to Angular - it's one that you see with when developers wrote unmodular code period. I saw it with legacy ExtJS code.
Oh I completely agree it's not an angular thing. It was a Rails thing, is or will be a 'node' thing, etc. It will be a docker thing at some point too. There's a rush to 'new' that appears to everyone to be 'it', people use 'it' for a bit, realize it doesn't solve all problems, then move on to something else. They've done a lot of learning on someone's dime, moved on, but left a mess of code for someone else to 'maintain' for years. The cycle will continue to repeat itself for a long time...
> when many of the decision makers that mandated angular move on to something else and leave piles of mess behind for someone else to clean up.
That's already happening. Two contacts came up in the last two weeks with Angular projects gone off the rails (pun intended).
That's already happening. Two contacts came up in the last two weeks with Angular projects gone off the rails (pun intended).
I've been looking In the US for remote positions, contracts, and local. If they are using a framework theres 90% chance it's angular. For all javascript/html/Css type jobs its more like 50-60%. I've talked to consulting/contracting companies and they have agreed that they have far more requests angular than any other front end tech.
I agree with your comment about it. I tried it and didn't like it. I've talked to a few devs who Have mentioned issue in larger projects more around organizing the code base.).
Regardless of all of that. There's so much demand that I'm going to drop emberjs and learn angular.
I agree with your comment about it. I tried it and didn't like it. I've talked to a few devs who Have mentioned issue in larger projects more around organizing the code base.).
Regardless of all of that. There's so much demand that I'm going to drop emberjs and learn angular.
Yes it is a horrible and overblown framework. However it has this "made by Google" sticker on it. No one got fired for choosing Google ;)
I haven't done the exact numbers and 90% seems really high, but it feels like it. I bet the exact number wouldn't be lower than 75%.
I live in Eastern Europe, but I am mostly looking for remote jobs. I am a real full-stack developer and would gladly work on backend with Node.js, but these jobs are even rarer these days.
I haven't done the exact numbers and 90% seems really high, but it feels like it. I bet the exact number wouldn't be lower than 75%.
I live in Eastern Europe, but I am mostly looking for remote jobs. I am a real full-stack developer and would gladly work on backend with Node.js, but these jobs are even rarer these days.
> No one got fired for choosing Google ;)
Only a brave woman would build her house on GWT
Only a brave woman would build her house on GWT
Angular is attractive to "strategic technologists" because it's rich in ceremony, edifice and nomenclature inspired by the European Union.
A platform like this achieves critical mass when it starts appearing in McKinsey slides, and then it will become a permanent fixture in job ads for the next 10 years. I guess Angular has reached that milestone.
A platform like this achieves critical mass when it starts appearing in McKinsey slides, and then it will become a permanent fixture in job ads for the next 10 years. I guess Angular has reached that milestone.
The enterprise folks have arrived to ruin everything. Run, just run!
I've just been looking for JavaScript work in the UK. Certainly the majority (maybe not 90%, but definitely > 50%) of jobs mention Angular. It's difficult to tell how many of these are just "put something cool on the advert to attract the hipsters" and how many are actual "we use or will use angular heavily in production" though.
UK here too, and this sounds about right. I would say that most of these shops are not using Angular "heavily in production" right now - either they will have some portion of an existing project that they're trying to move to Angular or a greenfield project for which they're evaluating Angular and think anybody with that skill would be a valuable addition to the team, whether or not they end up using Angular.
In terms of roles I see posted on LinkedIn in the UK (which may or may not be representative of the industry as a whole, but it's all I've got to go on), there's a lot of Angular, a lot of "Angular or similar (eg. Backbone)", and a lot of "MVC (eg. Angular, Backbone)". Many of those same roles do also mention jQuery, but not with the same sort of billing it might have had two years ago. I'm not sure I've ever seen a role specifically mentioning Ember.
Like quite a few others in this thread, I'm an Angular naysayer for the standard reasons, and would generally prefer to avoid it, but the market does rather dictate what we end up doing sometimes, for better or for worse.
In terms of roles I see posted on LinkedIn in the UK (which may or may not be representative of the industry as a whole, but it's all I've got to go on), there's a lot of Angular, a lot of "Angular or similar (eg. Backbone)", and a lot of "MVC (eg. Angular, Backbone)". Many of those same roles do also mention jQuery, but not with the same sort of billing it might have had two years ago. I'm not sure I've ever seen a role specifically mentioning Ember.
Like quite a few others in this thread, I'm an Angular naysayer for the standard reasons, and would generally prefer to avoid it, but the market does rather dictate what we end up doing sometimes, for better or for worse.
90% is certainly high. But he's not that far from the truth. A lot of companies do expect anyone working with JS to know Angular... which is not good for me. I'm really not a fan of that framework.
> it's a horrible and overblown framework with a high barrier to entry.
I'm honestly surprised how often I keep hearing about its high barrier to entry. I've worked on ~5 different MVC style web frameworks, all server side, over ~5 years of professional programming. I just started a front-end position using Angular for the last three months, and have found it pretty straight-forward to pick up. That is, the concepts I learned server-side have translated fairly cleanly to the front-end.
Most of the people I've seen struggle with the framework so far are those that didn't have that server side experience. Which isn't to say its required, but only to say some of the concepts they struggle the most with are concepts you need for any MVC style web framework - server side or front-end. Its not that they are that similar, but that they encounter and solve many of the same problems. Routing, separation of concerns, dependency injection, testing, getting what you want into the template, etc. And Angular isn't what you'd call a micro framework (see Django vs Flask or Bottle from Python world, for example). So of course Angular is large; it tries to solve alot of problems for you (how well it does so is another story).
Anyways, the take-away (from my point of view) is that much of the work that used to be done by server-side guys can now be done by front-end guys. So they have to learn all the same concepts and struggle with all the same problems to be effective.
I'm honestly surprised how often I keep hearing about its high barrier to entry. I've worked on ~5 different MVC style web frameworks, all server side, over ~5 years of professional programming. I just started a front-end position using Angular for the last three months, and have found it pretty straight-forward to pick up. That is, the concepts I learned server-side have translated fairly cleanly to the front-end.
Most of the people I've seen struggle with the framework so far are those that didn't have that server side experience. Which isn't to say its required, but only to say some of the concepts they struggle the most with are concepts you need for any MVC style web framework - server side or front-end. Its not that they are that similar, but that they encounter and solve many of the same problems. Routing, separation of concerns, dependency injection, testing, getting what you want into the template, etc. And Angular isn't what you'd call a micro framework (see Django vs Flask or Bottle from Python world, for example). So of course Angular is large; it tries to solve alot of problems for you (how well it does so is another story).
Anyways, the take-away (from my point of view) is that much of the work that used to be done by server-side guys can now be done by front-end guys. So they have to learn all the same concepts and struggle with all the same problems to be effective.
It's sad to see a post on HN specifically devoted to Angular utterly devolve into framework flame wars. If the title were "Why Angular 2 will be better than React" I could understand, but this is just a sneak preview of features to come. Can we please just choose the tools we prefer and build stuff instead of nursing our insecurities about the choices we've made?
As someone at the inflection point of choosing a single-page framework, I find these "flamewars" incredibly useful. Further I find the notion that this is evidence of insecurity itself evidence of insecurity -- why feel threatened that people discuss alternatives and merits/detriments?
When new language features of C# or other languages (e.g. Go) are brought up on here, inevitably those features and benefits will be contrast against other languages. And they should. Because we aren't hammers and everything isn't a nail, and even if we happen to use tool A today, we usually have the capacity to move to tool B tomorrow if it made sense.
When new language features of C# or other languages (e.g. Go) are brought up on here, inevitably those features and benefits will be contrast against other languages. And they should. Because we aren't hammers and everything isn't a nail, and even if we happen to use tool A today, we usually have the capacity to move to tool B tomorrow if it made sense.
Surely you don't really find "off topic" complaints an insecurity. This article is about Angular 2.0, I would expect to read about thoughts/pros/cons about Angular 2.0 when reading the comments.
It's similar to reading comments on a Halo (Xbox) post on Reddit. Over half the comments are flame wars about PS4 > Xbox. There have been many "framework vs. framework" potss already on HN, let's keep the flamewars contained.
It's similar to reading comments on a Halo (Xbox) post on Reddit. Over half the comments are flame wars about PS4 > Xbox. There have been many "framework vs. framework" potss already on HN, let's keep the flamewars contained.
No, sometimes you don't really know what something is without holding it up to a yardstick. Flamewars are annoying, but this isn't a flamewar.
Carry on.
Carry on.
What is the scope of an on-topic pros and cons discussion, though? It seems that the relative comparison should include competitors, especially given how large of a change this apparently will be. For a current user of Angular it isn't a certainty that will make them a user of 2.0.
Reason is -- Angular 2 is quite a departure from Angular 1 and a good number of poeple will at that point might choose to envaluate other frameworks.
React is the _other_ popular framework today so people are talking about.
In large the discussion is fairly civil (so far), people are passionate and seem to care about the topic and are discussing it.
React is the _other_ popular framework today so people are talking about.
In large the discussion is fairly civil (so far), people are passionate and seem to care about the topic and are discussing it.
I don't think this is a flame war at all, I think people are pissed at all these breaking changes. I've seen them coming from miles away, I'm still a little distant from Angular until it's API modernizes and matures.
I think people like to mention React because every since it was publicized last year Facebook has had ES6 integration in mind. With Angular, 2's goals have been up for a long time but I don't think many people thought about how much the API would have to change to accommodate the new features.
I think people like to mention React because every since it was publicized last year Facebook has had ES6 integration in mind. With Angular, 2's goals have been up for a long time but I don't think many people thought about how much the API would have to change to accommodate the new features.
The problem I see with this is that it's very different from Angular 1 to the point people using Angular would have to learn it all over again.
Breaking how the framework looks this drastically is both very brave and very risky. Especially since from discussions with Angular core (and as you can see from the presentation) - Angular 2.0 relies heavily on ES6 features and syntax which are not yet supported in any browser and worse - are not known by most web developers anyway.
Breaking how the framework looks this drastically is both very brave and very risky. Especially since from discussions with Angular core (and as you can see from the presentation) - Angular 2.0 relies heavily on ES6 features and syntax which are not yet supported in any browser and worse - are not known by most web developers anyway.
I'm only guessing that it'll be another year or so before Angular 2 is in a release-ready state... It's a huge break from the prior version, and imho a good one.
The tooling will be the most interesting to me, I can only guess that they'll use node and traceur for building the output in a project to something a browser can use. I've been moving towards React (and Flux) as it lines up well with the way I've been developing with node. This just takes it a step farther.
As for the features that aren't well known, this will change and have to be learned. There's enough in the ES6 stuff that I'm running new development against Node 0.11 so that I can get generator support and some other language features in place. Though still using the CommonJS/Node style require() statements.
I do hope, that like React and its' tooling that the Angular guys have a compelling case and support for shared server/client logic and rendering as well as support for Browserify and Webpack+hot-reload. Though I like Webpack I think it goes too far from the node system, it is really nice however and I can see why others use it.
It's all really interesting... I'm curious to see where Polymer goes from here as well...
The tooling will be the most interesting to me, I can only guess that they'll use node and traceur for building the output in a project to something a browser can use. I've been moving towards React (and Flux) as it lines up well with the way I've been developing with node. This just takes it a step farther.
As for the features that aren't well known, this will change and have to be learned. There's enough in the ES6 stuff that I'm running new development against Node 0.11 so that I can get generator support and some other language features in place. Though still using the CommonJS/Node style require() statements.
I do hope, that like React and its' tooling that the Angular guys have a compelling case and support for shared server/client logic and rendering as well as support for Browserify and Webpack+hot-reload. Though I like Webpack I think it goes too far from the node system, it is really nice however and I can see why others use it.
It's all really interesting... I'm curious to see where Polymer goes from here as well...
> Angular 2.0 relies heavily on ES6 features and syntax which are not yet supported in any browser
Which is why part of the project is a compiler which compiles ES6 (actually, an ES6 superset) to ES5, which is supported by every browser.
https://github.com/google/traceur-compiler
Which is why part of the project is a compiler which compiles ES6 (actually, an ES6 superset) to ES5, which is supported by every browser.
https://github.com/google/traceur-compiler
Agreed. This looks almost like a complete rewrite, which seems like a good thing because IMO Angular 1 is overly complex. But it does make me wonder if I should bother to really learn Angular 1 at all. The main thing pushing me towards Angular has been the size of the community but if they're wiping the slate then I might just go with React after all.
Angular has some huge support and momentum behind it... there has also been a lot of job postings around it as well. That said, I couldn't get past some of my issues with it, and that server rendering (shared code) was not really a good option there... The issues with dependency injection is another issue, and testing pretty much requires a browser.
These are the reasons I'm using flux/react now. I'm really looking forward to following the development of Angular 2 now, and may just be my tool of choice for new development in a couple years.
These are the reasons I'm using flux/react now. I'm really looking forward to following the development of Angular 2 now, and may just be my tool of choice for new development in a couple years.
I don't know, somebody has to be first though. Also, from what I've heard it's like two years away anyway.
Google is developing AtScript, which compiles down to ES5. I don't think that's the right way to go, though..
I think it's hilarious how javascript frameworks are beginning to resemble java frameworks. This new release is really starting to look like Spring, including annotations. The increasingly complex DI is also looking like Spring.
original author came from Java server-side background I believe, that probably explains why you see similarities.
Yeah, in IT we tend to go full circle. Or full retard. :)
I that is what I thought too. I believe in a couple of years we'll be hearing jokes about the "fat" frameworks we used and shot ourselves in the foot.
Kind of like how people make fun of Enterprise Java Beans' FactoryFactory... methods.
Kind of like how people make fun of Enterprise Java Beans' FactoryFactory... methods.
There have been so many binding frameworks, with a few varieties of approach. It has always been clear that it's "experimental". But it's been a few years now, and the mature(er) frameworks are focusing themselves.
This is a good thing! I'm glad they're learning, and willing to make it better. In my career I've gone from ASP -> PHP -> ASP.NET Web Forms -> ASP.NET MVC -> Angular/knockout/react. We're developers, if you can't flow with change you should move on to one of the more established engineering disciplines.
This is a good thing! I'm glad they're learning, and willing to make it better. In my career I've gone from ASP -> PHP -> ASP.NET Web Forms -> ASP.NET MVC -> Angular/knockout/react. We're developers, if you can't flow with change you should move on to one of the more established engineering disciplines.
It's not about you, the developers. You can easily move on and jump from frameworks to frameworks.
Your clients or employers suddenly have to worry about one extra thing because their newly developed applications/systems suddenly become 'out of date' simply because the crazy churn in on JavaScript frameworks API.
It is not a good thing. We are invalidating people's investments, time and money for no good reason.
Your clients or employers suddenly have to worry about one extra thing because their newly developed applications/systems suddenly become 'out of date' simply because the crazy churn in on JavaScript frameworks API.
It is not a good thing. We are invalidating people's investments, time and money for no good reason.
Honestly, that's why you don't develop a new production system in a framework that's just a few years old. I had a coworker suggest using Angular on our main product that pays our bills. My reply was, it looks great... i'm excited about it, but I think we should use it on less critical systems until it matures. There's too many unknowns. There's no reason every new platform you develop needs to be using literally the latest tech. Actually, there's really good reasons not to.
Too many unknowns is way too broad of a reason when it comes to JS. JS is already the language of unknowns. It really depends on the framework, timing of things, people behind it. Angular is by Google, but also Google is pushing Web Components at the same time, which can integrate with Angular 2, but it challenges it as well. Also with Angular 2's goals being known for a long time, anyone could tell that ES6 would be a dramatic wave of change to the framework.
With JS, all the frameworks and libraries out there are just a few years old. Angular is about 5 years old, but Google doesn't even use Angular in their sites, which should be extremely telling (along with the complexity learning and figuring out the API). In fact I think Google isn't even planning on Angular on any Google sites in the future. They are waiting until Web Components are finalized.
With React, it is apparently mature enough, it is used on Facebook (1 billion users), Instagram (a child company of Facebook, like Youtube for Google), Khan Academy, Github (github issue viewer), AirBnB, CloudFlare, and a lot more:
https://github.com/facebook/react/wiki/Sites-Using-React
In the JS world, there's a lot of reason to keep moving forward with tech. Sure it doesn't have to be the latest and greatest, but since JS is such a "poor" language, a lot of these newer tools, features, framework, and libraries help build more professional, quality code. Shying away from newer tech (again not the latest and greatest, but away from tech that improves quality of code) highlights obstinance and ignorance about the technology behind it, as well as how little someone understands the industry today.
With JS, all the frameworks and libraries out there are just a few years old. Angular is about 5 years old, but Google doesn't even use Angular in their sites, which should be extremely telling (along with the complexity learning and figuring out the API). In fact I think Google isn't even planning on Angular on any Google sites in the future. They are waiting until Web Components are finalized.
With React, it is apparently mature enough, it is used on Facebook (1 billion users), Instagram (a child company of Facebook, like Youtube for Google), Khan Academy, Github (github issue viewer), AirBnB, CloudFlare, and a lot more:
https://github.com/facebook/react/wiki/Sites-Using-React
In the JS world, there's a lot of reason to keep moving forward with tech. Sure it doesn't have to be the latest and greatest, but since JS is such a "poor" language, a lot of these newer tools, features, framework, and libraries help build more professional, quality code. Shying away from newer tech (again not the latest and greatest, but away from tech that improves quality of code) highlights obstinance and ignorance about the technology behind it, as well as how little someone understands the industry today.
Google does use Angular on many sites in production - the number is somewhere over 120 according to their metrics last I heard. They even use it for static pages - I noticed that the older Google Nexus pages were done in Angular. They prominently tout using Angular for DoubleClick, among other sites. It is also used widely internally.
Angular is also used by a formidable set of companies in production - Microsoft, Google, Apple, VMware, Netflix, MSNBC, Bloomberg, Washington Post, USA Today, US News & World Report, Amazon, Udacity, Cisco, and countless others. I have heard of it being used in the financial sector quite a bit as well. The prevalance of Angular and the strong support by Google is far more telling.
Angular is also used by a formidable set of companies in production - Microsoft, Google, Apple, VMware, Netflix, MSNBC, Bloomberg, Washington Post, USA Today, US News & World Report, Amazon, Udacity, Cisco, and countless others. I have heard of it being used in the financial sector quite a bit as well. The prevalance of Angular and the strong support by Google is far more telling.
I don't think this is a bad thing. The angular they built will still be working, just like C++ that was written 10 years ago will still be working.
Don't invest in a framework that does not respect your time commitment and existing implementation. They break compatibility between 1 and 2. It is most likely they will break 2 and 3 as well.
Don't be that programmer that leave shit all over the place for his/her successor to pick up due to bad choice of technology stack.
Don't be that programmer that leave shit all over the place for his/her successor to pick up due to bad choice of technology stack.
Every large opinionated framework is "overblown" (aka "scary") until you actually take the time to learn it and code a few large non-trivial projects with it. I've learnt more MVC frameworks than you can shake a stick at and Angular is hands down one of the best. Once you're comfortable with it you can fly and code things so quickly and cleanly, and it scales well into complex apps too. Angular is largely designed the way it is to promote small, encapsulated, testable components. But if you're not practising TDD, or don't test your code at all, (which I suspect is the case for many of the framework's detractors) then it possibly is somewhat over architected - by all means pick a simpler framework, but don't knock it from a position of ignorance.
We're not saying Angular's bad, just that React's approach is better :) I've tested both (and quite a few other MVVM libraries actually) before I came to this conclusion.
Of course, I gain nothing by someone choosing Angular over React or vice versa. I'm just sharing my experience and leaving them to make their own choice.
Of course, I gain nothing by someone choosing Angular over React or vice versa. I'm just sharing my experience and leaving them to make their own choice.
TBH, I'm both amazed by the power and simplicity of Angular && mad at how difficult and unpredictable is to unit test services that use promises and/or depend on other services.
You can fully mock out those services and pass them into the component under test. Those mocks could return an immediately succeeding (or failing) promise for example. Hey presto, no uncertainty or weird promise handling code in your tests.
I think promises are hard to test regardless of framework. As a side note most Angular examples seems to do more functional testing than unit testing since they don't mock many other services.
Ouch, just spent this month learning Angular... And now 'RIP angular.module, controllers, $scope' etc.
Does anyone have some idea about when this launches and when it can be sort of considered stable for building apps beyond mere prototyping? Curious about the timeframe :) Thanks
Does anyone have some idea about when this launches and when it can be sort of considered stable for building apps beyond mere prototyping? Curious about the timeframe :) Thanks
> Ouch, just spent this month learning Angular
I've found that no knowledge I've gained from learning technology/framework/language etc has ever gone to waste.
Somewhere down the line, the insights gained previously come in really handy or even make something that I thought wasn't possible, realizable.
I've found that no knowledge I've gained from learning technology/framework/language etc has ever gone to waste.
Somewhere down the line, the insights gained previously come in really handy or even make something that I thought wasn't possible, realizable.
Looks like your learning is still valid for another couple years - this isn't being released any time soon, and in fact won't run in most of today's browsers.
Two years in internet-time is a long time! For all you know, civilisation as we know it will have ceased by then.
Two years in internet-time is a long time! For all you know, civilisation as we know it will have ceased by then.
Took some digging but I found a video: https://www.youtube.com/watch?v=S8fE-w2DL8U#t=54m12s
Edit: They took it down, sorry :\
Edit: They took it down, sorry :\
This video is private.
Igor posted on his twitter there'd be a video soon. Surely OP will deliver...
https://twitter.com/IgorMinar/status/525807334099288064
https://twitter.com/IgorMinar/status/525807334099288064
This looks like a completely new framework, version 1.0.
I don't think I'll use Angular for any new projects, they basically flushed every library and documentation (1st and 3rd party) down the drain.
I don't think I'll use Angular for any new projects, they basically flushed every library and documentation (1st and 3rd party) down the drain.
As somebody with little experience writing web applications, having just used ember for a my last project, these Angular 2 Core highlights seem way behind ember.
I knew there was a reason I put off learning angular.
I'm not so sure. I think it will take about 5 years for angular 1.x to lose momentum.
Intresting, but WHY are these approaches better. Is that adequately explained?
I think this is the problem with posting slides, and not a video. For most presentations slides are bullet points. It's like ordering a cheese burger without the burger.
From http://jaxenter.com/angular-2-0-112094.html:
> the framework will be “drastically different looking”, meaning users will need to get to grips with a new kind of architecture. It’s also been confirmed that there will be no migration path from Angular 1.X to 2.0.
> Currently Angular is aiming for a release by the end of 2015 – but early 2016 seems more realistic given the drastic changes that are planned.
This essentially makes investing in Angular pointless, when there are far more capable and easier to learn frameworks out there - Meteor primarily, and also Derby.js, though it's got about 1/10th of the momentum of Meteor, which launched 1.0 two days ago, and had 20k GitHub stars without backing from some giant company. BTW, Meteor never broke compatibility with earlier releases in such drastic ways as Angular will.
> the framework will be “drastically different looking”, meaning users will need to get to grips with a new kind of architecture. It’s also been confirmed that there will be no migration path from Angular 1.X to 2.0.
> Currently Angular is aiming for a release by the end of 2015 – but early 2016 seems more realistic given the drastic changes that are planned.
This essentially makes investing in Angular pointless, when there are far more capable and easier to learn frameworks out there - Meteor primarily, and also Derby.js, though it's got about 1/10th of the momentum of Meteor, which launched 1.0 two days ago, and had 20k GitHub stars without backing from some giant company. BTW, Meteor never broke compatibility with earlier releases in such drastic ways as Angular will.
It took a lot of time for me to get the hang of AngularJS 1.x and now AngularJS 2 seems very promising but shifting along with the new syntax, programming logic is really painful..
They should provide a path to easily shift programmers thinking from 1.x to 2 (hopefully it is already in their roadmap)
They should provide a path to easily shift programmers thinking from 1.x to 2 (hopefully it is already in their roadmap)
IIRC, in the larger Google Doc cache of their Core documentation for Angular 2.x, they've stated in the manifesto of sorts that, well, that "easy shift" may just not be possible. Primarily when it comes to migrating existing applications.
Although I am looking forward to the Angular 2.x mainly to see what it has in store in terms of performance.. i had had faced performance issues with Angular regularly
1. For developers, change is usually a good thing in regards to our careers. If you aren't learning and growing, it's not Angular that will go away, it's you.
2. They are following the http://semver.org definition of a major version change perfectly fine "MAJOR version when you make incompatible API changes".
3. If anyone is bothered by the complete shift, fork Angular at version 1.3 and maintain it yourself. That's the joy of open source. You might even be a hero to many other developers.
2. They are following the http://semver.org definition of a major version change perfectly fine "MAJOR version when you make incompatible API changes".
3. If anyone is bothered by the complete shift, fork Angular at version 1.3 and maintain it yourself. That's the joy of open source. You might even be a hero to many other developers.
I tried both EmberJS and Angular. To me it seems Ember is years ahead, the main advantages:
- clean model abstraction, which prevents soo much boilerplate - clean templates - components, partials, great re usability
- clean model abstraction, which prevents soo much boilerplate - clean templates - components, partials, great re usability
I've built one significant project in Ember, and three in Angular (multi-month projects with a small team; requiring maintenance for the next 3-4 years; < $100k USD).
Ember 'feels' so much more right to me. I really enjoyed working with it and it reminded me of the desktop frameworks I used to work with. It's not without it's faults, but what is.
But sadly Ember just doesn't seem to be holding it's head up in the ongoing swell of JS frameworks. I think that is a great pity. But time goes on and they'll all be forgotten in a few years.
Ember 'feels' so much more right to me. I really enjoyed working with it and it reminded me of the desktop frameworks I used to work with. It's not without it's faults, but what is.
But sadly Ember just doesn't seem to be holding it's head up in the ongoing swell of JS frameworks. I think that is a great pity. But time goes on and they'll all be forgotten in a few years.
"its"
Is there anywhere with further detail on this?
(Because it looks fascinating, but I'd like to see some detailed documentation and examples on how it's going to work.)
(Because it looks fascinating, but I'd like to see some detailed documentation and examples on how it's going to work.)
Yes, if you go to the AngularJS GitHub it's full of design documents and debates about 2.0, for example - here is 2.0 change detection for the data binding: https://github.com/angular/watchtower.js/
It's not proper documentation but debates and design documents but it's all there.
Of course - not to forget https://github.com/angular/Angular2.design
It's not proper documentation but debates and design documents but it's all there.
Of course - not to forget https://github.com/angular/Angular2.design
I don't know exactly how many of the Durandal & Angular convergence[1] features made it into Angular 2.0, but it looks like lazy module loading and a better component syntax did, which is fantastic
[1] http://angularjs.blogspot.fi/2014/04/angular-and-durandal-co....
[1] http://angularjs.blogspot.fi/2014/04/angular-and-durandal-co....
I love how they use attributes, I've been impressed by attribute modules for CSS. The only thing I am surprised, I would think that this would include significant overhead, yet you claim it is way faster. Most likely previous scanning of the dom was even slower.
I think this is excellent use of attributes and good way to refactor things. What others pointed out, this is different framework :)
I think this is excellent use of attributes and good way to refactor things. What others pointed out, this is different framework :)
Great to see HTML5 growing so rapidly during the past few years! That said, I'm not a huge fan of frameworks, they do not work so well except for basic pattern apps. When you have an app worth building you consider very carefully what foundation stones to use. I ended upright on my feet and happily dancing using React as one of the stones.
Can anyone suggest which practices can be added to the use of 1.3* to ease the transition to 2.0? For instance, if I start using grunt-ng-annotate or gulp-ng-annotate now, will that help ease the transition? If it would, I'd be curious what other things I could do to make the switch less abrupt.
I think the biggest win would be to start using ES6 and getting used to using the import/export syntax.
New syntax is ok, quite cool actually, but I'd rather see more improvement on things like route, high performance repeat. Hope they bring some goodness from Angular 2 to Angular 1x as well. Also, not sure how the old directive/plugin ecosystem would fit in, is there any rewrite needed?
In your face Angular fans, who said that all the angular stuff was the best way. They scrapped most of it!
After looking at the doc, my first reaction is that all HTML should be schema compliant. Using non-standard HTML in the constructs will screw up a lot of tooling and validation.
It's also safe to say this is just too big of a change without public commentary. Way too big.
It's also safe to say this is just too big of a change without public commentary. Way too big.
I understand wanting to appeal to the same user base and tell that it was develop by the same team. It's a brand decision. Nevertheless Angular 2 "deserve" a completely new name. It has no resemblance of Angular 1.x. Welcome to a new framework.
Nothing surprising or disappointing here in my opinion. It was my understanding from day 1 that ng was Google's experiment and attempt in transforming and mutating HTML into a language for web apps instead of web sites.
Is this for real? Is this the official direction for AngularJS 2?
Seems like a very big leap considering people are just getting use to the way AngularJS 1 works ($scopes etc).
Seems like a very big leap considering people are just getting use to the way AngularJS 1 works ($scopes etc).
This is what is shit with JavaScript frameworks, no respect to backward compatibility. Imagine if these kind of API churning happens in C++ or other languages.
I'm sat right now coding a bunch of new stuff in angular 1.2 - it was feeling sweet until I read this - now it feels old and outdated. Time to just ignore the massive race to reinvent the framework and just get some stuff done I think.
Since when is C++ a framework?
What does Angular win you beyond what you get in Web Components? I haven't used Angular, so this is curiosity, not a challenge being issued.
I'm now wondering what will happen to other projects that have placed a huge bet in Angular 1.x, like the Ionic Framework for example...
Is he using TypeScript or ECMAScript 6? Also, is it just me, to does this seem like a completely different framework than Angular 1?
Typescript is ECMAScript6, with additional (typing) features.
I'd venture it's ecmascript 6 being used, as Google suffers NIH syndrome too..
I'd venture it's ecmascript 6 being used, as Google suffers NIH syndrome too..
I wouldn't call TypeScript an "ECMAScript 6 with types". It feels more like a superset of ECMAScript 5 as it introduces non-standard features such as static class properties and public/private scoping while major ES6 features such as proxies, symbols, generators, modules or block scoping are not supported.
Yeah, it definitely is EcmaScript 6. They've added the "class" and "constructor" keywords. Typescript is very mush modeled after EcmaScript 6 anyways, so technically it can be both. But I'm sure it's EcmaScript6, because that's what Angular 2 is written in.
See the post about Google's AtScript that was on HN yesterday.
So is this basically TypeScript with annotations and types available at runtime?
is there a video of this? viewing these slides is like reading every-other page of a book :(
So... upgrade path is nonexistent?
Looks like it's great if you're starting from scratch though!
Looks like it's great if you're starting from scratch though!
[deleted]
time to find another framework to work with
or best is, just scrape client side MVC framework, and fallback to server MVC framework
or best is, just scrape client side MVC framework, and fallback to server MVC framework
bye bye angular. need new framework due to 2.0
if I have to rewrite then I might as well look at others.
Is this just a proposal or something?
This is a change for the far worse, someone branch this please and maintain a backward compatible branch with the same syntax.
I know Angular has a lot of community support and I have built some side projects in Angular but I feel now too bloated with having their own standards instead of following normal HTML standards. That's just my 2 cents on it and i'm sure there are a ton of reason to use Angular but I just don't know if I can continue supporting a project that makes so many drastic changes to a standard. I don't want to make it sound like I have Angular hate here but i'm a big vanilla fan and it seems in order to build anything useful in Angular you have to throw out vanilla and use Angular's way even if vanilla is better. On most projects handlebars and correct proper design patterns in code is enough to keep HTML out of javascript and keep basic organization.