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 brows…
Angular 2 Core
81–90 of 279 posts
Re: Angular 2 Core
#82Re: Angular 2 Core
#83Earlier quoted context omitted.
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?
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, bu…
Only a brave woman would build her house on GWT
Re: Angular 2 Core
#84There 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 yo…
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.
Re: Angular 2 Core
#85Earlier quoted context omitted.
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 suf…
... 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.
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.
Re: Angular 2 Core
#86- clean model abstraction, which prevents soo much boilerplate - clean templates - components, partials, great re usability
Re: Angular 2 Core
#87Earlier quoted context omitted.
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.
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 requireme…
Re: Angular 2 Core
#88There 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 yo…
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.
Re: Angular 2 Core
#89Earlier quoted context omitted.
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 requireme…
> 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 als…
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.