search

cloverfield-tools / cloverfield

A next generation JavaScript boilerplate scaffolding tool.
MIT License
142 stars 8 forks source link

List of existing scaffolding tools #5

Closed ericelliott closed 9 years ago

ericelliott commented 9 years ago

For reference, here are some existing scaffolding tools:

vivainio commented 9 years ago

Brunch is one for the list as well. My favorite is probably 'git clone' though ;)

therealklanni commented 9 years ago

Definitely a fan of Yeoman.

ericelliott commented 9 years ago

Thanks @vivainio! Can you go into more detail about scaffolding with git clone? Is there a good list of boilerplates that you could use as scaffolds using only git clone?

@therealklanni What do you love about it? What would you change about it?

therealklanni commented 9 years ago

I love that it handles pretty much any scaffold you could possibly want (no generator for what you need?—make one!).

I can't really think of anything in particular off the top of my head that I would change about it.

vivainio commented 9 years ago

@ericelliott I'm thinking stuff like https://github.com/Keats/ng-boilerplate, don't know if there is a maintained list. I have tried yeoman, but in the end it's just a fancy way to do git clone (assuming your code diverges enough to stop sub-generators from working)

ericelliott commented 9 years ago

@therealklanni I don't think I've ever found a yo generator that doesn't do a bunch of stuff that I felt the need to undo. Most of them are too broad, prescribing an entire application framework, and frequently a particular application layout for that particular framework. Are there a lot more granular generators that I'm not aware of? Here's an example of the problem. Lots of generators have descriptions like this:

A full stack, testable, web app development workflow with Browserify, Jade, Stylus/SASS/LESS, Gulp and Bower

The more prescriptions there are per generator, the more likely you are to disagree with one and skip the generator altogether.

Also, most of the ecosystem is bower-centric, which is problematic because npm is 5x larger and much more active than bower. Searching for "browserify" based generators brings up a small handful of generators to choose from -- none of them look very attractive.

@vivainio Yeah, it would be nice to have access to an organized ecosystem. =)

vivainio commented 9 years ago

Somehow, I think it would be useful to have a more stable "base" on which you would add stuff:

These are not all that hard to do, but it seems everyone ends up doing their own gulpfile and googling half-solutions from the net. Many of these problems could be solved in a "thorough" fashion if people looked beyond their immediate problem at hand.

ericelliott commented 9 years ago

@vivainio Front end npm has been in a nice state for years, and there are 5x as many packages on npm as there are on bower, and a much more vibrant dev community. Unfortunately, that hasn't been very well reflected in the scaffolding tools space, which is one of the reasons yo could use a bit of competition. Yoeman's generators are starting to feel very outdated when you look at how modern JS applications are being built.

As for taskrunner consensus, if you want gulp to be chosen, please feel free to contribute a gulp implementation to todotasks. The community seems to be leaning towards npm and make. I'm not convinced that we're anywhere near a confident decision. See the taskrunner discussion.

Many of these problems could be solved in a "thorough" fashion if people looked beyond their immediate problem at hand.

Yep. That's what we're hoping to accomplish with cloverfield, but it won't just be somebody's list of favorite tech that wins the day. We're going to put all the assumptions to the test.

One thing I can pretty much guarantee: Bower and AMD are already feeling old, and are not even in the running.

vivainio commented 9 years ago

@ericelliott whoa, that's a long discussion. I didn't actually know you were trying to do exactly this.

Gulp is fine on windows, make and 'npm run' are a no-go there. You may be on to something on npm, the faster we move to it from bower the better. It just doesn't seem like this is the case just yet, maybe in few months (scene changes fast)

ericelliott commented 9 years ago

@vivainio What do you feel that Bower does better than npm?

ericelliott commented 9 years ago

Gulp is fine on windows, make and 'npm run' are a no-go there.

This is potentially a very good point, primarily because too much dependence on Unix tooling can break cross platform compatibility.

vivainio commented 9 years ago

We are only consuming bower modules, not releasing through it. It probably does nothing obviously better, it's just that the catalog of frontend modules is bigger (still today).

Still, reading this article made me think npm needs time to catch up on frontend: http://blog.npmjs.org/post/101775448305/npm-and-front-end-packaging

ericelliott commented 9 years ago

the catalog of frontend modules is bigger

That's not remotely true. Roughly 60% of npm is browserify compatible. That's significantly larger than the entire Bower registry. Significantly larger than all other JS registries combined, actually.

ericelliott commented 9 years ago

@vivainio I think this point is worth your consideration:

50% of the actual downloads.. are front-end tools or frameworks

The downloads of less are particularly telling, because that implies that those downloads are explicitly for front end dev that is not based on Bower.

In other words, LOTS of front end devs are using npm modules on the client side without Bower. I can personally attest that I've been doing it for years, often times alongside workflows that rely on AMD and Bower. My personal experience is that node modules + browserify creates a much nicer development workflow.

Specifically, authoring all my modules in a single format has been nice. Avoiding Require.JS quirks has been nice. I have had frequent battles with Require.JS config, odd differences in behavior whether you include the .js extension or leave it off, etc...

For me, AMD and Require.JS have been very frustrating, especially after getting accustomed to node modules + browserify, where everything just seems to work as I expect it to out of the box.

AWaselnuk commented 9 years ago

The only one I've really tried is Yeoman. I found it provided a lot of boilerplate that served as good inspiration for how to do things. But inevitably I always ended up shaving away so much. I'm definitely in sync with you on that @ericelliott . I would love to see some smaller generators that are not so tied to a specific framework.