Discussion: make generator-webapp more mobile-friendly

[passy]

I was talking to @gauntface today, who is using the webapp generator as part of his Cordova generator after the initial project structure is set up. This appears to work surprisingly well given that generator-webapp was never designed to be used as sub-generator to begin with.

However, he ran into a few issues that we could take care of:

• jQuery is a bad default for a mobile application. I think that it is less likely to be needed for a webapp today in general. It is part of H5BP, though, which we try to stay close to. Now that we have checkboxes, could we make it another optional setting?
• The default template isn't responsive. You have to scroll horizontally. That should be easy to fix.
• Installation and welcome messages should have an option to be turned off. When you call from another generator, you usually don't want to see them. Could be one or two additional flags, but it would make sense to keep those consistent across the default generators like --skip-install.

Thoughts?

/ping @addyosmani @sindresorhus @stephenplusplus @paulirish

[addyosmani]

Good points!

So, @gauntface and I are exploring how to make generator-webapp more mobile-friendly as part of https://github.com/yeoman/generator-mobile and once we've done an alpha release I'd love to see if there's anything there that would benefit being brought into this generator.

I wouldn't mind moving jQuery to a prompt but we may want to survey developers before doing so. Most of the time when I need it these days it's to use with an accompanying framework so it makes more sense to continue bundling with those types of generators where it's a dependency.

Regarding the installation messages, +1 on us having an option for those to be turned off. How about --skip-welcome-message, --skip-install-message or something along those lines?

[gauntface]

Adding those messages sounds like the best approach to me.

I'll schedule this in for early next week and just put the relevant changes in as separate pull requests, should be fairly trivial changes.

[gauntface]

Just to discuss the jQuery issue a little further, the best solution does seem to be to add further options to switch jQuery (and Modernizr) from being defaults to checkbox items.

This does slightly increase complexity, checking whether certain things are included or not now that they can be optional.

But it does cater for a use case where people may not think it's the best thing to include (and perhaps offer something else on top of webapp).

Would it be worth adding Y (include by default), N (No don't include by default), R (Remove from options list) as parameters to a list of options (i.e. --jquery=R --modernizr=N --boilerplate=Y)

[sindresorhus]

For jQuery; why do we need to prompt for it. Can't we just document that it can be installed with Bower? Or is it expected to be a part of this generator. If so, having the learning prompt would make this much more convenient.

Modernizr is harder since it needs to be added manually to the head.

About the flags. I don't like having lots of flags. Makes things bloated and complicated and needs to be added to every generator, which is not feasable. Can't we instead expose a property that tells a generator if it's being used as a subgenerator and let it do some conditionals in that case? That property could then be used in installDependencies to automagically disable the message for subgenerators.

Would it be worth adding Y (include by default), N (No don't include by default), R (Remove from options list) as parameters to a list of options (i.e. --jquery=R --modernizr=N --boilerplate=Y)

We are planning a "learning prompt" which will basically remember what you choose and don't prompt you again unless you choose too. This will make it much better experience to have more prompts.

[gauntface]

If developers like and use jquery then we should keep it in. Just because it can be installed by bower, it's a bit if an annoyance.

Is there a way to make things more flexible without increasing the complexity? At the moment, parameters seem the obvious way, the only other thing I can think of is finding a way to override the webapp generator methods and change accordingly.

I.e. override a get check box options method and tweak the jquery parameter option to be off by default. On 10 Aug 2013 15:58, "Sindre Sorhus" notifications@github.com wrote:

For jQuery; why do we need to prompt for it. Can't we just document that it can be installed with Bower? Or is it expected to be a part of this generator. If so, having the learning prompt would make this much more convenient.

Modernizr is harder since it needs to be added manually to the head.

About the flags. I don't like having lots of flags. Makes things bloated and complicated and needs to be added to every generator, which is not feasable. Can't we instead expose a property that tells a generator if it's being used as a subgenerator and let it do some conditionals in that case? That property could then be used in installDependencies to automagically disable the message for subgenerators.

Would it be worth adding Y (include by default), N (No don't include by default), R (Remove from options list) as parameters to a list of options (i.e. --jquery=R --modernizr=N --boilerplate=Y)

We are planning a "learning prompt" which will basically remember what you choose and don't prompt you again unless you choose too. This will make it much better experience to have more prompts.

— Reply to this email directly or view it on GitHubhttps://github.com/yeoman/generator-webapp/issues/124#issuecomment-22441203 .

[addyosmani]

I agree we should cut down on unnecessary prompts where it makes sense.

That said before we drop jQuery we should do some further research into whether this would become a pain-point or actually help developers. Solutions like H5BP have continued to ship with jQuery for a good reason. If we do 'drop' it, I would rather it become a prompt because we'll be moving to prompts that learn from usage post 1.0 - this will lower the long-term cost of extra prompts.

I don't quite follow how exposing properties for a generator for the subgenerator usecase with the requirement that generator authors use conditions makes things cleaner than requiring the use of flags. Are you saying that we would detect the generator being used in this way and that's where we'd handle automagical disabling of the welcome/install messages?

[sindresorhus]

Are you saying that we would detect the generator being used in this way and that's where we'd handle automagical disabling of the welcome/install messages.

I'm saying let's put the logic in the generator system, so all the generator get's the benefit of it without having to do anything, while they still can by checking the property.

[sindresorhus]

Alright, let's make jQuery a prompt.

[passy]

What about Modernizr? I'd like to know what the H5BP team learned over the time. I always saw including the full version by default critical, because it has quite severe loading time implications without actually being used.

[addyosmani]

I'm saying let's put the logic in the generator system, so all the generator get's the benefit of it without having to do anything, while they still can by checking the property.

Okok. This makes sense now.

Regarding H5BP and Modernizr, @necolas may be able to shed some light here :)

[necolas]

H5BP isn't customisable, so the choices made there are not necessarily something useful for you guys. Prompting for jQuery sounds good.

I think this is a better way to handle optimized Modernizr builds automatically - https://github.com/Modernizr/grunt-modernizr

[passy]

@necolas Thanks for the feedback.

Right, we even have a ticket for grunt-modernizr: https://github.com/yeoman/generator-webapp/issues/107

[robwierzbowski]

Issues like this make me wonder if an official environment and build generator would be worthwhile. Something that includes:

• CSS and JS tools (pre and post processors)
• Asset directory structure
• Dev environment and build tasks for the above

But doesn't include:

• Templates
• Bower dependencies
• Project specific grunt tasks and sub-generators

Some of the features discussed in https://github.com/yeoman/generator/issues/277 would make it easy for generators to pre-supply defaults and selectively bypass subgenerator prompts.

On the other hand, I'm not sure if using a subgenerator like this would complicate building a more specific generator, especially when you're adding a setting here or there to grunt tasks the subgenerator has already defined.