Break-up Chaplin into components

[chrismcv]

https://github.com/component/component is a really interesting means of structuring the components of a web application. I'd really like to be able to use chaplin (or parts of chaplin with it).

The basic premise is splitting things up into small commonjs modules - generally the smaller the better.

A potential route for chaplin could be splitting each function component (e.g. mediator) into a separate component (giving it it's own component.json) and then having an outer chaplin component that can also be used which groups all the chaplin "sub-components" together.

I was wondering if this is something that you would be receptive to, and if it would be worth my time creating a pull request for it?

[paulmillr]

Some folks had been already creating repositories that had some Chaplin code because they didn’t wanted to use all framework parts.

I’d say :+1: because component is cool. But it would mean we should use common.js by default and wait for coffeescript compilation api in component.

[molily]

How will this look like in practice? Will this just add component.json files or require the existing modules to be split again?

[paulmillr]

This will likely require the split, but with rewrite to common.js style. But we should wait until component(1) will get more mature so it will make sense to do the job at all.

[anthonyshort]

Can't require.js just load CJS modules anyway? I know there's an option to auto-wrap with a define so you can write in the CJS style. So writing in CJS would mean you get support for both anyway. I could be wrong though.

[paulmillr]

you’re right, some time ago we wanted to write all modules in cjs style, @molily declined with reason it won’t be idiomatic amd

[andriijas]

ive toyed with using bower in a brunch-with-chaplin project to manage the vendor stuff. Its pretty relieving to have a tool to manage those dependencies.

[mehcode]

Okay. Let's get this figured out.

Here is my proposal (after talking with @paulmillr):

Keep a small and restricted core that is just the following modules: mediator, dispatcher, controller, route, router, and any associated utils / helpers in a repository called chaplinjs/chaplin-core.

Create the following components and extensions:

• model in chaplinjs/chaplin-model
• collection in chaplinjs/chaplin-collection (might depend on chaplinjs/chaplin-model)
• view in chaplinjs/chaplin-view
• collection view in chaplinjs/chaplin-collection-view (depends on chaplinjs/chaplin-view)
• regions in chaplinjs/chaplin-regions (depends on chaplinjs/chaplin-view)
• composer in chaplinjs/chaplin-composer (depends on chaplinjs/chaplin-regions)

And of course a meta-component under chaplinjs/chaplin that includes everything except regions, composer, and the collection view.

Obvious benefits are code size reduction if you're only using certain parts, etc.

[paulmillr]

what about backbone dependency here?

Chaplin.Model needs only Backbone.Model. But Backbone is not modular. I saw some components that had extracted models etc and used them standalone.

[mehcode]

Is it worth it to maintain chaplinjs/backbone-model, etc.? Perhaps. We could even list that as an improvement over backbone. Another thing we could do is make it a common.js module so to obviate the need for shim configuration for backbone.

[mehcode]

To clarify, I wouldn't mind keeping the chaplinjs/backone-* repositories up to date with released backbone versions.

[paulmillr]

we should try, at least.

[akre54]

I'm not sure there's a special need to break these out into individual components. It sounds like a maintainability nightmare and confusing for end-users at best. Chaplin is small enough that I'm able to mix-and-match pieces I want in my applications myself; it's also fairly modular which makes pulling out only what I need very easy.

At Skillshare we use Chaplin's Views and Collection View, but not any of the model or routing bits. In other applications I've used the prototype walker for collecting hash heirarchy or mixed in Chaplin's routing and beforeActions with other home-baked solutions. It's been remarkably easy to maintain as Chaplin has evolved. Decoupling further seems like the wrong approach, IMO, especially given that (if I recall correctly) one of Chaplin's original design goals was to provide a full-featured and monolithic framework on top of the relatively tiny Backbone.js underpinnings.

[mehcode]

we should try, at least.

Agreed.

For completeness sake (so we're all on the same page) this adds the following repositories:

• chaplinjs/backbone-events
• chaplinjs/backbone-model
• chaplinjs/backbone-collection (depends on chaplinjs/backbone-model)
• chaplinjs/backbone-view
• chaplinjs/backbone-history
• chaplinjs/backbone-router (depends on chaplinjs/backbone-history)
• chaplinjs/backbone — all of the above

Furthermore all modules would be done in common.js style so users of chaplin don't need to use a shim configuration for each one, etc. All would be installable via bower and component. None of them would be registered in bower (however bower [like component] allows for bower install chaplinjs/backbone).

An interesting side-effect is that Backbone.Router wouldn't need to be included with chaplin.

Another benefit is that this would stress test component / bower. bower install chaplin is going to install 10 repositories total. Bower can be a bit slow so if we chose to do this I'll submit a benchmark to bower after we're done. Haha.

References:

• https://github.com/asciidisco/grunt-backbonebuilder (https://github.com/asciidisco/grunt-backbonebuilder/blob/master/lib/builder.js) — Interesting; extracts modules from backbone. We could just give grunt an update task in each repo and run it chaplinjs/backbone (with git sub modules) after each release. Barely any maintenance overhead.
• https://github.com/gfranko/backbone — Good concept (what the above was based on); may be too much of a maintenance burden

---

@akre54 bower install chaplin would be still be close to everything the user has to do to get chaplin. We could even have the tar file with this all nicely packaged. It will also keep code size down for those that don't need / want things like the collection view (and further allow us to expand the collection view and not feel as constrained by trying to keep chaplin's size down).

Chaplin is small enough that I'm able to mix-and-match pieces I want in my applications myself

That sounds like a maintenance nightmare to me. I normally never touch vendor code unless I need to fix something broken then but then I'll either fork it and fix it there or make a local repo, etc.

Chaplin's original design goals was to provide a full-featured and monolithic framework on top of the relatively tiny Backbone.js underpinnings.

It still would. Just it would also allow / pave the way for an entire ecosystem of chaplin. Maybe user X really likes our model serialization and just wants to bower install chaplinjs/chaplin-model next to his or her backbone project.

[vendethiel]

To clarify, I wouldn't mind keeping the chaplinjs/backone-* repositories up to date with released backbone versions.

Git subtree ? (Interesting)

[paulmillr]

Just wanted to shed light on this decision.

I am highly in favour of splitting chaplin into components because it will allow users to use only stuff they need.

Basically I am just doing some propaganda of component(1) philosophy. It says that if you only need good DOM manipulation query library, you should not use 250K jQuery and prefer small 0.2K just-DOM component.

If you are building an application with Chaplin, you need to know or at least be aware of:

• Backbone (58K)
• Underscore (40K)
• jQuery (261K) [Zepto is shitty and still does not support even IE10]
• Chaplin itself (71K)
• Grunt / Brunch / require.js, also CoffeeScript knowledge sometimes.

These are obviously non-minified sizes but the point here is complexity. It is hard, really hard for newcomers to learn all this stack, in my opinion.

The problem is that backbone hardly depends on jquery APIs. I want to change this maybe by introducing more decoupling changes there, just like backbone decoupled its AJAX and DOM to Backbone.ajax / Backbone.$.

Also, Chaplin does not use some backbone stuff at all (Router).

[mehcode]

Going further on this, our generator (https://github.com/chaplinjs/grunt-init-chaplin) could generate the project to perform custom builds of lodash (https://github.com/asciidisco/grunt-lodashbuilder) and jQuery (https://github.com/asciidisco/grunt-jquerybuilder) to attempt to minimize the size even further.

[mehcode]

Git subtree ? (Interesting)

I was planning on writing something automated (with grunt) that would be a combination of https://github.com/asciidisco/grunt-backbonebuilder/blob/master/lib/builder.js and fetching backbone.js from github for backbone.

The meta-component or supercomponent repository would simply depend on its components using bower or component (1).

[andriijas]

Does everything really need to be in their own repositories to make it possible to build custom builds?

I think of chaplin as my django for clientside, it provides me with a stable foundation where for the most parts I really need most pieces to make a solid foundation for my app.

Things that would typically be components, plugins, apps if you like the django nomenclature would be things like chaplin-auth.

[mehcode]

@andriijas Check over at bower; they've got a nice discussion of the pros and cons.

For end users, the actual use of chaplin shouldn't change all that much: bower install chaplin.

[molily]

I can’t comment on anything related to bower/component/node.js/whatever module internals because I have no clue of any of those.

I am highly in favour of splitting chaplin into components because it will allow users to use only stuff they need.

Backbone is laving out important questions to the users so they need to find a solution themselves. This doesn’t work well in practice and leads to horrible spaghetti code in most cases, which leads us to Marionette, Thorax, Chaplin, Aura etc. and all those useful but silly “Backbone plugins”.

I’m quite fine with the notion that Chaplin is monolithic, because from my point of view it’s one main structural concept that is just rolled out in different classes: Application, Layout, Router/routes, Dispatcher, Controllers, Composer, disposable Models and Views. Of course there are classes that are useful out of this context, and it’s quite easy to pull reusable pieces of code out of Chaplin. It’s also possible to implement the same concept with less code and less features.

But Chaplin is way more framework-ish than Marionette, for example. If you want the main concept of Chaplin, which are disposable controllers that react to separate, declarative routes, you already got the mentioned classes on board. This structure is quite fixed and opinionated, but using it for the whole flow gives you the maximum benefit.