Live data from Hacker News

Angular 2 Final Released

angular.io

301–310 of 452 posts

Re: Angular 2 Final Released

#301
post #26

As someone who uses Angular 1 currently but would pick React for their next project, I'd love to see a list of reasons why I should use Angular 2 over React. If nothing else, Angular just stranded all their developers, while React has a huge head start on mindshare/plugins/tutorials/etc.

All three frameworks are excellent at helping us build ambitious front-end applications; you simply can't go _wrong_ by picking one over the other. If a particular framework's trade-offs don't for any part of the app (performance for example), you can always write just that part in a different way (manual DOM manipulation). But to contrast all three, I'll pick the area I'm most interested in - templating. The purpose…

Apologises if I'm miss reading this

> Angular and Ember allows state and logic inside HTML.

State updates do not occur in Ember templates. Templates specify the follow data from one component to another, as well as callbacks which are names of actions defined in a javascript portion of a component, or a parent component.

But it does not allow you to specify how state is updated within the template. In terms of Logic, there's just if statements & loops which is pretty conservative imo.

edit: rephrasing words

Re: Angular 2 Final Released

#302
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?

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.

Re: Angular 2 Final Released

#303

Earlier quoted context omitted.

Could you elaborate on what you mean by "shoehorning everything into components that don't belong there"?

Compare for yourself: https://react-bootstrap.github.io/components.html#btn-dropdo... (click on show code) vs https://ng-bootstrap.github.io/#/components/dropdown (click on )

I don't understand the distinction you are trying to draw. Both examples seem to put the same configuration in the component tree.

Re: Angular 2 Final Released

#304
post #170

Earlier quoted context omitted.

> 3. Idea of `(events)` and `[attributes]` is awesome, works really effective and makes code much more easy to read. This is encouraging. I always thought that looked aweful so it's nice to hear that it actually makes sense.

Having used ng2 in production for a while, I personally dislike the model behind this, mainly because it is not actually symmetric as it appears from a first look: - input: ``` ``` - output: ``` ``` To me this seems unfinished and inelegant; note also that everything is inherently mutable, but change detection will work best when the bound input values are reassigned, but if they are instead mutated at some deeper le…

try [()]

Re: Angular 2 Final Released

#305
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…

We've converted all our node apps to typescript and I've even started messing around with replacing all our back end promises/callbacks with rxjs.

Re: Angular 2 Final Released

#306
post #59

Earlier quoted context omitted.

Could you elaborate on what you mean by "shoehorning everything into components that don't belong there"?

There seems to be a lot of advocacy for tossing everything into the component tree in the React ecosystem - recently I got linked to a snide remark by Ryan Florence on Twitter implicitly arguing for putting everything in the component tree, including constructs that should have a better separation such as routing (which the tweet appeared to be a reference to). Some services don't belong in JSX though - this is why y…

I can see the objection to putting routing information (and similar) in the component tree.

But you were talking about bootstrap components which obviously do belong in the component tree, so I'm confused by your response.

Re: Angular 2 Final Released

#307
post #196
post #48

I evaluated React and Angular 2 several months ago and picked React. Some of the issues I found in Angular 2: The HTML template in Angular 2 is stored in a string. This has several disadvantages: 1. Editors can't do syntax coloring. 2. Editors can't do auto-indenting. 3. Editors can't offer "intellisense" suggestions. 4. Editors can't match tags. You embed variables in this template string like this: ' {{hero.name}}…

>The HTML template in Angular 2 is stored in a string. This has several disadvantages This is patently false. Just use "templateUrl" instead of "template". This allows you to specify a file instead. This is the way I always did it in angular 1 as well. I don't really understand why style guides & general practice recommend embedding html in the javascript though. It's horrible.

Does Angular 2 do any compiler magic with these templates? or are the templates parsed at runtime?

Re: Angular 2 Final Released

#308

Serious question : Why are SPA frameworks so popular these days? When someone asks "What should I use for web development?", It's now all about React/Angular/Ember/etc. But when I look at how are built the sites I like and visit frequently, I'd say 95% of them are not SPA, they are classic sites where the server generate each page (sometimes with one or two Ajax requests)! The Single Page pattern is great for desktop…

SPA frameworks are not all-encompassing tools for buildong all web pages. Notably, trying to SEO a SPA is frustrating at best and impossible at worst. However, in b2b use cases where SEO isn't an issue, SPA frameworks are ideal for coordinating a static-site dynamic-api system.

Server-side rendering is supported in several SPA frameworks now, and SEO is not an issue if you use it.

Re: Angular 2 Final Released

#309
post #59

Earlier quoted context omitted.

There seems to be a lot of advocacy for tossing everything into the component tree in the React ecosystem - recently I got linked to a snide remark by Ryan Florence on Twitter implicitly arguing for putting everything in the component tree, including constructs that should have a better separation such as routing (which the tweet appeared to be a reference to). Some services don't belong in JSX though - this is why y…

I can see the objection to putting routing information (and similar) in the component tree. But you were talking about bootstrap components which obviously do belong in the component tree, so I'm confused by your response.

Not everything is a component - as I pointed out in another response below, a modal is one clear example where you want an imperative API.

Re: Angular 2 Final Released

#310

Earlier quoted context omitted.

"1) Isn't it just (!isNaN(num) && isFinite(num))? I know that's pretty far from intuitive, but it's not as bad as you made it sound. That being said, i'd love an `isNumber` function at some point..." You just proved my point! A) Even if you are correct - it's terrible . This is completely ridiculous that there's no basic check for extremely common and mundane type-checking. Moreover, it's the same issue for other typ…

1) well look at that! I guess i've gotten a bit spoiled relying on lodash as much as I do! 2) There are aspects of prototypes that JS makes much worse (mainly the whole "this" clusterfuck), but the base is pretty sane and easy to understand. But at that point i'm not even talking about javascript any more, so I guess you are right here too. 3) I still disagree with you here. Yeah, there should be a way for the stdlib…

"But another benefit of multiple different implementations is they are free to optimize for different things."

Every language has that. There are different JVM's, different C/C++ compilers, different python interpreters.

JS is not 'at any advantage' here - and again - the drawback is the ridiculous fragmentation we see across browsers - which is ... bad - at least compared to other languages.

Post reply on HN