Comparison to similar projects

[dancancro]

Hello everyone. This is a great project. I entered selling points of this project and I made the following comparison of a few projects to show how they differ. If you have any corrections to make you can do so by commenting in the spreadsheet from which this is generated. If you are wondering why I went to such lengths it's not to promote a particular project. It's because I want people to stop competing and start working together. It is overwhelming to learners who have to pick a starting point and causes unnecessary duplication of work by the disagreeing project owners. Imagine what could happen if everyone worked together!

Developer Experience	Angular-kitchen-sink	great big angular2 example	ngrx example app	angular2-redux-starter	angular-seed-advanced
Authentication	X	X		X
Authentication, with two-factor authentication	X
Can run on a desktop without a browser					X
Client-side unit tests	X			X	X
Code coverage reporting (?)	X	X	X	X
Command line interface (CLI)	X	X	X	X
Components communicate with events	X	X	X
Core Module		X			X
CSS style checking		X
Deployment automation, to a mobile native executable					X
Deployment automation, using Docker (?)				X	X
Deployment automation, using Heroku (?)		X		X
End-to-end tests (?)	X		X	X	X
In-memory server-side database	X	X		X	X
Local storage	X	X	X	X
No build process is required	X	X		X	X
Production build, generate docs (?)	X
Separation of smart containers and dumb components		X	X
Server-side integration & unit tests	X	X	X
Shared Module	X	X
Style guide for code (?)		X
There is a book about it				X
Update generated code in an existing app	X	X	X
User Experience	Angular-kitchen-sink	great big angular2 example	ngrx example app	angular2-redux-starter	angular-seed-advanced
Account Management, Forgotten Password with Resetting	X
Account Management, login/logout	X	X		X
Analytics					X
Asynchronously loaded data example	X	X	X		X
Breadcrumbs (?)	X
Derived, computed properties	X	X
Dynamic component creation	X
External, 3rd party, API interaction	X	X	X
Footer	X
Front-end CRUD	X	X			X
Full-stack CRUD (?)	X	X
Full-stack CRUD, with Create, Update and Delete	X	X
Full-stack CRUD, with Create, Update and Delete, individual records	X	X
Full-stack CRUD, with Create, Update and Delete, whole data structures		X
Full-stack CRUD, with Read	X	X
Grid, Editable		X
i18n, localization (?)					X
Many-to-many data		X
Mouse wheel (?)	X
Navigation bar	X	X	X
Panels, draggable	X	X
Responsive styles		X		X
Search, actually works with backend API		X	X
Dependencies	Angular-kitchen-sink	great big angular2 example	ngrx example app	angular2-redux-starter	angular-seed-advanced
Backend Frameworks		Express		Express	Express
Continuous integration testers		Travis			Travis
Convenience method libraries	lodash	lodash	lodash		lodash
Databases	Redis	Redis (opt)		Redis (opt)	Redis (opt)
Documentation generators	typedoc
Frontend Frameworks	AngularJS 2.0	AngularJS 2.0	AngularJS 2.0	AngularJS 2.0	AngularJS 2.0
Languages	JS ES5, JS ES6 (ES2015), Typescript	JS ES5, JS ES6 (ES2015), Typescript	JS ES5, JS ES6 (ES2015), Typescript	JS ES5, JS ES6 (ES2015), JSX (opt), Python, Typescript	JS ES5, JS ES6 (ES2015), Typescript
Linters		stylelint	codelyzer, tslint	ESLint	tslint
Loaders	Webpack	Webpack	Webpack	Webpack	SystemJS
Misc	Angular Material, Immutable, ng2-redux, Redux, redux-devtools, RxJS	Angular Style Guide, ngrx, Redux, redux-devtools, RxJS	ngrx, Redux, redux-devtools, RxJS (opt)	autoprefixer, cssnano, Helmet, nodemon, Redux, redux-devtools, redux-logging, RxJS (opt)	cssnano, Electron, ngrx, Redux, redux-devtools, RxJS
Package Managers	npm	npm		npm	npm
Routers	Angular Component Router	Angular Component Router	Angular Component Router	Angular Component Router	Angular Component Router
Runtime Environments	Node	Node		Node	NativeScript, Node
Stacks	angular-cli	angular-cli	angular-cli
Task Runners	Gulp				Gulp
Test assertion libraries	Chai, Jasmine, Mocha	Chai, Mocha	Chai, Jasmine, Mocha	Jasmine	Jasmine
Test coverage reporters				Istanbul
Test runners			Karma, Protractor	Karma, Robot	Karma
Transpilers	libsass	libsass	libsass	libsass

EDIT: I added alt-texts to the benefits. Hover over (?)s to see them. EDIT: I added the Dependencies part

[NathanWalker]

This is awesome @dancancro !! I couldn't agree more. One of the reasons I did not create my own seed was for this very reason. It's why this is simply an extension and compliment to Minko's - because it was already an amazing seed - no need to create yet another distinct seed with it's own special setup. This seed serves 3 primary purposes:

1. Serve as solid example of how to extend Minko's awesome seed.
2. Serve as experimentation ground for multi-platform development from single codebase.
3. Provide a nice foundation for others that want to kickstart projects with the core features this seed provides out of the box.

Thank you for taking the time to put this information together, would be great to follow up with an article expanding on your analysis and concluding thoughts 🌮

[dancancro]

Thanks. I appreciate your agreement. 🌮

I started working on this a few years ago and have written about the situation a few times. I held Google Hangouts for a while with various project leaders and Google people. I have a few conclusions.

1. I'm terrible at moderating Google Hangouts
2. It's hard to get people to agree
3. People want to agree more than we might think they want to agree
4. This example I made is a sort of conclusion in that it demonstrates a pathway to agreement. I consciously ordered various expert approaches/styles to make this app and used the ordering to resolve conflicting opinions on how to do the same things. It's not perfect and I'm not an expert, but I think the idea of combining incompatible expertise systematically is possible if the experts are willing to give it a try. I hadn't come across your project until I already had enough projects to get sufficiently dizzy, but I welcome any offers to incorporate its virtues into the project if anyone wanted to do that.

My goal also evolved from reducing to a single starting point to sparing people massive amounts of time figuring out what's different between the different starting points. I respect the need to experiment but I also want to ease the path to convergence once the experiments have been conducted.

I have already done the bulk of the work to make figuring out differences much easier, but collecting and updating the facts about things is an ongoing chore. If anyone wants to help, the best way would be to comment "YES" (with links please) into the cells of the spreadsheet for benefits provided by technologies you know.

[fourctv]

Really awesome @dancancro! I am a seed user, and contributed a little bit at some point (although I'd love to contribute more, if I had the time or expertise).

When I started learning/playing with Angular2, I also bumped into some of those on your list, and ended up using Minko's awesome seed. I then moved to @NathanWalker's advanced-seed for one the primary purposed he mentioned above: multi-platform support.

And that is one item missing from your spreadsheet: mobile support. That is what brought me to the seed, the ability to use a single codebase and generate web, desktop and mobile apps. Although you do mention the ability to Deployment automation, to a native executable, that does not give enough weight to native mobile support.

Just my $0.02 contribution.

[dancancro]

@fourctv Thanks. I'm always open to suggestions. How would you put it?

The items above are a subset of all the selling points of all the web dev technologies I've read about over the past couple years - about 1500 at the moment - respecting inheritance of benefits from dependencies to dependents. To keep the above table from being too crazy, I have filtered it to just the important ones with some minimum subjective importance level I've given it.

You are welcome to send me a request for access to the spreadsheet and let me know if you think I should add anything, rename anything or give anything more importance points.

[fourctv]

Hi @dancancro my only suggestion at this point be a new row indicating support for "Mobile deployment". Feel free to name it as you please.

[OscarAgreda]

@dancancro , amazing consolidation thank you for sharing it . I also agree with @fourctv, after my research i decided to go with @NathanWalker's advanced-seed because the of ability to have one code base and multi "Front Ends" that compile natively. With Electron you can have the executables for Windows 10, Mac and Linux; that is unimaginable / inconceivable for most developers unless they see it. Then another "wow effect" is the elegant use of NativeScript to allow the app have views that compile natively for Android and Iphone. I think those facts definitely call for another Row on your awesome spreadsheet .

[dancancro]

@OscarAgreda No argument there. Write once run everywhere is holy grail level stuff. I'm going to read more about Electron and NativeScript and try to clarify what benefits they each deliver.

In what ways does angular-seed-advanced save you time that you'd otherwise need to spend putting Electron and NativeScript to use in your apps?

Also, I'm curious about the structure of this project that uses a 'frameworks' directory. That idea isn't part of the Angular style guide. If you'd like to talk about that, I brought it up in this thread on the ngrx project where file structure is being discussed.

[fourctv]

From my point of view, and @NathanWalker please correct me if I am wrong, the frameworks directory exists exactly because of the seed's multi-plataform nature. Code that is shared between the various platforms resides in that directory. (at least that's where I have mine).

Sure, it is not in Angular's style guide, but maybe that is an oversight of that guide :-), which does not take into account the idea/possibility of sharing code between multiple platforms. That guide does provide support for multiple 'apps' under one project, but it seems to assume all 'apps' are targeted for a single platform (web).

[OscarAgreda]

@dancancro Ok, let’s say we need to architect a multi-tenant software application (like Facebook for example, I am not sure if Facebook has this enterprise architecture but most likely yes), in which each of the millions and millions of users thinks and feels as if the application was specifically built for him/her. That is accomplished by having some type of Identity Server that injects some properties (claims) to each user that when she/he logs in makes the application behaves accordingly based on his/her assigned credentials. Also, let's say, this same app, must have just one “code base at the server level”, meaning that the developers will only work in one application, not many which will be impossible to maintain. I use Facebook as an example because there are millions of users running the same app “Code Base”.

Fakebook has a web interface and a Mobile version of the same application, and they use the same Sever Code. (If the developers find a bug, they only need to fix it in one place). From my humble opinion, applications that only run on the web are a thing of the past, every business nowadays wants a mobile app version for whatever app they have (or will have) for the web. NativeScript is the solution for the native mobile world. As a side note, I am a crazy Silverlight developer, then WPF so XAML comes easy to me, and I can tell you that I will not use Xamarin to build mobile apps (been there done that), in addition React Native seems to foreign to me. NativeScript is what some people are starting to call Angular Native.

So when @NathanWalker and all collaborators decided to go the extra mile by including NativeScrip, they provided a way to use the same server code (back end) and the same angular code (angular modules) for 6 fronts ends (Web, Windows Desktop, Mac Desktop, Linux Desktop, Native Android and Native Iphone) all utilizing the same business logic, nothing changes on the application . As i said, this is unthinkable to most developers. Most people won't believe it is possible , but it is .

[dancancro]

I'm getting into testing and see that this project has given that a ton of thought. I have a couple questions about why things were done the way they are done in this project. I hope this is an ok place to ask them.

1. What's the story with the "sample" directory? I can't imagine real projects based on this seed are meant to have their special stuff in a "sample" directory. I'm confused about the difference between what resides in src/client/app/components and src/client/app/shared/sample.

2. What's the difference between the src/client/app/shared/test directory and the src/client/app/shared/core/testing directory? I contrast this with the src/testing directory prescribed in the Angular Documentation which is my moral authority. I'm not saying deviations are bad. I just want to know the rationale behind them.

3. Was there a conscious reason behind putting the core directory in src/client/app/shared/core rather than src/app/core as it is in the Angular Documentation? I'm a little confused how the Angular team meant core and shared to be distinguished. I think it has to do with the number of instances things should have.

[NathanWalker]

@dancancro

1. This directory explanation may help: https://github.com/NathanWalker/angular-seed-advanced#code-organization-overview Sample directory is Just a sample module pre-configured with a scalable ngrx setup. meant to serve as an example of how to potentially build your own module out. It's meant to be deleted 👍 Components directory is also explained there.

2. shared/test is meant for shared testing code. Each directory which equates to a module can have it's own specific test helpers, hence shared/core/testing, etc.

3. Since the app directory is shared with the native mobile app, to reduce the amount of folders showing up in either locations, they are all collapsed down into the shared folder 👍 In the case of the seed, this naming has nothing to do with Angular team principles.

[luchillo17]

@dancancro Seems you've tested a lot of things, do you mind if i ask how would you persist state through application exit? In my case state lives in Redux store through @ngrx/store, and cross-platform (NativeScript/Electron/Browser) persistence is done with LocalStorage, what would you recommend?

[dancancro]

@luchillo17 I don't know how things work without a browser but with a browser you can use the browser's local storage like this for small things like an authentication token or the indexedDB like this for more data. The ngrx example app and others demonstrate it too.

I recently read this article about the various kinds of state in an application. I'm still trying to understand it. The author takes an approach that has a reducer making calls to the server which sort of breaks the main rule of Redux. He recommends and uses ngrx in his work but unfortunately he did not in the example code. So I'm working on figuring out how to do that so I can add this to my example app.

[luchillo17]

@dancancro As far as i know that's the purpose of @ngrx/effects, though haven't got to use them yet.

[dancancro]

@luchillo17 That's right. My example app uses lots of @ngrx/effects if you want to see how they work. And supposedly the author of the article uses them in his projects too. He just didn't use them in this article's example code. So I'm trying to figure out how he would have done this example if he had chosen to do it with effects.

[luchillo17]

For now i'm trying to figure NativeScript out, dev builds get me startup times of 12 secs, and trying aot generates error, depending on this i might have to go with ReactNative, which also generates some errors.