Live data from Hacker News

Angular 2 Final Released

angular.io

431–440 of 452 posts

Re: Angular 2 Final Released

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

On 3. I've found Aurelia templates to be much better in that regard. Their templates are valid HTML and compile well. I'm not a huge fan of embedding html within the JS (even with JSX) been easier to work with separate template files and keep as much JS out of them as possible. This has helped reduce harder to debug errors that crop up when the JS inside templates fails.

I concur. Aurelia feels much more like the standard HTML that I've been working with since the 90s, only more powerful. Hence we get power without unnecessary complexity.

Re: Angular 2 Final Released

#432

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.

Yeah, we have Angular 1 code in production, and I would like us to get off this train. I'm going to be evaluating Vue.js and Aurelia, and will probably push for Aurelia.

We were in the same boat back in January, and I looked at Vue and many others, but Aurelia won me over even though it was still in beta.

Re: Angular 2 Final Released

#433

Rob Eisenberg and his nimble team beat Angular 2 to the punch all the way back in July when Aurelia final was released. Before considering Angular, considering checking out http://aurelia.io - easier to learn, no third party dependencies and great support. I applaud the Angular team for sticking it out, but I am afraid they released far too late to compete with the likes of React, Vue and so on.

I now have several Aurelia apps in production. I've also created an app in Angular (v1), and another using Ionic (v1) - which was great. But, I can't express how well Rob and his team executed on this project. Documentation could be a little better in a couple areas but this is a place where they've done extremely well also (contradiction I know - but, for example the cheat sheets are amazing and documentation is com…

The documentation has been improving since January, and I expect there to be plenty more in a short time because for over half a year they were focused more on getting from beta to a full release. But even with the cheat sheets it felt like there was plenty to get work done because the complexity isn't so high with Aurelia - less to get confused about! And I agree about the Gitter channel being very friendly.

Re: Angular 2 Final Released

#434

Before you consider Angular 2, do yourself a favor and check out http://aurelia.io . Compare the differences and consider the trade offs with complexity vs simplicity. It's worth a consideration.

Please! The more of you that join us in Aurelia the better it will be, and I think the Angular community will benefit as well because at least they would become aware of some more best practices they could use to improve Angular.

Re: Angular 2 Final Released

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

Solid list. Having just used Angular 2 on a side project, I'd also add that I'm not the biggest fan of passing properties between components. @Input and @Output don't seem particular intuitive nor necessary, but maybe I'm just used to React.

I felt like I was writing really bad code passing stuff around like this. My project became ugly to look at, even though it worked. This was in February and I'm hoping that either better docs will prevent this from happening to me again or maybe that some changes they made in the 7 months since fixed all that.

I dread to go look at that code...

Re: Angular 2 Final Released

#436
post #377

Earlier quoted context omitted.

And the performance of all those is just garbage in Firefox on a 3 yr old laptop and isn't that much better on mobile. They're fantastic for forcing people to buy new hardware just to look at information :|

Well it must not be a very good 3 yr old laptop then? And firefox isn't exactly the slimmest or lightest web browser. Sucks ram just as bad as chrome used to. My 3 year old laptop can handle all of the google services just fine.

8gb RAM, great CPU. I'm playing counterstrike global offensive and civ 5 with very few problems. Lower FPS sure because the video card isn't great but it shouldn't be this bad. It was fairly decent in Win7.

Re: Angular 2 Final Released

#437
post #374

Earlier quoted context omitted.

at my last job we did a gradual migration from Angular 1 to React. Its similar to the path to Angular 2 really. React and Angular can live side by side... All we did was build an Angular directive that can render a react component in a subtree (that's easy), and a React component that could render an Angular directive (that's a little harder, but not that bad). With that, we could put a React component anywhere in ou…

Would you mind sharing the code for this?

I wanted to open source it at the time...then my employer had layoffs :)

The "React component inside of Angular directive" is fairly trivial and there's a million examples on the net. Just make a directive that calls ReactDOM.render on the element in the link function.

Angular inside of a React component is harder to google for, namely because there's so much misinformation saying its impossible.

It ended up being a variation of the discussion here: https://github.com/ngReact/ngReact/issues/80

(The code in the example isn't quite there...and its been a very long time since I did it, so I don't quite remember the tweaks I had to make).

Re: Angular 2 Final Released

#438
post #383

Earlier quoted context omitted.

> I tried to stay very far away from Angular 1 since I found its documentation to be very low quality (probably a symptom of Angular 1 being poorly engineered as well). I haven't found either of these to be the case. Is your experience recent? If so, will you expand on it? I like Angular 1(.5) quite a bit, but I'd be interested to hear more about a different perspective.

In 2014 when I started using Angular, I could not make heads or tails out of the docs and went stright to 3rd party tutorials. Today, if I know what I need and just need to remember the syntax, I will go to the official docs, but if not, I search elsewhere. I still don't think it's suited for learning.

I had the same reaction. What made it worse for me was that there was no "standard" way of doing things so different third-party tutorials would take different approaches. There was nothing I could find that suggested what the team would recommend how to approach different things.

Other libraries and frameworks have multiple ways of doing things but most times the documentation would provide an example that could be considered the way to do things.

Re: Angular 2 Final Released

#439

Earlier quoted context omitted.

How does such a service have inherent data flow problems? Especially since the NgbModal service IS built on a component that implements pretty much the same thing as react-bootstrap's Modal.

It uses components, it is not built on a component - the goal is for it to be able to manage multiple modals and some situations that are impossible to do right with component-based modals such as reusing a backdrop (I argue that multiple modals is a bad pattern, but it is a high demand user feature). It also allows flexibility into hooking into the lifecycle in the future with knowing when the modal renders, starts…

I think we are talking about different things.

Yes, if you build a component based api that supports multiple modals, resuing backdrops, lifecycle hooks, that api would suck and be a real pain to build a service version on top of.

A React component should not be trying to do all that, but merely produce the appropriate HTML for a modal dialog. That produced HTML can equally be used to build one-off "are you sure?" dialogs, a modal service, or what have you.

Re: Angular 2 Final Released

#440
post #307

Earlier quoted context omitted.

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

we can do both. In JIT mode, we XHR for them and compile them on the fly. In AOT mode, we do that at build time and turn the templates into TS code, which we can then typecheck (thus giving you typechecking against templates) - the benefit of this is you don't have to ship the compiler code to the browser, don't pay the cost of runtime compilation, and the generated code is monomorphic and thus highly optimizable in…

Oh cool, sounds similar to what Ember is doing with it's glimmer engine. Are you guys compiling it down to dom api, like htmlbars did? or something similar to a VM style runtime like in Ember's Glimmer 2, where templates are compiled down to a series of opcodes? Or something entirely different from those approaches?
Post reply on HN