Lite version

[nickpack]

Not really sure what your thoughts are on this:

https://github.com/nickpack/Backbone-Require-Boilerplate-Lite

I noticed my colleagues spending some time removing bootstrap and jQuery UI but still using the boilerplate, so figured it makes sense to make a lightweight version without these. I am not convinced that removing jQuery mobile was that great an idea but figured as I am making it light I should remove it anyway.

Not sure how this is going to ride with you, but was thinking of maybe running this as a branch in the main repo and keeping releases in sync. I realise that this adds additional maintenance work to the project, but I am happy to strip newer releases back if I have the time.

Let me know your thoughts.

[gfranko]

I think removing those libs and creating a lite boilerplate makes a lot of sense. A lot of the motivation behind adding the Bootstrap jQuery plugins, jQueryUI, and jQuery Mobile in the first place was to educate people how to integrate these popular libraries with Require.js.

Also, I had previously discussed the idea of creating a Github organization to hold different Backbone/Require boilerplates with @brettjonesdev (who has created a BRB w/ Marionette. What do you think about that?

[nickpack]

Sounds like a sensible idea to me, I do have plans for an SCSS based version too (yet again another thing we change at work) so would be a good place to collect all of these ideas I think.

[brettjonesdev]

Funny you should call it BRB-Lite... after I created Marionette-Require-Boilerplate, I made a separate, stripped-down version called MRB-Lite which simplified some things.

I agree with the idea of removing those common libraries just to make it lighter weight. I would further suggest, if we plan on making *-Lite versions of boilerplates, that the Lite versions also remove the separate RequireJS init files for Mobile vs Desktop - i.e. AppInit.js instead of MobileInit.js and DesktopInit.js.

Having used Marionette-Require-Boilerplate as the basis of a project, I was constantly annoyed by having to add new dependencies to the require config in not one, but two files. This, in my opinion, is the single greatest point of friction in getting a simple project off the ground quickly. You can check out my index.html and AppInit.js if you like.

Anyway, that's my two cents - yes, drop the specific UI libraries, but also consolidate to a single AppInit.js.

PS oh also adding grunt is great

[gfranko]

@brettjonesdev I definitely think stripping out the mobile stuff for a lite boilerplate makes sense. People want to get up and running fast.

@nickpack @brettjonesdev What would you like the new organization to be named? I named it BoilerplateMVC right now, so that we could potentially create other boilerplates that are not just Backbone and Require related. What do you guys think?

[nickpack]

@gfranko Personally I would go with the latter, as I am more than happy to contribute additional MVC boilerplates that arent specifically Backbone based.

[brettjonesdev]

I like BoilerplateMVC as well. Makes for a nice wide umbrella.

[gfranko]

Backbone-Require-Boilerplate is now a repo for the BoilerplateMVC organization!

[gfranko]

Here's a list of things we probably have to do whenever we have time:

• [x] Transfer any additional repositories to the BoilerplateMVC organization.
• [ ] Create additional boilerplates with different MV* frameworks (Ember, Flight, Angular, etc) and different AMD loaders (Browserify, One.js)
• [ ] Create a new GH pages website that we can point new users to tell them about this project.
• [ ] Create a logo for the project
• [ ] Create a few small real world examples for each boilerplate
• [ ] Discuss any changes that we would like to make to the existing boilerplates

Feel free to add to this list or change it.

[brettjonesdev]

I will transfer MRB and MRB-Lite to the org. I have no design skill, so not going to be much help with the logo.

I like number 4 - I was kind of mulling the idea of having a sort of 3-level approach; a Lite version, a standard version, and then a simple, real working application which is more of a demonstration of how the MVC tool in question is supposed to be used. I was thinking about the 3rd when working on MRB - having a boilerplate to get up and running is nice, but it would also be useful to show a real app that builds off of it. Does that make sense? Possibly a simple Node Express App with a login and some simple I/O? Thinking something slightly more complex than ToDoMVC, although if we wanted to keep it simpler I'd be fine with that too.

[gfranko]

I really really like the 3-level approach for each boilerplate but I have a question about the working example app. Should the working example app use the standard boilerplate or the lite boilerplate? I definitely think that providing example apps, that mimic real world apps (more than a todo list), would be extremely helpful.

P.S. The website should be made with one of the boilerplates

[nickpack]

I may be able to help with the logo - will have a mess around when I have a few mins - any rough ideas on concept?

I've forked my lite repo to the org for the time being, I have some stuff I want to play with - so I'd have only ended up forking it back from the org - let me know if this is alright, if not I'll do it the other way around.

@brettjonesdev I agree entirely on ditching the mobile stuff from the lite one - I'll sort that out shortly.

On real world examples - I am presently building a new site for my band using the boilerplate which I was planning on open sourcing anyway - this could serve as one.

[gfranko]

I think our slogan should be similar to the TodoMVC project ("Helping you select an MV* framework"). Something along the lines of "Helping you get started with an MV* framework and Module loader".

For the logo, we may need to decide the scope of the project first. Besides eventually implementing boilerplates for other MV* frameworks besides Backbone, do we also want to look at using other Module loaders besides Require.js? I'm thinking we may eventually have boilerplates that use browserify or one.js.

@nickpack Instead of forking your repo as a BoilerplateMVC repository, would it be better to just add your main repo as a BoilerplateMVC repository and then have some sort of dev branch for you to work out of?

@nickpack Also, I think your band website could definitely serve as a cool example. I don't think we have to stick with the TodoMVC mantra of redoing the same sort of app with each different technology. It might even be more interesting to have different types of apps with each tech stack.

I think we should also consider using the grunt-init plugin to create custom templates so people could easily scaffold our different types of boilerplates without having to clone each repo. I almost think of this project as a mixture between Yeoman and TodoMVC.

[nickpack]

@gfranko @brettjonesdev Move completed, I also removed the mobile router and tidied up the 'liteification' a bit (found some remnants of old libs in the shim configs)

[nickpack]

What about adopting something along these lines for the logo? http://nozama.typepad.com/.a/6a00e54ed05fc2883301156f6759e7970c-800wi

[nickpack]

Are we concerning ourselves solely with frontend MVC? I dont come from a frontend background at all, infact far from it.

[nickpack]

Also with regards to CI, Jasmine seems like a massive ballache, is it worth switching to qunit?

[gfranko]

@nickpack I was thinking that we would focus solely on front-end MVC for now, but I'm open to increasing the scope of this project if it makes sense. What did you want to do?

Good question about Jasmine too. I tend to prefer the Jasmine syntax over Qunit, but that is obviously my personal opinion. Also, I think it is easy enough to run Jasmine test suites via Grunt, but the difficulty is with the Require.js integration right now. I think this will change very soon.

I think our logo could look something like that example (that logo is currently used with the Backbone Boilerplate project).

[nickpack]

@gfranko Having just wasted an hour messing with qunit and facepalming massively I think I may have a solution to running jasmine via grunt, its a bit fiddly and I have run out of time today, but expect a commit in the next couple of days adding grunt and travis support.

[brettjonesdev]

On qunit/jasmine, I find that Jasmine's syntax is awesome for synchronous, but is absolutely horrible for asynchronous. Qunit is much easier to handle asynchronous, but is not quite as lovely and readable as Jasmine otherwise.

I think that whatever we choose, we ought to wrap it all up in grunt. As far as module loaders outside Require, I think that it could be nice to have a few project which use something like one.js or browserify.

@nickpack I like that idea as the basis of a logo.

@gfranko if we could create make something that used grunt-init to automatically produce templates that would be super cool. Or perhaps a web interface with checkboxes where you select your framework, pick your module system and some ancillary libraries and it automatically downloads a zip project for you? Sort of like the jQuery UI download site. Maybe I'm dreaming. :) Either way, I think we ought to fine tune our existing projects and push out a couple more frameworks and example apps before we try something that ambitious.

I definitely think we should put grunt in all of our projects.

Regarding specific backends, I agree with @gfranko that we should focus on the Front End for now, however I think that for our example applications we could use a smattering of whatever backends we personally prefer, just to show that front-end MVC doesn't have to depend on any particular backend. I personally will probably do a lot of Node/Express back-ends, but that's just me.

As far as my next move goes, once @nickpack has gruntified Backbone-Require-Boilerplate or BRB-Lite, I will take that code and copy it to work for my Marionette-based projects. I will also be working on an example application that uses one of them. My time is fairly limited right now by the way - I've got a 6 week old at home. :P Looking forward to working with you guys though!

[brettjonesdev]

OK just saw that grunt is already in. I will get my projects all gruntified shortly.

[gfranko]

@brettjonesdev I agree that we should fine tune our existing boilerplates and add a few more before we integrate custom grunt templates and/or a custom build process. We will eventually be able to do the custom build, so you aren't dreaming =). Also, I get that your time is limited with your new son and will appreciate any contributions you can make!

As far as my next steps, I am planning to learn more about Ember.js and Twitter Flight and will contribute boilerplates for them in the next coming weeks.

Finally, I added @skusunam to the BoilerplateMVC team. Welcome! He has experience with both Backbone and Angular and should be a great help.

[brettjonesdev]

Welcome, @skusunam! Looking forward to seeing your work, especially with Angular.

[skusunam]

Thank You team.

@brettjonesdev When i started with these MV* frameworks i always had trouble getting up to speed with them (structure, libs, build, mobile version etc). I always wished for boilerplate projects like these. I am 5 weeks old with Angular and have uncovered lot of things and had few aahaa moments, also awkward moments with it. I just started a seed projects on top of angular-seed w/Grunt (lint, Karma - unit & e2e tests, live reload, express, jsbeautify etc): https://github.com/skusunam/angular-grunt-seed

This effort is to make anyone new to Angular have a play (real) project up and running in no time. They can use Yeoman but it has 1000 more things which is not required for 90% of the projects. But i am heading in a direction where i will use most of what Yeoman have (some day in future).

Hoping to add a new project Angular-Boilerplate. I am not convinced yet in using Require w/Angular. On my list of things to make an opinion on this after a POC.

[brettjonesdev]

FYI I updated MRB and MRB-Lite with the Grunt builds from BRB and BRB-Lite, as well as a few other updates/improvements. I also changed the welcome page to plug our organization. Once @nickpack has a logo for us, I'd like to include that on the welcome view.

Next I plan on trying to complete a non-trivial example app which uses MRB-Lite. I also intend to write a blog post about MRB and/or MRB-Lite. I think it would be a good idea for us to blog about our respective projects.

[gfranko]

@brettjonesdev Great work! Yea, we are going to have to make an effort to go through each project and update the documentation to reference the BoilerplateMVC project so that people know each boilerplate is part of a bigger thing.

I also think blogging about individual boilerplates is a great idea, but we may want to wait for a larger publicity push until we feel the project is in a non-beta state (i.e. All projects have consistent documentation and battle-tested example app's, the BoilerplateMVC project website is completed, etc).

[brettjonesdev]

I am fine with holding off on the blog post for a while until we have all our ducks in a row. I can continue to work on my example app in the meantime, and maybe update the documentation for our other projects as well. If anyone needs some extra bandwidth feel free to ping me and I'll do what I can.

[nickpack]

Apologies for the radio silence chaps, been a hectic couple of weeks!

I should have some time to pick up where I left off tonight. Though the band site example is a no-go now as I am no longer in the band!

[gfranko]

@nickpack No worries! I've been working on improving BRB and I am going to push an update today that I think everyone will like. Later today, I'll give you all a break down of the improvements.

[brettjonesdev]

Dang sorry, @nickpack. I play the bass/guitar/keys/vocals. We should start a BoilerplateMVC band! @gfranko looking forward to seeing them.

[nickpack]

lol @brettjonesdev that could be a little geographically challenging!

Looking forward to it @gfranko

[gfranko]

Hey guys, I just released BRB v1.5.0. There are a few breaking changes that I think are huge improvements. Here are the upgrades:

• All Require.js configurations are now stored in one place (config.js) instead of three. This removes the pain of managing different desktop, mobile, and jasmine configurations. You can see the improved logic inside of index.html, specRunner.html, and the Grunt build. I also moved DesktopInit and MobileInit to the new init folder.
• The Jasmine Test Runner logic was simplified by removing testInit.js and all shim configuration settings for Jasmine. The Jasmine library is now being included directly before Require.js, which guarantees that it will be on the page before any specs are run.

@brettjonesdev Now that there is only one configuration file to worry about, does that make the mobile/desktop logic easier to grok?

[gfranko]

Shifted this discussion to the BoilerplateMVC repository

[brettjonesdev]

@gfranko I love the single Config with multiple Init files. Must confess I felt stupid for not thinking of this sooner, since managing multiple configurations was the irritatingly difficult part. Definitely the answer we were looking for. I will propagate this pattern to MRB and MRB-Lite.

[brettjonesdev]

BTW where are we supposed to continue our conversation now that you closed this Issue? Your link referenced this very page. :)

[gfranko]

@brettjonesdev Whoops I pasted the wrong link. Just updated the link =)