Live data from Hacker News

Angular 2 Core

docs.google.com

191–200 of 279 posts

Re: Angular 2 Core

#191

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.

It is not an upgrade if your old stuffs stop working. Man, 1.0 used to mean something.

Re: Angular 2 Core

#192
post #179
post #32

Earlier 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)

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.

Re: Angular 2 Core

#193

I 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…

You might want to have a look at Mithril, it's extremely minimalistic and fast: lhorie.github.io/mithril/mithril.html

Re: Angular 2 Core

#194

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

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.

Re: Angular 2 Core

#195
post #19

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…

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

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.

Re: Angular 2 Core

#196

Earlier 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…

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.

Re: Angular 2 Core

#197
post #17

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.

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.

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.

Re: Angular 2 Core

#198

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

Re: Angular 2 Core

#199

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

So is this basically TypeScript with annotations and types available at runtime?

Re: Angular 2 Core

#200

I 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…

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

Post reply on HN