More Questions & Answers Stuff

[davemo]

It would be awesome to have answers on the "design of lineman" relating to some of the opinions that Lineman has as an addendum to the Questions & Answers section following the Lineman vs Yeoman feature grid.

@searls probably has the best insight into answer these, here's a few of the common questions I get regarding this stuff:

• Why doesn't Lineman have sub-generators for its project templates? (ie: yo angular generate controller:food)
• Why does Lineman wrap grunt, testem and other tools instead of letting users reference them directly?
• Why does Lineman use Testem as its default test runner?
• Why doesn't Lineman use Bower or any other Package Management tools?

[searls]

I think this Q&A is going to turn into a blog post. Working on my reply now and it's getting too long.

[davemo]

A blog post is useful, is your idea to extract pieces from the blog post to condense into Q&A below our comparison matrix on the docs site?

[searls]

Or to encourage you to :-)

On Wed, Sep 11, 2013 at 11:17 AM, David Mosher notifications@github.com wrote:

A blog post is useful, is your idea to extract pieces from the blog post to condense into Q&A below our comparison matrix on the docs site?

Reply to this email directly or view it on GitHub: https://github.com/testdouble/lineman-docs/issues/6#issuecomment-24248836

[searls]

On reflection I'll go back to answering this inline then we'll decide what to do with it. Huge comment coming soon

[searls]

I'll try to take a stab at these inline:

Why doesn't Lineman have sub-generators for its project templates? (ie: yo angular generate controller:food)

Generated code, like fish, begins to smell after three days.

For the maintainers, it's yet another thing they need to keep in sync with the library-dependent code that's being generated; worse, if the library makes BC-breaking changes, the code generators need to become smart enough to generate one among multiple versions of the code (after detecting which version of the library the user is depending on).

For the users, it can certainly help overcome "blank page paralysis" and help them to get started, but the generated code often introduces other immediate issues caused by an uncertain understanding of what was just generated. We saw this with rails scaffold all the time back in the day—folks would absolutely love it in demos, but upon looking at the bizarre controller & view code that emerged, they felt less command and ownership over it than they would have if they had rolled their own. That is to say that generating a quick start to an activity typically doesn't cure "blank slate paralysis", it merely defers it—and worse, to a point where you already have the carrying cost of code to maintain.

There is a caveat, I think: a generator that produces only a very tiny amount of code (like a rails g migration generator) can absolutely prove handy when (a) it's very small and (b) the code that it's generating has some element that makes it a pain to do by hand. (In the case of Rails database migrations, that painful aspect is the timestamp needed in the migration's file name.)

But generally, code generation is very hard to implement well, and it's even harder when the code being generated depends on a library you don't own. It essentially guarantees that Yeoman's sub-generators can't be delivered in a quality, forward-compatible way. That team is hereby doomed to get a bunch a 3 a.m. issues filed on account of generating out-of-date code, brought on by the innocent March of Progress by whatever library the generator targets.

Why does Lineman wrap grunt, testem and other tools instead of letting users reference them directly?

The universe of people who understand Grunt, testem, and the myriad plugins that Lineman depends on is a relatively tiny set of humans (in the thousands). The audience that needs a much better front-end development workflow with minimal additional cognitive load is absolutely enormous (in the millions). Therefore, it doesn't make sense to bottleneck adoption of the much better development workflows that are afforded by Grunt (et. al) by first demanding as a prerequisite an understanding of what Lineman uses "under the hood." The user should be able to get some value out of Lineman without understanding how it works at all.

Additionally, by maintaining our own CLI and owning the top-level process, we can smooth out the edges of some of the libs we depend on in ways that aren't always possible by configuration alone. Better yet, we can swap out a dependency more-or-less invisibly with an upgrade to Lineman.

Finally, Lineman doesn't hide anything that it depends on, because we know that every single project that uses Lineman long enough will need to customize some aspect of its workflow eventually. That's why Lineman is obscenely extensible—literally anything Lineman configures (whether it's grunt tasks, conventional file patterns, or test runner configuration) can be overridden without any precognition on the part of Lineman's developers. This is one of the reasons it's been so easy for us to adapt Lineman for use with a variety of front-end frameworks with minimal additional code.

We view Lineman as providing just one (skinny!) layer of your front-end workflow, as opposed to a monolithic approach like Rails provided:

Aspect	The Rails Way	Our front-end approach
Application Framework	Rails	Any of the 20 current front-runners
Conventions and Default Config	Rails	Lineman
Build tasks	Rails (via Rake)	Grunt

Why does Lineman use Testem as its default test runner?

We like Testem because Lineman & Testem seem to share a core motivation: make development a delightful, joyful activity, a priority that's been sorely lacking from front-end web development up until very recently. Testem was incredibly easy to integrate into our default Lineman configuration, supports a variety of test library adapters and usage patterns for the benefit of users, and is otherwise unopinionated and unbiased.

It does what it says on the tin, and not a thing more.

It could be argued that it's not the only test runner in Node-land to do so, but we've yet to see it argued that anything else is objectively better.

Why doesn't Lineman use Bower or any other Package Management tools?

For the same reason Lineman doesn't care to know which front-end JavaScript framework you choose to build your application with: if you ask a hundred front-end developers how it ought to work, you'll get a hundred different answers. Even developers who agree on a tool tend to arrive with different expectations at where to draw the boundaries between automation and convention. A bunch of questions arise, and the answer to each will narrow Lineman's audience; questions like: should we limit our dependency management to fetching libs? Should we include a module requirement mechanism? Should we encourage asynchronous script loading? Should that be configured or declarative?

There's simply way too much variety and churn in this space to pick a path and be confident that it'll have been the right decision multiple years from now (in fact, our money is that none of the current approaches will mature into the eventual browser-supported standard in a forward-compatible way). I've written about this topic at length and why I view it as a concern that's not critical enough to concern myself with yet at our blog

[davemo]

Nice work!

[davemo]

Pushed to master and heroku in 659cc3a0dcf9fcc1acdfbde6d1cb645910082f12

[jasonkarns]

Wow, excellent description, Justin.

[searls]

LOL, after the comment earlier that @jasonkarns is always my harshest critic, I'm now skeptical of any positive feedback as well. :-)

On Thu, Sep 12, 2013 at 5:00 PM, Jason Karns notifications@github.com wrote:

Wow, excellent description, Justin.

Reply to this email directly or view it on GitHub: https://github.com/testdouble/lineman-docs/issues/6#issuecomment-24355548

[jasonkarns]

I can't win!

(rest easy that I only share my true opinions)

On Thu, Sep 12, 2013 at 5:08 PM, Justin Searls notifications@github.comwrote:

LOL, after the comment earlier that @jasonkarns is always my harshest critic, I'm now skeptical of any positive feedback as well. :-)

On Thu, Sep 12, 2013 at 5:00 PM, Jason Karns notifications@github.com wrote:

Wow, excellent description, Justin.

Reply to this email directly or view it on GitHub:

https://github.com/testdouble/lineman-docs/issues/6#issuecomment-24355548

— Reply to this email directly or view it on GitHubhttps://github.com/testdouble/lineman-docs/issues/6#issuecomment-24356075 .

[jasonkarns]

closed by 659cc3a0dcf9fcc1acdfbde6d1cb645910082f12