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.
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.
Angular 2 Core
191–200 of 279 posts
Re: Angular 2 Core
#192Earlier quoted context omitted.
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
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)
Re: Angular 2 Core
#193I feel that Angular changes too much in HTML to be considered useful for long term projects.The new syntax is also disturbing. My ideal MVC for front end utilizes regular javascript and html tags. At most just add data-ang-click="" something like that instead of "(click)" the latter isn't even valid HTML. Sometimes I think Angular is mainly popular because it's supported by Google. If any regular developer made these…
Re: Angular 2 Core
#194I feel that Angular changes too much in HTML to be considered useful for long term projects.The new syntax is also disturbing. My ideal MVC for front end utilizes regular javascript and html tags. At most just add data-ang-click="" something like that instead of "(click)" the latter isn't even valid HTML. Sometimes I think Angular is mainly popular because it's supported by Google. If any regular developer made these…
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.
Re: Angular 2 Core
#195I'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…
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).
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.
Re: Angular 2 Core
#196Earlier quoted context omitted.
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…
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.
Re: Angular 2 Core
#197Angular 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.
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.
- this feels like it is a key conceptual difference but I'm not clear on what this means.
Re: Angular 2 Core
#198Is 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..
Re: Angular 2 Core
#199Earlier quoted context omitted.
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.
Re: Angular 2 Core
#200I feel that Angular changes too much in HTML to be considered useful for long term projects.The new syntax is also disturbing. My ideal MVC for front end utilizes regular javascript and html tags. At most just add data-ang-click="" something like that instead of "(click)" the latter isn't even valid HTML. Sometimes I think Angular is mainly popular because it's supported by Google. If any regular developer made these…
> 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…
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.