Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Angular 2 Core

docs.google.com

Post reply on HN
Print view View original

181–190 of 279 posts

Re: Angular 2 Core

#181

Post by EugeneOZ »

Cthulhu_ wrote: post #37

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

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.

Re: Angular 2 Core

#182

Post by Offler »

bryanlarsen wrote: post #25
gasping wrote: post #24

Earlier quoted context omitted.

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

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

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.

Re: Angular 2 Core

#183

Post by jshen »

mmgutz wrote: post #108
skore wrote: post #36

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) 5,656 commits 7 branches 122 releases 199 contributors…

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.

Re: Angular 2 Core

#184

Post by kuni-toko-tachi »

nilliams wrote: post #99
kuni-toko-tachi wrote: post #55

Earlier quoted context omitted.

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

  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);
Javascript does not need Java-style dependency injection. Javascript's configuration language JSON is valid Javascript.

Re: Angular 2 Core

#185

Post by thekingofspain »

joshkpeterson wrote: post #144
woah wrote: post #126

Earlier quoted context omitted.

I've been using Vue.js recently, it's a lot like Angular (inspired by?), without all the crazy nonsense: http://vuejs.org/api/

Terrible name. Edit: Other framework name ideas ~ Modil.js, Controllr.js, Framework.js, Class.js, js.js

Vue is French, you know, right?

Re: Angular 2 Core

#186

Post by cmdkeen »

Bahamut wrote: post #19
pedalpete wrote: post #10

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

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.

Re: Angular 2 Core

#188

Post by Bahamut »

davidholmesnyc wrote: post #92

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…

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.

Re: Angular 2 Core

#189

Post by nilliams »

kuni-toko-tachi wrote: post #184
nilliams wrote: post #99

Earlier quoted context omitted.

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

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); Javascript does not need Java-style dependency injection. Javascript's configuration language JSON is valid Javascript.

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

Re: Angular 2 Core

#190

Post by dodyg »

peteypao wrote: post #88
dodyg wrote: post #84

Earlier quoted context omitted.

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.

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.

Post reply on HN