Angular 2 Style Guide
angular.io
angular.io
React is great as well, but if you find Angular incomprehensible it's not clear you'll find React much easier.
One major difference between React and Angular is that the Angular community _tends_ to separate their templates from their "controller" code, whereas the React community _tends_ to intermix their templates with code ("PHP" style).
The result is that in Angular you have a few funny characters in your HTML to learn (e.g. `*ngFor="let foo in bar"` for looping) whereas in React you'll use JSX and use JavaScript for loops.
It's pretty clear to me that component-based webapps are here for the long haul. Even if WebComponents ends up being the future, the concepts you learn in using either Angular or React will be more-or-less transferrable.
It seems to me that Angular and React are becoming more similar over time. For typing, Angular uses TypeScript and React uses Flow. For data architecture, both communities are gravitating towards some sort of Flux (redux / ngrx). You can even use JSX in Angular if you want to.
Shameless plug: I've written a book on Angular 2 which talks through, step-by-step, how to understand Angular. The first chapter walks you through your first app and you can get it (for free) here: https://www.ng-book.com/2/
Because you can't practically use web components. Only Chrome and Opera support them. Angular2 has support down to IE 9.
Which is why I stopped messing around with polymer. Basically adding the webcomponents polyfill to your DOM tree (because it touches so many things) breaks contenteditable in some weird ways. Which can be limiting to people who use rich text editors (many still decorate contenteditable divs) although iframe-wrapping the editor fixes the contenteditable breakage (at the expense of introducing other problems with extending your editor - try adding custom (say) atmention autocompletes to something in its own execution context).
Also, webcomponents have had some pretty major syntax changes over time, especially when it comes to shadow-piercing styling vs other styling selectors.
Ultimately, I'm looking forward to webcomponents. I can't wait to have proper namespaces and all that. In the short run, though, I've tried the webcomponents polyfill (I wrote a lot of polymer 0.X code for a webapp that I eventually ported to angular 1.x instead when the polymer 1.x syntax meant I'd have to rewrite a lot anyway), and it's not Enough.
And you'll get started in no time, no need for nodejs and zillion packages from npm, or even a cli tool and what not.
it's one file you drop into your html page. Vue.js explains clearly how you should build a Vue application and is honest about its potential limitations. There is no surprise nor magics. No IoC container forced on you if you're not into that kind of voodoo.
React is good too, I recommend either of them. I'd have recommended you Angular 1 3 years ago, now I can't, I have no idea if they'll stop developing that version at some point in time.
Did I just compare Angular 2 to Perl 6?
Alas, Angular 2 is threatening to actually roll out sooner rather than later.
Just start building stuff in it. Start with Hello World or something else ridiculously simple. If it doesn't work, then debug and fix it until it does. If it works, then add some features until it stops working, then fix it. Repeat until it does something useful. Find some demo apps and examine them to give you some direction on how to do things. Work through any tutorials you find.
Angular 1 seems like a good starting place to me. It has some complexities, but it's one file to use and is all bare Javascript. You can at least get something simple working before you have to figure out how to set up build pipelines for Typescript or JSX or something. You can even do some useful stuff in it with no Javascript at all - the default form validation stuff is pretty nice.
The biggest hangup people seem to have at first is JSX ("HTML") mixed in with JS, and I had that worry too but it vanished as I spent more time with React.
It's just the view layer, and just a library, which can be a pro or con, depending on what you want from it.
Oh, and the documentation, a part so often neglected or written in a style that's for CS professors instead of mere mortals, is extensive, clearly written and full of examples. Lovely!
> Request javascript version
"This chapter is not yet available in JavaScript. We recommend reading the TypeScript version."
LOL
Angular2 is a framework build for Typescript and Dart, barely for Javascript and certainly not for ES5.
I can understand that it feels strange, especially to someone who has had little exposure to languages outside of Javascript. However it is very much worth investing the time in learning it.
15 years ago I was making the same argument to Visual Basic developers about C#..
It's a shame too, I was a pretty big Angular fan. I used Angular, Ember, and even React and for several reasons I ended up settling on Angular as my favorite SPA framework (back in 2014 and 2015). Back when they announced Angular 2.0 would be TypeScript based, I felt like it was a mistake and that feeling has only gotten stronger as TypeScript has continued to fall behind EMCAScript (http://kangax.github.io/compat-table/es6/).
If TypeScript adopts compilation down to WebAssembly, that would be a reason to learn it/give Angular 2.0 a chance for me, but until then I will stick to Angular 1.0 or move towards React for my next project...which is a shame because I really don't like Reacts focus on the V of MVC. Maybe I will go back and check on Ember, but I wasn't a fan of it's tight binding of Models to Views (sometimes I just need a VC or a V and not a full MVC)...but maybe it has changed.
It can. Typescript is just optional information added to your Javascript. All Javascript is 100% compatible TypeScript. You can use TS extensions anywhere you like, your whole codebase, only certain function APIs, or nowhere at all.
My first job in the mid 80s was in a language with runtime typing. My experience is that "strong" (compile/parse time) typing is not the panacea that many say it is. I've seen far more damage caused by C style "operator precedence stew" issues (vs Lisp style all funcs w/ parens). It's like the Type Police have to punish us for the dark era of C/++ Play-dough Pumper byte molding the industry had to put itself through in the 90s.
In fact, I would much rather see a language that forced modules/data/functions to be flagged which were not immutable/idempotent (which should be an enforced default), rather than an even-trade-at-best static type feature. Yes, that means your "main" would be flagged as "dirty", so it could do I/O, but your library modules (lang; 3rd party; app) would mostly be pure functions.
Anyway, I much prefer dynamic (runtime) types and FP with an occasional dash of OOP style Javascript to the "Let's be like Java!" cult. As Douglas Crockford likes to say "Those people will go to their graves, never knowing how miserable they are". Ironic, considering how the coming holy grail of ADTs/Objects was beaten into us in Uni in the 80s, and FP all but ignored.
Oh, come on now. If JSX isn't necessary, then neither is TypeScript. Have you tried writing React components without JSX? Angular2 in ES5 is saner.
I get that neither is ideal, but let's be real here.
decorators are a TC39 proposal from Yehuda Katz and Jonathan Turner...
Angular 2 looks like a JEE "inspired" nightmare.
Turned out, that was a nuisance.
TIA
There are plenty of ES5 frameworks out there - the biggest value proposition Angular 2 brings for me is that it's built with typescript from the start and it leverages all of it's features (ie. modern OO tooling that comes with languages like C# and a language that feels familiar to C#/Java devs) and builds a GUI framework on top of it that works in the browser.
Without being native TS Angular 2 would have very low appeal to me.
For us, "being like Java" is not a plus. My IDE already does a pretty good job at type inference while I am editing, as well as displaying the comments about each symbol as I click on it.
Anyways - it seems like a set of reasonable conventions; Java/C# programmers should feel right at home.
The only thing that sticks out is the file name convention. If you only have one thing pr. class then why not use name as it is directly in the file name? (HeroComponent.ts instead of hero.component.ts)
Having worked on various teams (now we follow https://github.com/johnpapa/angular-styleguide), its truly a maintenance nightmare without a verbose Angular style guide for reference.
He is in charge of the Angular 2 style guide too. I bet he will do a good job with this one too.
Use some style guide as a base and then agree on your own internal exceptions/additions as a team, then just implement those rules, and eslint can let you know when you've forgotten something.
Personally, I find the editor (via Syntastic in vim) integration most helpful since it's more of a warning and not an overbearing release gate.
> Consider naming an interface without an I prefix.
They give the same recommendation in the Typescript style guide, but I still don't understand why.
You shouldn't need to know whether the client is using an interface or an implementation class. List represents a list, and a User represents a user - not an IUser. Another problem with using I, is that (oddly) we use it to communication the implementation decision of using an interface. Usually we don't want implementation decisions expressed so loudly, because that makes them hard to change.
[0]http://programmers.stackexchange.com/questions/117348/should...
[1]http://stackoverflow.com/questions/541912/interface-naming-i...
[2]http://stackoverflow.com/questions/5816951/prefixing-interfa...
[3]https://blogs.msdn.microsoft.com/brada/2004/02/03/why-do-int...
To me, it still seems more about people's gripe over the very existence of interfaces.
If anything, using IUser in lieu of User is a pretty clear signal to, say, an uninitiated developer, that you shouldn't be attempting to create an instance of "IUser."
if not, can i run angular2 in, say, nashorn to generate view data?
E.g. -
define( [ 'jQuery' ], function ( $ ) { ... return { ... } } )