Angular 2 – Best Practises
blog.budacode.com
blog.budacode.com
I'm still disappointed that Angular 2 is such a sharp departure from Angular 1 and certain aspects of Angular 2 development, e.g. the fact there is still multiple CLIs, the fact that "compiling to Dart" is still a thing, and the fact that it's still unreleased give me no confidence to build anything in Angular. I can't help but feel that with any library, less is more, and that Angular 2 is already trying to do way too much. IMO Angular 2 should be a Typescript-only library with one CLI and one way to manage your files (among other changes made in the name of simplicity).
All this being said, I hope I'm terribly terribly wrong, and Angular 2 becomes the super-simple-way-to-create-great-UIs that the authors intended that the whole community can follow along. This article however, made me ask myself if that will ever happen.
I know these tools don't keep your code organized, but it doesn't prevent you from organizing it either. And I really do hate all the levels of indirection the monolithic SPA frameworks seem to throw in your face.
PathJS: https://github.com/mtrpcic/pathjs
Jadeify: https://github.com/domenic/jadeify
Smoothstate: https://github.com/miguel-perez/smoothState.js
You can see how i used it at http://zviwaldman.com when you click any link.
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...
https://www.google.com/trends/explore#q=angular%20tutorial%2...
I made a conscious switch from Angular to React because React (and the flux pattern) really did reinvent how web components are built and it's incredibly intuitive. I simply don't see the same innovation in Angular 2 apart from 'we made Angular more modern'
It's written in TypeScript, so you can write your frontend in TypeScript. Many bugs averted.
You can use a real reactive model (http://victorsavkin.com/post/137821436516/managing-state-in-...)
For a number of reasons:
- In general Java and C# programmers like it.
- It is made by Google (perceived as more "mature", business like) rather than Facebook (young kids).
- It takes a lot of inspiration from server side development with its dependency injection and general terminology.
- And TypeScript is very similar to Java and C#.
(The list is a slight caricature but I hope the general point is clear.)
React has been around for a while, but it is still only a library. Angular 1 and 2 are frameworks. Also Angular 2 is a complete rewrite and not even in final release. I'm not sure how that is boring or old.
As with Angular 1, Angular 2 aims to be opinionated, so it should be clearer how to do things than with React. Especially now with the move to components, Angular should be easier do more with, without as much confusion. And Angular 2 is much faster, if you do it right, which was one of the reasons Angular 1 was left for React.
React is fine for what it is. It's somewhat "matured" for a few years and is not a bad decision if you go with it.
I don't think that you should just jump on the latest JS bandwagon, but Angular 2 is more than just "for mature companies" and "similar to Java and C#".
Really, the only frustration we've had with Angular 2 so far has been that it has been changing so quickly, but it's starting to settle down now.
Where the sound is the promise of a better tomorrow without actually looking at alternatives.
You probably knew this already, but worth to point out that React never intended to be a framework.
This is a really interesting talk: http://2014.jsconf.eu/speakers/sebastian-markbage-minimal-ap...
react and typescript go hand in hand, now that typescript has .jsx support (as .tsx files)
React offers ability to use same code on server side and client side. Easier to test a Vdom library. It's a lot less complex, it's perf is a lot better, you can live edit. The biggest selling point is you can create native apps using native ui with a lot of code re-use.
React + ts definitely give you a bigger bang for buck. I spent 2.5 years of my life writing angular code. It definitely has some good ideas but I won't be investing so much of my time in angular 2 anymore.
Both ecosystems are vibrant enough to stay for the foreseeable future.
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.
The performance difference and development experience (no silly css hacks) is very noticeable.
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.
Just to be clear, Ionic is _not_ native.
Single Page Apps (SPAs) are more app-like than webpage-like and if you're really going for reusability then your components need to have a say in how they are rendered. That means they need to provide /some/ HTML.
You can still create components without including CSS but you'll likely need to provide structure (HTML) in order to bind behavior/callbacks/events to it. It's still good practice to separate rendering (HTML/JSX/NG) and behavior.
Please stop wars "a vs r" - it's counterproductive. Knowledge sharing is much better. If you don't trust me - read Twitter of Dan Abramov.
IMO there is one main reason to choose Angular 2 over React currently - perf. Angular 2 has significant perf improvements over the other libraries/frameworks out there, and supports incremental rendering as opposed to React's render all at once model. Angular 2 also will have the best built-in animation support of the various libraries/frameworks out there, in part due to the Angular team's collaboration with the Chrome team (this is true with Angular 1 as well).
Otherwise, React is more mature than Angular 2 & has a simpler API. Conceptually, Angular 2 and React share much in common, and architectures should look similar between well written apps in both.
Not arguing that you are wrong, I just haven't kept up with any of Angular 2 and am genuinely curios.
It also supports the shadow DOM through its style engine with the component decorator. One can either use native shadow DOM (and use a polyfill for the functionality), or use Angular 2's built-in virtual shadow DOM where it randomly generates unique attributes to style off of with the component decorator.
I've despised angular since pre-1.0, mainly for performance reasons. Once the number of watchers hits 1000 or so, a browser will noticeably lag. A compete rerender will cause a noticeable freeze up.
I'm not currently using react either, but it's possible to do an incremental render through code, only rendering what needs rendering. React-dom will be needed to plug the result in the right spot.
The general tooling process is pretty simple, no need to convince people of the merits of JSX.
Architecturally speaking many people still like separating presentation from business logic.
Angular has a lot of mature tooling and wrappings around current libraries. Angular also offers a lot more tooling on the side, React is much smaller.
On an architectural side, while React keeps states in components, the state update mechanism is a bit obtuse compared to Angular's "scopes are just objects" philosophy.
It's dependent on how you view things, but if you're working on things where strict component decomposition is hard, and you "like global state in your views", then Angular's state mechanism (controllers) could work better for you.
Some would also declare that the non-turing-complete-ness of the template language in Angular is a feature, not a bug.
I would argue that a distinction that you make yourself, based on your application's architecture is more meaningful and useful than one made by some arbitrary separation of source file formats.
"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.
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 immutability, unidirectional data flow, centralized state, etc. that ends up very similar to the React ecosystem conceptually.
Both allow native cross-platform mobile with React Native (react) and NativeScript (angular2), and Angular 2 also gives you a nice hybrid/webview option with Ionic 2. Angular 2 also gives you a bit tighter integration with TypeScript, if that is your preference (which it is mine).
Personally, for me, I like both a lot but the full-framework and tight TypeScript integration fit my use cases and personality better.
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 shows. Also nobody uses flow outside of React unlike TS which has a decent community even outside of Angular and plenty of 3rd party type definitions.
We've converted all our node backends to typescript. It's been a game-changer in productivity.
anyway, does typescript support some kind of template-string validation for angular2? If so, I'm going to really re-consider angular2 for my next project
No, and that's the reason I mention jsx as a missing feature from Angular 2. There is no compile time or refactoring support for templates, whereas with TypeScript and jsx you get that.
See https://github.com/microsoft/typescript/issues/6508 (and the GIF!)
Or simply put. If they named "Angular 2" by its real name "Some other cool framework name" - you would not use it. (e.g. Polymer 2)
And there is first class support for component-scoped css, aka emulated shadow dom, which is great for large codebases.
I also just don't like the over use of non standard features like decorators. There is a chance they don't make it to the spec, what then ?
Meh, I don't see how this is a bad thing. We need some more software engineering in the javascript space instead of cowboy hacking.
Are you saying that the ability to write entreprise java code is what separates "software engineers" from "cowboy hackers" ? That statement is arrogant.
My point is the use of Typescript doesn't produce idiomatic Javascript code, since it encourages writing front-end code a certain way. You might like it, fine, I'm personally not willing to deal with that kind of over engineering blessed in the Java world, I know what it leads to. If this approach was really successful everybody would be using JWT by now. Obviously they don't.
I'm saying that software engineering doesn't need to be simple, it needs to be solid. I think type safety is one of those features that makes a language more solid.
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 classes all over, rely on private/protected/public like crazy to make complicated domain models, abuse decorators to hell, enums, etc... then it's C# for the web.
It doesn't have to be used that way, but those features made available and having a high focus in the official doc is causing a lot of issues when people coming from Java/C# hop in a TypeScript code base.
We don't use TS here, but when we hire people who come from TS companies, we have to tie them down for them not to start writing C#-like code, and remind them that it's structural typing, etc.
The visibility modifiers are optional, only checked at compile time, and quite frankly solve a problem that JS developers have been solving badly for a decade now. From "gentlemen's privates" (ie, if it starts with an underscore please don't touch it or rely on it!), to closures to CommonJS modules, all ridiculous contraptions essentially designed to give you some sense of privacy in the language.
TypeScript doesn't have enums. Instead it allows you to restrict a string to a finite set of values. Which basically boils down to JavaScript "enums" with a dash of static typing thrown in.
I have no doubt TypeScript tends to attract C# and Java developers. But that doesn't take away from the fact that TypeScript is a proper superset of JavaScript, it doesn't force you into a rigid class system at all (structural typing for the win), and really, truly is "JavaScript with types".
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.
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.
I does matter as there is difference between introducing type support in a language and introducing features that completely are non standard. Now imagine TC39 introduces a decorator syntax that is not compatible with Typescript's implementation ( it happened in the past with previous Typescript module syntax and the language had to break compatibility )
Angular 2 is completely based on the use of decorators to inject almost anything. Sometimes the decorator definition itself is bigger than the class using it.
Hmm. I thought that they just deprecated the old syntax while maintaining backwards compatibility.
1. It has effortless two way binding, which makes apps that allow mutating the same state from a lot of places easy and simple to make (though one could argue harder to maintain)
2. It uses a template rather then a precompiler (such as jsx) which has two advatages- since its html it makes cooperating with designers and the design process itself easier and it means you can use strings for modularity (for example saving a templatr in the database etc.)
Edit: Why the downvote?
"We're still doing the framework, but we're improving our ability to handle different languages. Our plan is to have versions that will work with many server-side technologies, from Java to Python... We would like to work to make Angular future-proof. As we have new releases for Angular, it would be nice if we could give just an upgrade script, so on every release, it would be stress-free."
I have some experience on JSF but I suppose it is completely different.
Super nice IMO
"This chapter is not yet available in JavaScript. We recommend reading the TypeScript version."
For example, my current company screwed itself by using a fork of UI Grid, and thus probably cannot upgrade the current app to Angular 2 easily.
It may get pretty confusing if you're not used to transpilation, too. For example, when you want to instrument your code for code coverage for your unit tests, you need to map that instrumented code and its results to your typescript files and not the es5 transpiled version of your code to see which lines are failing/not being run/whatever. There are good plugins, but there's definitely some effort involved.
People on my team are using Angular2 in their own projects and are claiming huge productivity gains. They love the relative simplicity and power.