Angular 2.0

[pensierinmusica]

According to Brad Green at ng-conf 2015

the first production Angular 2.0 app at Google will ship in May 2015.

Is there any timeline estimate to support Angular 2.0 in "generator-angular-fullstack"?

Considering the breaking changes, will there be a separate generator, or a user option during the initialization process?

Thanks!

[honkskillet]

The changes are so radical that I'm assuming that a separate MEAN stack generator will be made at some point. Alternatively, there has been talk about the next version of angular-fullstack being much more modular, possibly to the point were the front end and backend are really separate generators that work together. That would allow for a completely different from end implementations (even using a completely different framework like ember). I'm not really in the loop though. Maybe @daftmonk or someone in the know can comment.

[ericmdantas]

I believe it should, and most probably will, be a different generator.

Not only the changes are too big and diverse, but this generator is not much active as it once was.

By the way, I was thinking about working in a new generator, just for the new stuff:

• iojs;
• angular 2;
• express 4.12 + or koajs;
• gulp;
• lodash 3;
• MongoDB 3;
• and other brand new stuff.

[honkskillet]

@ericmdantas I like that list. What about jspm.io?

[honkskillet]

@pensierinmusica Also, there is seemingly really no "timeline" for anything on this repo right now. It is currently in a nice state and has a lot of user but not much recent activity. Pulls request seem to be stacking up.

[ericmdantas]

@honkskillet, never heard of it - gonna take a look later.

By the way, here's the repo I started to work on:

https://github.com/ericmdantas/generator-ng-fullstack

[pensierinmusica]

@DaftMonk and @btford thoughts?

[btford]

I'd probably consider starting with a fresh generator.

Was there any specific question you had?

[pensierinmusica]

No specific question, besides the one on top. Since @DaftMonk and @btford are two main contributors to this repo I thought it was relevant to know their opinion.

[dmarcelino]

One of the ideas that has been discussed in #801 is to separate client logic from server logic. Angular 2.0 would be a great motivation to kickstart that.

[pensierinmusica]

Would that be different from, let's say, have two folders?

For example:

• /client made with "generator-angular"
• /server made with "generator-express"

My feelings, and the thoughts I read across several comments in these projects, are that the more simple and modular a generator is, the easier it is to maintain.

So, the core of the discussion seems to be what the modular architecture could be, what is the best way to implement it, and what modules to start working on.

I imagine a basis going forward could be:

• Client (Angular)
• Server (Express or Koa)
• Authentication (Satellizer or Passport)

Another issue would be deciding whether CSS processing (SASS, Compass, LESS, Stylus), production build (compression, minification, concatenation, cdnify, etc.), and so on should be part of the "client" module, or sperated into their own sub-modules that can be coupled together.

The same could apply for different DB options on the server side: should they be part of the server generator, or data models can be treated as separate sub-modules? This way one "server" generator could be coupled with different DB and ORM sub-generators supporting, let's say, PostgreSQL, MongoDB, MySQL, RethinkDB, Redis, and so on... depending on the project needs.

Thoughts?

@DaftMonk @btford @ericmdantas @honkskillet @dancancro @JaKXz

[dmarcelino]

I'm working on a project (private) where I stripped mongoose out and replaced it with waterline so, from my part, I would also like to see the ORM, models and related being abstracted into separate projects. But that's something that can probably be abstracted within the server side generator(s) and not exposed to the parent generator.

[ericmdantas]

While I do agree that having these 'already made generator' inside a bigger generator is a good idea, I have my doubts about the wiring with each generator and the consistency between them.

But it's definetely something to be taken into consideration - not reiventing the wheel with a huge generator to rule and rewrite them all.

What we could do to visualize it better, would be to draw the tree of components/folder structure and see what we can do from there - as far as separation of logic/generator goes.

[kosz]

still some moving parts with Angular 2.0 I feel. Looking through their Angular 2.0 site things seem to be a bit out of sync, since ATScript is mentioned in a few places, yet they announced it will be replaced with TypeScript.

I myself dodged the bullet there with my generator, since I was going to spend time on adding an ATScript option to it.

[ericmdantas]

@kosz, yup.

They said themselves not to go much further than a Todo App, because things might still change drastically.

And I'm not entirely sold with TypeScript. I mean, seems nice and all, but there's a lot of things from ES6 they're missing (last time I checked, at least).

Edit:

Looks like they're still a bit behind: https://kangax.github.io/compat-table/es6/

[Awk34]

My opinion for separation of server & client is to keep the project as a full stack project. The generator will ask you for three sub-generator options: Full-stack (both), Client App, or Server App. That way you can only generate one part of the stack if you wish.

[Awk34]

@ericmdantas https://www.youtube.com/watch?v=Xw93oketp18&list=PLOETEcp3DkCoNnlhE-7fovYvqwVPrRiY7&t=856

[ericmdantas]

@Awk34, yeah, I watched that.

For now, I'm using babel and I'm really liking it. But I'll definetely give it a try to TypeScript once version 1.5+ is out.

Looks like they're being very active, by the way.

[Toub]

@ericmdantas @btford if you start a new project, please think first about how to avoid the current situation with DaftMonk generator.

@DaftMonk works very hard on this great project until one day he is not available anymore, so the project is now died.

One of the success key is surely to decouple client and server, but maybe also other components (e.g. look at this suggestion about decoupling authentification: https://github.com/DaftMonk/generator-angular-fullstack/issues/885).

An other key is to start from scratch with a collaborative project. At least 3 or 4 people and more discussions about the design. It is harder and need more time but it can guaranty a better maintenance then.

Think also about documentation to try to get more people involved in pull requests (users are also developers).

[Toub]

By the way, is it really a good idea to restart from scratch? Why don't proceed step by step so the current generator can share the server code?

e.g.:

• decouple client & server generators
• server: upgrade express & mongo (so current generator can use the last versions of theses)
• client: fork the current client and upgrade to angular 2.0
• extract authentication to a new yeoman generator
• ...

Upgrading to gulp is a must-have but is not a high priority.

[remicastaing]

And before starting, please, define a list of features the generator should have. But not to many. The project would be to hard to maintain.

A least, choose the features I need. ;)

[ericmdantas]

@Toub and @remicastaing: I've started from scratch aiming for my needs - since I am the only one using it and commiting stuff, but of course there's a lot we can adapt so we can cover a bit more ground without trying to cover it all (which would make a huge, unmaintanable generator).

As for angular 2.0, I don't know it's time to have a generator for it yet. If you check their repo, there are still major renaming and design decisions taking place, so I'm going with angular 1.4 for now.

As for the decoupling, @dancancro (and others) have been doing these discussions about how to do it the better way, as far as listening to what the user (developer) needs and the end user (client) also needs. It's been a great talk, worth watching it and bringing your own point of view.

[khwerhahn]

Hi,

since Angular 2 isn't finalised (and best practises not clear) yet and too many changes might affect a generator being build right now, I would probably take the time to maybe plan the project a bit more and stick to a clear roadmap of features so that it is clear for everyone where the journey will go and that more people can contribute more effectively to the project.

Why don't we start a trello board with a backlog of all the features, then discuss the core layout of what the project should look like and also start voting for features that should be included. I think naturally with a lot of people having an interest in this project, there will be an endless amount of features that should be included. It will be impossible to include everyone's wishes.

Maybe it would be a good idea if we just supported a core generator to start a project and building/deploying and then use other generators to support different needs. I'm thinking for example the use of mongoDB or an ORM like Sequelize.js. Someone might want to use bootstrap and someone might rather want to use Angular Material. Many of these projects have their own (best practise) generators. So instead of building a huge monolith generator, just stick to the minimum everyone needs and then support external generators. Just an idea.

What I'm trying to say is that in order for this project not to depend on one person, it would be nice if there was a more organised collaboration so that the project is a distributed effort. This needs structure though and investing in this would definitely pay off in the long run.

Suggested collaboration tools: Slack (communication and integrating 3rd party tools - git, trello, etc.) Trello - Backlog of features

[Toub]

@ericmdantas @khwerhahn I agree about Angular 2.0. I did not say that we should start that project now ; I said that if anybody want to start a rewrite (with or without angular 2.0, we should consider some points before to go).

I like the idea to start with a very minimal generator, without any dependency to angular nor express, with just the tools. This would be a good base yeoman generator starter for any yeoman project. As there are also a lot of yeoman generators, we should consider to fork one of them (daftmonk, jhipster, angular-gulp...) and remove all the non necessary stuff (or get inspired by one of them).

But I am still not convinced about the best approach between:

• start from scratch a new project
• fork and split the current project into sub-projects

The advantage of the last is that it does not requires a lot of effort to have a first release.

[Toub]

By the way, @ericmdantas what is the status of https://github.com/ericmdantas/generator-ng-fullstack ?

[dmarcelino]

I'm more inclined towards the 2nd option:

fork and split the current project into sub-projects

That way we can benefit from the lessons learned during the development of the generator. If I'm not mistaken @kingcody already has a branch where he divided the Gruntfile between client/server. That can be a great starting point for the split between client and server.

[Toub]

@dmarcelino I agree, what about using load-grunt-config to split the Gruntfile config by task?

Example: https://github.com/tombatossals/angular-openlayers-directive/tree/master/grunt

[ericmdantas]

@Toub, it's working. There's a bit of refactoring here and there, but I'm already using it for my own purposes. I mean, it's simpler than this one, but it's more straightforward - at least for what I need right now.

It's based on most options from the command line, you only answer two questions:

• What's you github username;
• What's the name of your app.

From there, you'll just create stuff doing:

$ yo ng-fullstack:controller user --feature user

I think it's better that way, but I'm open for suggestions.

As for development goes, I'm stuck trying to get the development of the subgenerators with the babel transpiler, gotta figure out the extends and inherits so it'll work with ESNext (es6, es7~) stuff.

Even though 1.4 is still in beta-like mode, I'm currently using it as the angular version (which has the idea of components, new router, and things like that).

@khwerhahn, I agree that sounds like the best option (having one generator to rule smaller ones), but I'm afraid we might have an infinity of options and cases where these things might be hard to keep track and suchs - but we'll never know until we try, or see someone who has already done it.

[khwerhahn]

Maybe it would be a good start to gather other generator projects and look at them and do some research. Then we find the best suitable one and "support" this generator.

I think it would be more suitable to build a best practise generator for a angular 2 project with best practises for the client and server side (ie. express) and then support certain generators who follow a "best practise pattern".

So you pick the things you want to use on your client and server side and the generator bootstraps your project and then installs also the supported generators for the choices you have made. Then we add best practise testing and deployment support. I know this is easier said then done, but maybe one could work closer together with other generator projects. I think everyone would benefit from it.

So we need to agree on a few "core" things we want to use (i.e. grunt or gulp) and then stick to the basics every project needs (boilerplate (front-end/backend),testing,deployment).

@ericmdantas @Toub

[ericmdantas]

@khwerhahn, I agree with pretty much what you said. But I'd say there are some traps we could fall in, like:

• What would happen if we want to have generator-x to help us, but generator-x is not being used anymore, because the owner, for whatever reason, doesn't want to do it anymore? We'd fork it, and make it our own. Make that with more 3 generators and this gets out of hand.
• The thing about "you should either use gulp or find another generator - we don't work with grunt" (or vice versa) - same goes for koa/express, nodejs/iojs, traceur/typescript/babel, etc - is great for us who are developing (less things to maintain), but it'd suck for the developers who were willing to use the full generator, but want one and not the other.
• How does it all fits together? That's the big question for me. Because now we'd have to worry about our generator managing these others - which is great - but we'd have to worry about the breaking changes these 'sub' generators could have - or even the lack of commits. They don't necessarily care about us, they're a generator for their own users.

In short, the bad reason to have a generator do it all is the same code being shattered in different generators. And the good reason, is to have total control of what is inside of you generator and how it behaves. Maybe we could find a middle ground.

[khwerhahn]

@ericmdantas I know what you mean and that there is a certain risk I completely agree also, but when we go for mainstream projects like an angular 2 generator or an express generator I don't think that the risk is that high. The problem with this project right now is, that it is more or less maintained by one person.

There will have to be core decisions I think, but what would be awesome is that if we use mainstream gens, we could focus on the basics, like a boilerplate generator with deployment capabilities.

[dancancro]

@khwerhahn Grüßen aus Berlin!

If you haven't seen this yet, it might be worth a look. It will show you which starters provide which benefits including those you've mentioned.

I've tried to make it as easy as possible to see the trade-offs between things. And I warmly welcome any help filling in the details about them. The more facts it has the more useful it will be.

I also agree that dependence on a single person makes the open source software development process really brittle.

I think you're the first Berliner I've seen on these lists too. Let me know if you want to meetup and chat about this stuff sometime or join the weekly google hangout.

[ericmdantas]

@khwerhahn, yeah, we'd solve a lot of problems if we had an organization to take care of it. By doing so we'd make our own team to commit, review and fix stuff. I think that's the way to go.

If that happens, you can count on me.

[khwerhahn]

@dancancro Grüße zurück!

It would be nice to know who would be interested to support a new project. If a core team has gotten together, then it would be easier to start.

[remicastaing]

Then, let's use the momentum and start! ;)

Grüße aus Frankreich!

[honkskillet]

There is a new generator generator-ng-fullstack that might be worth checking out. @ericmdantas is leading it. It is a newest version of angular full stack generator, which (I think) means as soon as angular 2.0 comes out that will be the version used. https://github.com/ericmdantas/generator-ng-fullstack

[ericmdantas]

@honkskillet:

It is a newest version of angular full stack generator, which (I think) means as soon as angular 2.0 comes out that will be the version used.

Pretty much.

If you feel like it, I could create an organization and make it available for a core team.

[khwerhahn]

@ericmdantas very nice, but sequelize is missing ;)

[honkskillet]

@ericmdantas I think an org is a great idea.

[khwerhahn]

@honkskillet @ericmdantas sign me up

[khwerhahn]

https://github.com/timjacobi/angular2-education

[remicastaing]

I would be happy to contribute for the email functionnalities (account confirmation, forgotten password, etc. )

[dmarcelino]

Count me in. I would like to try extending it to use waterline multi-adapter ORM.

[Toub]

I won't have much time to invest but should be able to provide small contributions.

[ericmdantas]

Sounds great, guys! I'll do it later today and I'll let you know!

Just created an issue on my generator to move things forward.

Thanks for the links by the way, @dmarcelino and @khwerhahn.

[kingcody]

If I'm not mistaken @kingcody already has a branch where he divided the Gruntfile between client/server.

That is correct, let me know if you'd like any help merging stuff in.

[pensierinmusica]

Awesome guys, looks like this is moving in the right direction! I'll be happy to contribute too, compatibly with other work commitments :)

[Awk34]

1869