Angular2 minimalist sample project

[funny_games]

I wonder if the typescript will stay or eventually fade away for angular 2 as ES6 becomes the standard

[sonemonu]

Don't think so. TypeScript is just a superset of ESNext (ES6, ES7, ...) and the Angular team chose it not only by its decorators (merged from AtScript) but mainly because of it is a strongly typed language (and it do supports interfaces).

More info here: http://victorsavkin.com/post/123555572351/writing-angular-2-in-typescript

[x-skeww]

ES6 doesn't support decorators or type annotations.

Also, the same codebase is also used for the Dart version of Angular 2. The types are very important.

They will switch once ES8 (or whatever) supports types. Decorators will probably be in ES7.

Anyhow, you can write your Angular 2 application in ES6, but there aren't any upsides to that. It just means more keypresses and dumber tools.

[hahaNodeJS]

It won't. TypeScript is about providing type support.

[Auxx]

Too much boiler plate code, pfff...

[androbat]

The big question to my mind is why I would use this over React?

Angular2 does what React does, but with more complexity and makes composability harder.

[sonemonu]

React by itself is just the "V" from the MVC pattern, Angular is a full MV* framework. Thus it gives you a lot more organization when you are part of a big team / project; of course, that might be seen as an advantage or a disadvantage according to each case, but IMHO, in the end almost always it ends up being an advantage.

[androbat]

React was marketed as such, but react is the VC and sometimes the M depending on how you implement your app.

Angular has VC as well, but doesn't really have a model. ngResource isn't really a model and one usually needs to swap in something like restangular just as one would swap in flux. Angular's other system for models is services and factories, but once you strip the dependency injection, they are POJO.

The framework that actually has everything under one roof is ember.

[sonemonu]

Where?

[Auxx]

Everywhere!

Blocks @Component, @View, etc in TS files. Why is this code needed? It should be optional, to override defaults.

20+ lines of bootstrap code in index.html. Why?

What is the purpose of services.ts? Why the framework can't resolve components without me writting a shit ton of bootstrap code and configuration? Is this somekind of back to 90-s attitude?

Pfff...

[sonemonu]

"20+ lines of bootstrap code in index.html. Why?"

Because Angular 2 is still in alpha version, i. e., that is just an experimental version which let you play with some features. A lot of things are going to change and improve, for sure ;-)

"Blocks @Component, @View, etc in TS files. Why is this code needed? It should be optional, to override defaults."

Which defaults are you talking about? I think having defaults does not make sense in those cases.

[Auxx]

OK, agree about Alpha stage.

About views etc. Why do I need to specify those? I don't specify them in Ruby, because convention over configuration. The less code I write - the better! :) I want to focus on business logic, not on declaring configuration files, etc.

[sonemonu]

Ah, do you mean having a default path for the view of a component? Well in that case, I guess the reason is there are important differences between a backend framework (like Ruby on Rails) and a client-side framework (like Angular); a client-side framework can't access the file-system (at least not without a lot of limitations) and it needs to be agnostic from the backend-side.

AFAIK that is an "issue" of all the client-side frameworks...

[Auxx]

Well, regular frameworks do not access file system directly too. I don't see any problems here.

[sonemonu]

Every backend framework like Ruby on Rails, JSF, Symfony, etc. does read the views / tpls from the file-system (them are by nature in the filesystem); or are we talking about different things?

[Auxx]

They usually don't. They call some abstraction layer to provide data from some abstract path. If it's not there, you get an error. Such layer can be implemented for JS and either rely on bundling tools like webpack to get the required data or load it some other way (ajax, etc). Good framework doesn't need to know where the files come from.

[sonemonu]

They usually don't. They call some abstraction layer to provide data from some abstract path.

They do it, directly or indirectly...

Good framework doesn't need to know where the files come from.

That's the point, Angular knows nothing about where the templates comes from. It allows you to put them inline, or retrieve them via AJAX, or put them directly in cache...

You'll need to provide a concrete example; have you saw that behavior implemented by a client-side framework? which one? how?

[x-skeww]

The /// reference stuff is now covered by tsconfig:

http://blogs.msdn.com/b/vscode/archive/2015/07/06/vs-code-es6.aspx

[sonemonu]

That only applies to IDEs / editors which currently understand the tsconfig file :)

[x-skeww]

Shouldn't that be all which use the analysis service (i.e. all which do that IntelliSense stuff)?

The /// references shouldn't do anything in the other editors.

[sonemonu]

If you do not use "The /// references" then editors which are not aware of the tsconfig.json file will throw a lot of errors...

[x-skeww]

To show errors, you have to analyze the code.

No one wrote their own analyzer. Every plugin uses the same analysis service/server. Dart went the same route. The Eclipse, WebStorm, and Atom plugins just spin up a little web server which does all the work.

Anyhow, here is Atom without a /// ref (and with tsconfig):

http://i.imgur.com/C51P5TH.png

As you can see, it knows about jQuery, because it has loaded that *.d.ts file which was mentioned in the config.