Live data from Hacker News

Angular 2 Final Released

angular.io

331–340 of 452 posts

Re: Angular 2 Final Released

#331
post #324

Earlier quoted context omitted.

he's right... (!isNaN('100') && isFinite('100')) === true My check would treat '100' as a number, so if i did something like this it would break unexpectedly: var num = '100' if ((!isNaN(num) && isFinite(num)) === true) { console.log(num + 10) } You'll get "10010" printed to the console.

Well that's because this is checking if a value may be a valid number. It's not safely converting the value to a number. That's done after a parseFloat()

You guys make my point for me.

There's no way on earth we'd be arguing about such a ridiculously trivial thing for most other languages.

Nobody should have to look any of this up.

Yeah, we work around it ... but it drives me crazy. :)

Re: Angular 2 Final Released

#332
post #141

Earlier quoted context omitted.

Of note, Facebook's create-react-app provides an "official' opinionated approach. https://facebook.github.io/react/blog/2016/07/22/create-apps... There's even a pull request to bring typescript into the mix. https://github.com/facebookincubator/create-react-app/pull/5...

I'm just writing a first React app, and read beforehand that it was going to be difficult to choose which libraries to use, and to get them to work together, but I haven't found that to be much of an issue in practice. create-react-app set up all the build tooling, for a router the clear recommendation is react router, and for a flux implementation the clear recommendation is Redux. It feels like there's a well defin…

Good thing you don't have clients demanding IE compatibility. Bye bye ES6 :-(

Re: Angular 2 Final Released

#333
post #195

Earlier quoted context omitted.

Cons: 1. Typescript. If your team isn't familiar with it it's not trivial to get everyone on board. The up-front cost can absolutely be worth it in the long run, but there's some friction in the day-to-day work with managing type definition files and looking up esoteric lint-errors from the Typescript compiler. 2. RXJS. Canonical NG2 should use Observables, and rxjs is not a trivial library to learn the ins and outs…

It's very strange to me, any one of the cons from 3-6 will make me avoid a framework. Do you think the pros of the framework outweigh these serious cons?

At the moment? No, I don't think so.

To be brutally honest I think the only reason why this is on HN frontpage is because of its name. It's quite telling that they kept the name despite it being a totally different beast with (imho) an entirely different audience. No way they'd get this much support from the webdev community otherwise.

However I do see the potential, and one should not forget that this is just the first version, straight out of the oven.

Give it some time and I'm sure it will improve.

Re: Angular 2 Final Released

#334

Earlier quoted context omitted.

Well... I would argue that angular 2 is not even better than angular 1 so it will probably happen again :p It's more performant, but that's about it. It's insane, java/spring like complex for no reason.

Really? So mobile support, change detection revamp, TypeScript, the removal of $scope, and all the routing changes are all just "meh" to you?

Wellllllll... I does make me want to learn React & React Mobile if I have to largely start over, anyway.

Not saying ng-2 is not an improvement, just that it's a big change to take in.

Re: Angular 2 Final Released

#335
post #239

Earlier quoted context omitted.

I lost so much time with Angular 1. I don't care how much v2 is better than v1, I'm not touching it with a ten foot pole (disclaimer: switched to React, not looking back).

I'm really feeling the pain right now. Convinced previous company react was better. Even built my own app in React, now I'm at a new place that is using Angular 1.5. My god, it's so painful trying to get everything working correctly with jquery plugins. The blessed route often doesn't work, even though technically it should. I'm also getting performance issues for really simple scenarios...

The only thing in ng-1 that really bit me, speed wise, was long select/option lists. I wrote a bit to load them using jQuery instead of ng-options and now I'm good.

Re: Angular 2 Final Released

#336
post #302

Earlier quoted context omitted.

It's very strange to me, any one of the cons from 3-6 will make me avoid a framework. Do you think the pros of the framework outweigh these serious cons?

To be fair, outside of testing I have generally found the documentation to be excellent. Also, the debugging tools seem to be pretty nice. In particular, Angular Augury looks amazing: https://augury.angular.io/ However, if you dislike the approach to templating, you will definitely dislike angular. This is one of those things that is controversial, regardless of which approach they had chosen.

[deleted]

Re: Angular 2 Final Released

#337
post #266
post #8

Is there a definitive angular versus react versus ember (or others) pros/cons/community status page out there somewhere?

You know what, these religious debates need a war to settle the question. Let's get 3 of the best teams for each stack, have them build the same 4 apps that cover a few of the most common scenarios... and let's see who's solution is done the fastest, is most maintainable, and has the best performance.

Emacs, of course.

Re: Angular 2 Final Released

#338
post #195
post #77

Earlier quoted context omitted.

Any chance you can do a quick cons review too? Specifically comparing to the weakness of Angular 1 like bloated complexities, issue with custom directives or scope life-cycle.

Cons: 1. Typescript. If your team isn't familiar with it it's not trivial to get everyone on board. The up-front cost can absolutely be worth it in the long run, but there's some friction in the day-to-day work with managing type definition files and looking up esoteric lint-errors from the Typescript compiler. 2. RXJS. Canonical NG2 should use Observables, and rxjs is not a trivial library to learn the ins and outs…

> looking up esoteric lint-errors from the Typescript compiler.

Thought that's a lot better than hunting down bugs in production.

Re: Angular 2 Final Released

#339
post #85

Earlier quoted context omitted.

From a purely pragmatic point of view, I can say that I write very little code when using react-bootstrap, can create screens quickly and the results look good. Not sure how much simpler of an API you can get. But to each their own. +1 to choice.

It's not about just simple - it's about making the right architectural choices that don't come back to bite you due to the need to make a change that brings down a house of cards from a library perspective. ng-bootstrap avoids problematic apis such as component-based modals, and makes use of the much more natural service-based approach to allow developers maximum flexibility. If a developer prefers a component-based…

I don't think that your service based model is more extensible. Yes, I could build a component based version on top of the service based version. But I can also build a service based version on top of the component based version.

In fact from a peek at the source, the NgbModal class is built on a NgbModalWindow class which acts much like react-bootstrap's modal. So, ng-bootstrap builds the service based version on a component based version. If either library can be accused of bloat it ng-bootstrap for including the serviced based version when I might just want to use the NgbModalWindow directly. (Its not in the documentation, so I wouldn't actually use NgbModalWidnow directly in practice, even if I'd want to.)

Now, I've drunk the react cool-aid, so take my opionion with salt. But in my assesment while modals can be somewhat awkward in the declarative style, they aren't awkward enough to make me break my rule of avoiding imperative apis.

Re: Angular 2 Final Released

#340

Earlier quoted context omitted.

I'm just writing a first React app, and read beforehand that it was going to be difficult to choose which libraries to use, and to get them to work together, but I haven't found that to be much of an issue in practice. create-react-app set up all the build tooling, for a router the clear recommendation is react router, and for a flux implementation the clear recommendation is Redux. It feels like there's a well defin…

The sanctioned way forward for React is Flow. It's not as comprehensive as TypeScript, but there's no compilation required - Flow annotations just get stripped out. As of a couple of weeks ago it is part of create-react-app. https://flowtype.org

Too bad flow doesn't work as well as typescript in practice. It has way more bugs, is not as tested.

It was very promising at first but typescript now has caught up with Flow best design decision: noImplicitAny, strictNullChecks.

Also, check on the "try typescript" website: typescript's JS output is almost left untouched. it's effectively a replacement for babel, if you only care for ES2015 stuff, and not some of the more recent stage 0 / stage 1 stuff.

Post reply on HN