Use Browserify by default?

[trykickoff]

Use Browserify by default?

[ashleynolan]

I’m still on the fence because of the reasons we came up with before when discussing it.

Pro–users should be able to use the recommended Yeoman generator, whereas chances are beginners won’t use the generator to get a build without dependency management.

If we can come up with a way that it can be easily taken out for people who don’t want it, then I’m all for it though, as I use Browserify as a base for JS on all my projects!

Maybe a switch in the Grunt config somehow…

[nicbell]

Concatenating files is ugly. At last it's time for the change, now I can have water whenever I require.

[YKehinde]

For smaller projects I tend to write all my script in one js file since there isn't a lot to do whereas some of the bigger projects i've been on, it might make sense to write the script in a much more modular way. I guess it's down to preference and whether the user will need it or not.

Being that I use Yeoman, I can make a choice between using browserify or not but someone pulling from the repo may not have the option...

[ashleynolan]

@nicbell I completely get your point, but it does then make Kickoff more niche as a framework if we start hardwiring a specific dependency manager into it by default.

People who don’t use Browserify won’t use Kickoff, especially if they use RequireJS or a different dependency manager, as having to undo config is harder than adding it in usually.

By adding it in as a default, it starts making Kickoff more opinionated, which is what we have always tried not to be in terms of dependencies, so it stays easy to build on top of in whatever way you want to. It might just be that we come up with a better/easier way of adding it in when people want it (Kickoff Addons perhaps?)

[mrmartineau]

@ashleynolan the way I see it, is that we are pushing the Yeoman generator as the default way to use the framework, so if that's the case, then we should be safe to make the switch. I think Kickoff is not an entry-level framework anyway so I don't see a problem with it.

[nicbell]

We have node, NPM, Grunt, SASS ect. For any developer using these tools is browserify actually a jump?

[ashleynolan]

@nicbell You could just ignore all of those parts of the framework if you wanted to. You could use the compiled CSS file, ignore the Grunt setup and use a tool like Codekit (if you wanted) and you wouldn’t have to change anything in the framework to do so.

I think if we make Browserify part of the default build, we have to make it so that it requires very little effort to not use it if people don’t want to. People adapt and edit a framework to their needs and I think that it’s important we don’t create too many extra barriers to doing that.

@mrmartineau Kickoff, although not entry level, should be accessible for anyone, and I’m not sure the benefits of making it part of the base project outweighs the potential negative impact on people not wanting to use it. If we use the generator ourselves anyway, it doesn’t really affect us in theory whether it’s default or not, so I can’t really see the reason to make it part of the default project – it kind of is anyway for us.

What are the benefits of making it default?

The only reason I can think of is that we want to push developers to use a dependency manager by default, to encourage that as a best practice – which is cool, but I think that we should try and get a broader opinion as to whether this would put people off or actually be a sufficient benefit to them in providing this setup.

I do think that sometimes, like Yemi mentioned, people might just want a JS file, and having Browserify setup may seem a bit like overkill to those unfamiliar with it.

Would definitely be good to hear other peoples thoughts on this – I’m not dead set against the idea, I’m just wary of making the barrier to entry harder if it doesn’t need to be. Especially if it doesn’t really affect us anyway.

[nicbell]

@ashleynolan same can be said for Grunt vs Gulp in Kickoff or the crazy image libs, the package.json has a long list of opinions.

[ashleynolan]

@nicbell Of course, but JS is fundamental to most front-end builds, whereas using Grunt isn’t – people can just ignore the build tool and it wouldn’t make any difference to them using the CSS or JS essentially if they had their own way of doing things.

If people didn’t want to use Browserify, they’d have to make their own JS file setup and add in their own concatenation step. We obviously make opinions in the framework, but making things easy to change or opt out of is essential.

Like I say, I’m not arguing against Browserify – I wrote the config for it in Kickoff after all – but I think it needs more thought around the positives and negatives it could introduce for people using the framework if it’s made default.

[mrmartineau]

I like your sentiment but I think as we evolve as developers, Kickoff should evolve too. What I like about Kickoff is that it represents a snapshot of what we deem to be the best workflow, for the widest array of projects, at a given point in time. At this point in time, using modules and npm as a package manager (and by extension Browserify) is the one of the best ways to manage JS.

Kickoff is opinionated and I think even I would struggle to use parts of it without Grunt or to change the JS build to something else.

Like I said before, if we retain the current default as an option within the generator, the main repo will be what we deem to be 'best practice'.

[mrmartineau]

Hey guys, I'd really like to resolve this today if possible. Please could you vote for your preference?

• Browserify [new]
• Concatination [existing]

My vote is for Browserify.

Please could @nicbell, @ashleynolan, @CiaranPark, @munkychop, @maciejgolis, @tommaton & anyone else chime in

[ashleynolan]

I’m happy to go with the majority on this one 🎱

[nicbell]

Browserify isn't the big change, it's moving from concatenated files to modules.
I want to go with writing modular code and being able to depend on third party modules via NPM.

Browserify is probably the best tool at the moment so that comes with this approach, the style will remain but there may be a better tool in 6 months.

[CiaranPark]

It's a tricky one, but personally I'd like it included as default. Don't know what the statistics are on what type of users use generators vs cloning but can't see it being a negative having an option to require Browserify in Yeoman.

As long as the docs explain that if you don't want Browserify then use the generator then I think that covers all bases.

[mrmartineau]

@CiaranPark good idea, I looked at the stats and FWIW:

• generator npm installs: 2 downloads in the last day, 80 downloads in the last week, 674 downloads in the last month
• git clones: ~10 in the past month

[ashleynolan]

Wow, so quite a lot more using the generator then, which is good news 👍

[mrmartineau]

indeed 💯 👍

[munkychop]

Another vote for Browserify here, as modularity should be encouraged. In
the future, I think that using ES6 (i.e. something standard) would make the
most sense, when it has enough browser support.

On Friday, September 4, 2015, Zander Martineau [email protected]
wrote:

indeed [image: 💯] [image: 👍]

—
Reply to this email directly or view it on GitHub
#57 (comment).