Live data from Hacker News

Angular 1 and Angular 2 integration: the path to seamless upgrade

angularjs.blogspot.com

11–20 of 102 posts

Re: Angular 1 and Angular 2 integration: the path to seamless upgrade

#11
post #4
post #3

Remember when we were worried about the semantic purity of our HTML.

Remember separation of concerns ? Fuck that, let's just mash code and markup together.

What concerns do you think you're separating exactly, when you're dealing with presentation-tier markup and code that combine intimately to a single component?

Re: Angular 1 and Angular 2 integration: the path to seamless upgrade

#12
post #8

Earlier quoted context omitted.

I don't know that "semantic" is what you mean here. Semantics in HTML is about exposing the meaning of content through the DOM. Adding data-binding via attributes doesn't change that at all. Name still encodes just as much semantics as Name I think what you might have meant, as mariusmg mentioned in a sibling comment, is "separation of concerns"? Personally I think that has diminishing returns as your application get…

I think it's more like "syntactic" then semantic. Is syntatically valid HTML, although ng-model may not be a legal attribute name in standard HTML. On the other hand: Isn't even syntactically valid HTML. It kind of rubs me the wrong way too, although I don't know if it matters in practice, although I'm not sure it doesn't either. It does seem ugly.

I'm not sure you are correct. According to the w3 spec for HTML attributes [0], html element attribute names must consist of one or more characters other than the space characters, U+0000 NULL, """, "'", ">", "/", "=", the control characters, and any characters that are not defined by Unicode.

Granted, it isn't necessarily what I'd expect to be legal, but it doesn't look illegal either. We may just need to add some logic to HTML colorizing syntax checkers in our IDEs is all.

[0]: http://www.w3.org/TR/html-markup/syntax.html#syntax-attribut...

Re: Angular 1 and Angular 2 integration: the path to seamless upgrade

#13
post #5

I have been evaluating writing some new applications in Angular at work and was quickly turned away from it because before today the actual migration path seemed very unclear. Without a migration path, picking v1 for a new application at this point would be silly, and 2 is completely unready for production. Hearing that they are really planning on making it more or less "backwards compatible" is definitely a smart mo…

Since Angular 2 was announced, I had the feeling that I picked the wrong framework for our product with Angular 1, and was feeling regrets about that choice towards my team, to have blocked them with a framework without future. Knowing that we'll be able to slowly move our app to Angular 2, one feature at a time, is certainly the best news I've had in a while.

BTW, why do I always feel like betting in a horse race when choosing a web framework/library? Hoping it'll be maintained long enough, hoping it'll not be deprecated after 6 months for the new cool kid...

Re: Angular 1 and Angular 2 integration: the path to seamless upgrade

#14
post #12

Earlier quoted context omitted.

I think it's more like "syntactic" then semantic. Is syntatically valid HTML, although ng-model may not be a legal attribute name in standard HTML. On the other hand: Isn't even syntactically valid HTML. It kind of rubs me the wrong way too, although I don't know if it matters in practice, although I'm not sure it doesn't either. It does seem ugly.

I'm not sure you are correct. According to the w3 spec for HTML attributes [0], html element attribute names must consist of one or more characters other than the space characters, U+0000 NULL, """, "'", ">", "/", "=", the control characters, and any characters that are not defined by Unicode. Granted, it isn't necessarily what I'd expect to be legal, but it doesn't look illegal either. We may just need to add some l…

interesting!

Re: Angular 1 and Angular 2 integration: the path to seamless upgrade

#15
See , that's how you manage an open source project , you listen to your community , and yes people can have relevant suggestions. Angular JS became successful because of its pragmatism but also because it allowed more than 1000 people to contribute to its core, not because it was a "Google project" .

Everybody knows what other project i'm talking about.

Re: Angular 1 and Angular 2 integration: the path to seamless upgrade

#18

Earlier quoted context omitted.

Since Angular 2 was announced, I had the feeling that I picked the wrong framework for our product with Angular 1, and was feeling regrets about that choice towards my team, to have blocked them with a framework without future. Knowing that we'll be able to slowly move our app to Angular 2, one feature at a time, is certainly the best news I've had in a while.

BTW, why do I always feel like betting in a horse race when choosing a web framework/library? Hoping it'll be maintained long enough, hoping it'll not be deprecated after 6 months for the new cool kid...

I had always a bad feeling about angular.

The first guy I heard talking about it was like "It was made by an underdog at google" and "We often had the feeling about hitting a dead end when developing with it, but it was always because we were using it wrong" which both sounded strange to me.

I used ExtJS, Ember and React. And never switched away from them because it wasn't maintained anymore. It just happened that people preferred to use new frameworks on new projects.

Re: Angular 1 and Angular 2 integration: the path to seamless upgrade

#19
I see 2-way data-binding is mentioned here and will still be supported (good). Curious why has 2-way now become 'uncool' recently, e.g. React? 2-way is what got me excited about client side JS due to the code reduction in an average app. Is just that Angular 1's implementation was non-performant? (lots of other frameworks use it as well, e.g. Knockout, RactiveJS, etc).

Re: Angular 1 and Angular 2 integration: the path to seamless upgrade

#20
post #4
post #3

Remember when we were worried about the semantic purity of our HTML.

Remember separation of concerns ? Fuck that, let's just mash code and markup together.

Business logic should still remain separate. This would be display logic.
Post reply on HN