Live data from Hacker News

Angular 2 – Best Practises

blog.budacode.com

81–90 of 94 posts

Re: Angular 2 – Best Practises

#81

After having gone around the SPA framework circuit, I'm back to using jQuery, routing with PathJS, and templating with Jade (compiled using a Browserify transform). It's just so much simpler to understand. No magic, and I have yet to run into any problems. If I needed more complex model stuff, maybe I would throw in Backbone. I know these tools don't keep your code organized, but it doesn't prevent you from organizin…

I'm eagerly awaiting a time when "the community" again allows this to be an acceptable alternative. Not that I wouldn't just go ahead and choose this.

Re: Angular 2 – Best Practises

#82
post #55

Earlier quoted context omitted.

One specific reason I am personally choosing Angular 2, is that the Ionic2 Framework also uses Angular 2 [0]. So I can re-use code from my front end website on my native mobile apps for the new startup I'm launching. Much less code = quicker time to MVP, and lower cost of development. [0] http://blog.ionic.io/angular-2-ionic/

> So I can re-use code from my front end website on my native mobile apps for the new startup I'm launching. Just to be clear, Ionic is _not_ native.

While Ionic's not native, even Ionic 1 is close enough for most apps. Ionic 2 is supposed to be 3-5 times faster. So for startups that need both iOS and Android support, but have small teams, Ionic's 100% iOS-Android code reuse remakes a lot of sense.

Re: Angular 2 – Best Practises

#83

Earlier quoted context omitted.

Essentially it boils down to whether you prefer a cohesive all-in-one framework/platform (angular2) or a collection of semi- and fully-independent libraries (react). Pretending that one of those options is the right fit for everyone is not productive. The only thing really missing from Angular 2 compared to the React ecosystem is jsx. Angular 2 and RxJS (and if you want throw in ngrx/store) allows a heavy focus on im…

I don't think JSX fits Angular 2 - it sticks to "views are markup based and code is in controller" traditional MVC which I prefer to JSX. You mentioned TS but I feel like you understated it - it's the selling point for me. I have used TS + React but it's not the same thing - Angular was written with/for TS and it uses it to leverage all the advantages. React migrated from ES5 to incrementally add ES6 support and it s…

> TS which has a decent community even outside of Angular

We've converted all our node backends to typescript. It's been a game-changer in productivity.

Re: Angular 2 – Best Practises

#85
When an article about Angular is posted here, It seems standard practice to ignore the article itself—in this case, a writeup of Angular 2 best practices. Instead it becomes a discussion on React vs Angular, Angular 1 vs 2, frameworks vs no frameworks, etc. I’m not sure how to fix this problem—and I see it as a problem because the article bears discussion. But even with this comment I’ve derailed the original poster’s intent. So: is there a similar forum where Angular-oriented articles are posted and the starting assumption is that Angular is, well, good?

Re: Angular 2 – Best Practises

#86
post #4

Could someone tell me one-or-more reasons to choose Angular for a new project, now that the React ecosystem is mature enough to compete with it? As I feel that from a conceptual/architectural point of view Angular is simply on a loosing path. https://www.google.com/trends/explore#q=angular%20tutorial%2...

I love the direct integration of async support in templates. You can extract the value of promises and observable directly in templates using the async pipe, which cuts down on a lot of boilerplate. That means your templates can directly subscribe to observables and auto update on changes. Awesome.

And there is first class support for component-scoped css, aka emulated shadow dom, which is great for large codebases.

Re: Angular 2 – Best Practises

#87
post #69
post #52

Earlier quoted context omitted.

It is C# for the web, of which a small subset is great and can be used to make "JavaScript with types". Or rather, TypeScript isn't bad, but the way it is documented might convince people to do bad things. It took forever to get "the good parts" of JavaScript in people's head, and that doc is really a step backward. If you just use TypeScript's types and run away with that though, it's pretty good. If you start using…

I have to disagree. For starters classes came from ES2015. They're an official, first class construct of JavaScript now, whether we like it or not. Decorators are also from ECMAScript. Whether people use TypeScript or not, a lot of what you're complaining about is coming regardless. The visibility modifiers are optional, only checked at compile time, and quite frankly solve a problem that JS developers have been solv…

Decorators aren't in EcmaScript yet. And the ES standard changed since they were implemented in TS (I honestly don't know if TS changed to accomodate or if they're just mismatched now).

TS sure as hell has something called "enum", which is NOT the same as their string literal types (those are good).

I disagree about the privates: closures are perfectly good functional ways of handling them, and if you didn't want that, we have symbols now to do it for "real". And privates aren't terrible. Protected however are OOP bullshit.

Though my primary point isn't in how its features are implemented: it's how they're advertised. That, to me, is what makes TypeScript "a C# for the web". It's implementation isn't terrible, especially if you stick to the "good parts". However, the "good parts" they advertise/encourages are javascript "bad parts.

Re: Angular 2 – Best Practises

#88
post #87
post #69

Earlier quoted context omitted.

I have to disagree. For starters classes came from ES2015. They're an official, first class construct of JavaScript now, whether we like it or not. Decorators are also from ECMAScript. Whether people use TypeScript or not, a lot of what you're complaining about is coming regardless. The visibility modifiers are optional, only checked at compile time, and quite frankly solve a problem that JS developers have been solv…

Decorators aren't in EcmaScript yet. And the ES standard changed since they were implemented in TS (I honestly don't know if TS changed to accomodate or if they're just mismatched now). TS sure as hell has something called "enum", which is NOT the same as their string literal types (those are good). I disagree about the privates: closures are perfectly good functional ways of handling them, and if you didn't want tha…

Ah you're right, I forgot about the numeric enums. I was thinking strictly string based.

I honestly think "protected" is not worth fussing over. Not to mention JS becomes more classically oriented every day. I predict ES2018 adds "protected" :)

Anyway I honestly don't have much opinion on how they are marketing TS. The language itself is well done and that's all I really care about.

Re: Angular 2 – Best Practises

#89
post #20

Earlier quoted context omitted.

Have you tried React with React Native[0]? [0] https://facebook.github.io/react-native/

In my experience code-share between React and React Native is extremely difficult as your UI code is so significantly different with native components and what not. At least with Angular/Ionic you can directly share UI code between the two as its all HTML and CSS. Still, I really enjoy working with React and React Native because I it's one API and mental model to learn.

You might want to check out https://github.com/necolas/react-native-web - that has implementations for a lot of the React Native primitives on the web, to make code-sharing easier.

Re: Angular 2 – Best Practises

#90
post #67

Earlier quoted context omitted.

You separate your presentation from your business logic in React. What React gives you that Angular doesn't is the ability to separate your presentational logic from your business logic. Angular makes you put presentational logic in with your business logic because presentational logic simply cannot be expressed with the templating format. I would argue that a distinction that you make yourself, based on your applica…

All the React stuff is starting to sound a bit to me like "MongoDB is web-scale"

Not really. I think a key distinction is summed up in this quote:

"Angular 2 continues to put “JS” into HTML. React puts “HTML” into JS."

See: https://medium.freecodecamp.com/angular-2-versus-react-there...

This influences to some extent what you can do with the frameworks and how your code is organized. I like the fact that since my rendering is essentially JS in React, then I can structure my code better with OO to solve problems (inheritance where appropriate, helper classes, patterns etc). In Angular, its just a awful mess of ng-* statements for flow of control. All you can really do to tame it is to use composition or to mix-in behavior via directives.

Post reply on HN