-
Notifications
You must be signed in to change notification settings - Fork 18
Why should I use a generator?
Modern web development is a complex undertaking and not for the faint of heart, consider the following reaction:
As many others here have observed, fashionable webdev now is beyond a joke; I’m seriously glad I got out of it when I did. Once you’re forced to actually deal with this nonsense you either run screaming for the exits or go insane. It’s not even fragmentation, it’s fragmentation cubed. I’ve lost count of the number of MVmumble frameworks I’ve seen pitched as “a framework using Foo, Bar and Baz”, where Foo turns out to be a event library you’ve never heard of with 3% usage share, Bar is a templating library you’ve never heard of with 2% share and Baz is a databinding library you’ve never heard of with 1%, making the combination useful to… I dunno, the author, maybe, for the next five minutes until he switches to a new set of libraries.
I don’t understand. I don’t understand why anyone thinks this is a good idea. I’ve seen code produced by people using this stuff, and it’s just unbelievably awful, because nobody has time to understand anything when it changes every thirty seconds.
**othermike, Reddit** [Another Response to the Selfsame Post](http://www.reddit.com/r/programming/comments/2kl88s/angular_20_drastically_different/clml1hj)
Enterprise development is an order of magnitude more complex.
-
You need a testing and CI strategy
-
A deployment strategy
Adding yet more churn is the migration from ES5 to ES6 and Typescript.
Yeoman generators can be a big part of the solution for all the above complexities. Our AngularJS 1.x, React and AngularJS 2.0 applications all share the same basic structure: They all have routers, components, models and some mechanism for dealing with asynchronous operations (Promise based services, RxJS, BaconJS, SuperAgent or any one of the many Flux Architectures). They all have linters, unit-tests and E2E-tests and they all have to package the app into an optimized, deployable bundle and even deploy to a CI environment in some cases.
Generators are the place that you capture and update your organizations best practices. All your projects that use the generator can benefit from the lessons learned in each. By propagating the best practices back to the Yeoman generator, all projects can benefit by simply running yo <generator-name>
and re-scaffolding the app. Yeoman will prompt you before overwriting each file (unless you tell it not to) and any changed files can be compared via diff tool (or local history in webstorm) and any necessary merge/restore operations can be performed.
Generators differ from seed projects in the following important ways:
- A seed requires introspection to determine the relationships between it's various components. The developer typically copies and pastes files from one or more folders into a new set of folders and starts renaming things and updating dependencies between artifacts until everything works. As projects grow and best practices change, or new developers (unfamiliar with the code) onboard, it becomes increasingly difficult to determine which examples are best to copy-paste from. Generators keep things consistent. With a generator, you select the type of artifact you want from a well defined list of artifact types and tell the generator where you want the artifact to live. The generator approach eliminates copy-paste errors, typos and missed dependencies. A generator can even enforce project structure and naming conventions.
- A seed is a minimal and static snapshot, anything more would require significant editing and/or deletion of artifacts. A generator, by contrast, can support a rich set of artifacts and choices of support libraries (CSS, testing, FRP, AJAX) that can be tuned based on input from the developer, both during initial project creation and through subsequent use of sub-generators. Sub-generators can create new artifacts and alter existing ones. Want to make a component routable and choose between sync and async? A sub-generator can offer the developer a list of viable candidates and make all necessary changes by following simple prompts. Want to know how to do it manually? Do a quick diff after the sub-generator runs using local history.
We've just scratched the surface but hopefully the utility of generators as a tool to smooth out the bumps in enterprise web development is a bit clearer. There is one more tool in our arsenal and if you aren't already using it you should run, not walk, to:
also see: