Future of generator-angular-fullstack & alternatives

[Toub]

Hi,

I loved to play with this awesome project for the last months and use it as default for my angular/node projects. However, as the project is maintained by only a few volunteers, it looks to be almost dead or at least very sleepy now. @DaftMonk (and others), do you have any serious plan to re-launch the project, or as I suppose, are you busy with something else?

Mean.js (https://github.com/meanjs/generator-meanjs) maintained by a single guy looks to suffer the sames difficulties, while Mean.io (https://github.com/linnovate/mean), maintained by Linnovate company, looks more active on github.

I guess that to maintain such a project, it need to be maintained by a real company. What are the alternatives?

Should we move to bigger projects such as Sails (https://github.com/balderdashy/sails) or Loopback (http://loopback.io) maintained by Strongloop?

[NielsGregers]

Hi Toub, @DaftMonk and other volunteers.

I am also loving this project, but I share Toub's concern

[ericmdantas]

+1

[hiroqn]

+1

This generator has many configurations like css or less or stylus etc (of course , its good thing) It makes this project difficult to maintain, I think

[Climax777]

I use this generator as a decent start for many production servers. I think it is a great lightweight start. The packages are a bit dated though.

On Wed, 28 Jan 2015, 12:53 hiroqn notifications@github.com wrote:

+1

This generator has many configurations like css or less or stylus etc (of course , its good thing) It makes this project difficult to maintain, I think

— Reply to this email directly or view it on GitHub https://github.com/DaftMonk/generator-angular-fullstack/issues/801#issuecomment-71815059 .

[kosz]

you guys could all contribute :)

[ericmdantas]

@kosz, yup, but it'd awesome to hear from its main commiters where this is going.

[dancancro]

Hi @Toub, effort is underway, albeit a little slowly, to unify the projects. Here is a collection of the alternatives that I know about. If you know any of them well and want to help improve its accuracy, I would welcome a hand maintaining it.

[dotch]

the main thing I like in this generator is, that ist relies on complete client side rendering and JWT as authentication method.

problems I see are: it has too many configuration options, which makes contributing and maintaining hard. many packages are outdated, which is a really bad thing for starting new projects. the release cycle is rather slow. it is not clearly stated what differentiates this generator from the other solutions.

[kosz]

it would be interesting to know why development has slowed down with this generator ...

is the web app community not encouraging the use of generators anymore ?

[brandon-arnold]

I also think this is a very smart implementation, and I appreciate its adherence to Google's recommendation for using the fractal pattern for organizing the angular codefiles. On the other hand, I have to get my hands dirty in the Gruntfile to fix issues sometimes. I would like to see this project go on.

[khwerhahn]

I would also love to see this project go on. Especially sequelize is awesome. Most projects only offer Mongo. Maybe we could try and get more traction on this project by promoting it (twitter, facebook, etc). I'd be open to help out there.

[dotch]

imo a new release including sequelize, angular 1.3 and updated dependencies should be the main focus and then be promoted upon release.

[leonardoanalista]

I can't see a reason for "concern" here. Fullstack is not a framework - it is a generator. It generates readable and maintainable code with best (or good enough) practices. I like Fullstack because you are not stuck with an specific Framework such as mean.io, meanjs, sails or strongloop. Angular, node, express are great just the way they are without any magic behind the scenes.

Btw I am running locally a pretty big app on io.js. App was initially generatedby FullStack and it has been fine so far.

Leonardo

[mitchellmorris]

I agree with Leonardo. I like Fullstack because it not as tightly coupled as most frameworks are. It doesn't seem that this project makes up any rules. Instead it simply utilizes best practices to fill in the gaps and leaves the imaginative stuff to you. It's harder to get painted into a corner and it's easier to unravel external dependencies when new dependencies are introduced. IMHO, it's barely in the same wheelhouse as some of the alternatives mentioned. But honestly I haven't taken anything else for spin. Haven't really felt the need to. Fullstack works great for now!

[simonh1000]

+1 for updating some of the dependencies (I think for angular I just tweaked bower.json to use ">=1.2.*", and it has not broken

[leonardoanalista]

I tried to update angular to 1.3.x but BootstrapUI depends on 1.2.x. I contacted the BootstrapUI project member and they have plans upgrade but not sure when.

[Awk34]

Check out the Canary branch

[gaboesquivel]

@DaftMonk I'm in for helping maintaining. I also think we should accept PR to master and use tags for versioning as other projects. generator-angular already dropped canary see https://github.com/yeoman/generator-angular/blob/master/contributing.md

Well documented releases is good thing as well https://github.com/yeoman/generator-polymer/releases

It is also nice to PR from console using hub

[honkskillet]

Hi @Toub, effort is underway, albeit a little slowly, to unify the projects. Here is a collection of the alternatives that I know about. If you know any of them well and want to help improve its accuracy, I would welcome a hand maintaining it.

@dancancro Can you expand on this? It would be great if there was just one MEAN stack that people would rally around. Just looking at the various github repos it seems many have lost steam (in terms of upkeep).

[dancancro]

@honkskillet in November we started having Google hangouts and some collaborative brainstorms to address it. It's not exactly a secret that front-end development has a whole lot of different approaches and this comes at a cost. So the value of working together is pretty universally acknowledged. The details about how and the will to do it are not as solid yet but it's a start.

[honkskillet]

@Awk34 What specifically about the Canary branch ?

[honkskillet]

@dancancro That sounds great. When you say we do you mean the contributors to this repo or y'all and the contributors to some of the other repos mentioned?

[Awk34]

@honkskillet just an fyi that there is other stuff in the canary branch.

I have a bunch of stuff that I'd like to add to this project, but I've been lazy about learning how to develop for Yeoman generators.

[dancancro]

@honkskillet, it's a motley crew. Some people are maintainers/contributors of the various generator/seed projects, some educators, some Google people, some JavaScript experts from things other than Angular. After putting together the big spreadsheet of alternatives, I just wrote to whoever I thought could have an interest in solving the problem that it reveals. I'm personally not a contributor, an educator or a Google person. Just a concerned citizen with too much free time, I guess ;)

[andrewstuart]

I can definitely say for myself that there's a lot I'd like to do on the generator as well, especially around documentation and integrating something like dgeni.

To answer the question @Toub asked about alternatives, I think a dedicated CI that can push your package is critical to avoiding Key Man Syndrome, at least when it comes to having changes that can be integrated by a team of committers (who can come and go) and then be automatically deployed for anyone to use.

Without any guarantees that further work will see the light of day (on NPM), it's harder these days for me to find motivation.

Plus I now have a one-year-old and a 2.5 hour round-trip commute, so a lot of my time is accounted for these days. More evidence of the necessity of a deployment process not dependent on anyone in particular.

[honkskillet]

I would love for @DaftMonk to chime in on this issue.

[ericmdantas]

@honkskillet he doesn't show up on github with contributions since november/2014, I don't think that's happening.

I'm starting to think that a fork would be great to make things keep going, since most PRs are stuck, issues with no answers, etc.

[leonardoanalista]

There are lots of people keen to contribute. I think we should fork it.

[brandon-arnold]

I'm for it. I have ideas about the focus of this generator, myself, to accommodate for java and .NET service layers. I think whoever forks should take ownership of the project. I would be glad to do this, but as I have a single pull request and not much activity here, I think there are other more qualified candidates to own the vision and direction.

[ericmdantas]

Me too.

[honkskillet]

Yes, a SINGLE fork to a group repo might be the best bet. I wouldn’t want to see this project get splintered.

[DaftMonk]

Hi guys. Sorry for the lack of updates lately, I haven't had a whole lot of time to do this myself lately because of work and other responsibilities, but I plan to be more involved going forward and getting some solid releases out.

That said I have concerns about maintainability of the project if we just merge in tons of different additions, as it just adds to the scope and maintainability issues. Things like adding coffeescript support to the server, or an option for gulp/broccoli instead of grunt would be awesome, but they need to be maintained as separate codebases so as not to overburden the project. I've been pulling back on merging PRs like that until we can find ways to make thing scalable.

I believe the future of this project is to break things down into more modular pieces, and planning how we can do that is a large part of my discussions with Dan at our weekly Google hangouts.

I'd be happy to get some more people involved in maintaining the project who could help ease the burden of reviewing/merging pull requests and managing releases. Please let me know if anyone would be interested in that.

[honkskillet]

@DaftMonk Awesome, input. Keep the codebase lean is I think the correct approach. Many of the others MEAN stacks seem to stagger under their own bloat.

[brandon-arnold]

Hi Tyler. That is great to hear.

I like the idea of splitting it up, which may require changing the Gruntfile fundamentally somehow using another obvious task runner that may be better for this. For me, the central benefit of angular-fullstack has had very little to do with any part of the stack than the client. I use it for its support for Google's best practice recommendations for the angular fractal hierarchy, and for its smart build process of an angular single-page app into the client dist/ folder. I think it speaks to de-coupling this front-end stuff from the back-end for any purpose but having a useful mock server as an API test harness. Then building it for other server API platforms becomes built-in. I'm glad to contribute to this.

[DaftMonk]

@brandon-arnold Part of that client side decoupling is done with https://github.com/DaftMonk/generator-ng-component. But I totally agree the initial client scaffold should be completely decoupled from the server. We probably should have separate generators for the client and server initial scaffolds, and have the fullstack generator just combine them with some reasonable defaults.

As you mentioned, the gruntfile is very difficult to extend in its current form and is quite bloated. I would be happy to switch to broccoli or gulp if it would help to address those issues.

[brandon-arnold]

Thanks for the generator-ng-component, and I see that it needs work, as it just scaffolded a single .yo-rc.json file. For me, this decoupling can't come fast enough. I very much want to integrate this client-side functionality into corporate projects in which I'm involved, and I know I'm going to have to do something before it integrates well with them.

I think the idea of finding a task runner that gives you the ability to de-couple all these layers of the stack, and link them together somehow, is a fine and ambitious idea. I don't have many opinions about how that would go, except to say that Broccoli seems too beta still for my taste.

Fact is, the gruntfile works pretty well in its current form, if we are not even thinking about having other projects with which to integrate ng-component. I think that if ng-component were basically angular-fullstack without the mongo, keeping its current Gruntfile form, would be a fantastic start. Having a quick node API whose sole purpose is to provide mock data to the front-end has been enormously useful!

[Toub]

Happy to read that the project is not dead, and I really support the idea to decouple client and server modules.

[andrewstuart]

Sweet, glad to see that as well! :-)

I love the idea of using a lot more of Yeoman's composability to make a bunch of generators work together in concert. It seems like yeoman makes it fairly simple, even.

[dotch]

decoupling sounds really nice. especially since I like the server part with the token based auth system + sequelize support and used it with react and ember based clients. would be awesome if you could outline your plans/steps to get there so interested people can follow along and maybe contribute.

[ericmdantas]

@dotch +1.

[Toub]

An other question related to the required effort is how do we manage github issues. A few new tickets are open every week and as nobody answers, the stack (and the related dept) only grows daily (167 open issues so far). Should we try to create a more official team with any volunteers and try to provide a common effort to close or plan the issues, and release a new version asap?

[dotch]

@toub yes that sounds reasonable.

[khwerhahn]

Maybe we can use a trello board?

[digitalmint00]

I think much of the problem is that as contributors select to grow the codebase it naturally becomes more difficult to stay current with it, manage it, and maintain it. I would like to see this project live on as more of a seed generator that manages core concerns rather than a jack-of-all-trades generator, but with that said, it will be those major contributors who ultimately shape its evolution -- and I am not proficient enough to be in that set. I think that a fork would make much sense but it may be more appropriate to fork to accommodate an experimental base and the current stable base. This will allow those familiar with the existing implementation to contribute and take weight off of those contributors trying to grow the project. Then the based could be reconciled periodically to reflect core revisionary changes. Idk, I would just hate to see this project become super fragmented and live on in many less perfect iterations.

On Wed, Feb 18, 2015 at 10:54 AM, Konstantin notifications@github.com wrote:

Maybe we can use a trello board?

— Reply to this email directly or view it on GitHub https://github.com/DaftMonk/generator-angular-fullstack/issues/801#issuecomment-74900384 .

[simonh1000]

@digitalmint00 +1

[jeffbuhrt]

Having been a public domain maintainer from the days of UU using RCS to current open source projects and as a software architect I see this project at both a simple and dangerous cusp. @KingCody and I have talked about some of my thoughts and observations.

Thanks for the project!

Some thoughts: -There are 'a lot' of people willing to contribute but it seems multiple PR's not getting merged in. -Not responding and/or creating a way to merge/share ideas being worked on discourages future contributions. -This project seems to have a lot of people willing to use and contribute right now. I would not lose the energy and potential users/contributors. Many projects die at this cusp. -Given the project is a builder and not a library or 'application' I would suggest having more options isn't a bad thing. Maybe a 'ask me all' or a high level per-sub package questions could be a way to handle the '... but it does a lot and asks a lot of different things' question. I think being able to generate more rather than only one thing is good. [Balance against some points below.] -It seems generating the best of breed example is important. There aren't many solid examples let alone generators that allow easy extension. Related there are many 'dead' projects per the Google spreadsheet/survey that was referenced. A lot of older StackOverflow general Angular hints don't work out of the box and require tweaks at best to work. -Maybe contributor/approvers by module could work vs just framework as a whole (and only) to split the review/merge/commit load. I have not played enough with Github (vs Sourceforge, etc) to know if Github supports sub-projects with related approvers, etc. -A sub-project could exploring ways to support splitting the generator into chunks (server, client, db support, add-ons, language support (JS/Coffee[script]/tea/water... HTML/Jade/etc....) Modules and ways to add combinations, future options can help future add-ons. [Also a 'stop the insanity' could be that not every example has to generate in all combinations for now.] -The Git model of fork for a purpose/feature as long as it is done within the top level project and quickly merge if the idea seems solid (eventhough in this case maybe not perfect or 'complete') would be better than letting ideas die and not even having basic examples for thing people need. [it is a generator vs an application itself]. Good examples of how-to do might be the most lean thing. Some features will be expanded on, others may never have any more changes. People could also come back here once they use something this project bootstrapped them with and extend, expand, etc. helping everyone (including themselves by receiving back others' changes as well.)

-Jeff

[digitalmint00]

Yes, Jeff, we are definitely at or near to that point. I would hate to see this project become a chimera of sorts where there exist many similar forks that feature select advancement and improvements, but where this has come at the cost of having a larger community of contributors, testers, and project followers, and generally a better community. A logical progression would be to facilitate all of these would-be forks, or side-concerns, with a single fork that they can all exist as children of, that can then, later, allow for them to be evaluated and potentially, merged back in, or reconciled with the stable codebase, that everyone in the community will still be current familiar with, and thus available to give input in answering questions and issues.

This would be favorable to narrowing the audience, as typically would happen at each subsequent project fork.

On Thu, Feb 19, 2015 at 4:42 PM, Jeff Buhrt notifications@github.com wrote:

Having been a public domain maintainer from the days of UU using RCS to current open source projects and as a software architect I see this project at both a simple and dangerous cusp. @KingCody https://github.com/KingCody and I have talked about some of my thoughts and observations.

Thanks for the project!

Some thoughts: -There are 'a lot' of people willing to contribute but it seems multiple PR's not getting merged in. -Not responding and/or creating a way to merge/share ideas being worked on discourages future contributions. -This project seems to have a lot of people willing to use and contribute right now. I would not lose the energy and potential users/contributors. Many projects die at this cusp. -Given the project is a builder and not a library or 'application' I would suggest having more options isn't a bad thing. Maybe a 'ask me all' or a high level per-sub package questions could be a way to handle the '... but it does a lot and asks a lot of different things' question. I think being able to generate more rather than only one thing is good. [Balance against some points below.] -It seems generating the best of breed example is important. There aren't many solid examples let alone generators that allow easy extension. Related there are many 'dead' projects per the Google spreadsheet/survey that was referenced. A lot of older StackOverflow general Angular hints don't work out of the box and require tweaks at best to work. -Maybe contributor/approvers by module could work vs just framework as a whole (and only) to split the review/merge/commit load. I have not played enough with Github (vs Sourceforge, etc) to know if Github supports sub-projects with related approvers, etc. -A sub-project could exploring ways to support splitting the generator into chunks (server, client, db support, add-ons, language support (JS/Coffee[script]/tea/water... HTML/Jade/etc....) Modules and ways to add combinations, future options can help future add-ons. [Also a 'stop the insanity' could be that not every example has to generate in all combinations for now.] -The Git model of fork for a purpose/feature as long as it is done within the top level project and quickly merge if the idea seems solid (eventhough in this case maybe not perfect or 'complete') would be better than letting ideas die and not even having basic examples for thing people need. [it is a generator vs an application itself]. Good examples of how-to do might be the most lean thing. Some features will be expanded on, others may never have any more changes. People could also come back here once they use something this project bootstrapped them with and extend, expand, etc. helping everyone (including themselves by receiving back others' changes as well.)

-Jeff

— Reply to this email directly or view it on GitHub https://github.com/DaftMonk/generator-angular-fullstack/issues/801#issuecomment-75154570 .

[jeffbuhrt]

@digitalmint00 I agree a single project is the best for all. Fragmenting to separate projects breaks the community. Having a large user base and everyone working together is the best.

Finding a process to allow more frequent merging and feedback along with a 'stable' public release might be enough.

[honkskillet]

@jeffbuhrt +1

[gaboesquivel]

I don't like other mean generators, although I'm looking for one that uses gulp as build system. I'm actually thinking on forking and gulpifying this one, since it's the one I like the most.

But reality is this project needs more active core members that maintain it... perhaps it deserves it own organization on github. this doesn't happen on any of the yeoman projects, issues are properly tagged and code members do code reviews frequently... you PR directly to master, you can use hub.git.com, and these generators are used by a lot of people, more than this one.

I volunteered to help maintain it on this same thread and received no reply. Actually I don't know if there's other maintainer other than @DaftMonk. Do what yeoman team does, it's proven effective. that's my suggestion and again use hub :) .. I'm loving it. Trello is bad idea, github is designed to collaborate, that's the whole point of it.