Prepare Backbone 1.4

[megawac]

Some significant changes have occurred on master since 1.3. I'd like to get 1.4 out sooner than later. Below are a list of some of the more important activity highlights over the past couple months:

• Added support for ES6 classes with a preinitialize hook for model creation (https://github.com/jashkenas/backbone/pull/3827). This one should require a good example of how to create an ES6 class extending from BB

• iterator support https://github.com/jashkenas/backbone/commit/a2fc65b9798d1a5d0dcb43b5c50483640f5187c5

• Fixed a bug with the hash generation from Router.navigate (#4025)

• 4131

/cc @akre54 @jridgewell

[jridgewell]

Any others PRs we should merge?

[megawac]

Probably should get in:

• https://github.com/jashkenas/backbone/pull/3909

Perhaps

• https://github.com/jashkenas/backbone/pull/4024
• https://github.com/jashkenas/backbone/pull/3955
• https://github.com/jashkenas/backbone/pull/3884
• https://github.com/jashkenas/backbone/pull/3946
• https://github.com/jashkenas/backbone/pull/4002 (meh)

[vladyslav2]

Any release date of backbone v1.4.0 ?

Thanks for such a nice framework !

[denar90]

@megawac what about separating on several files, thus View, Model, Collection etc will be in their own files?

[megawac]

That was previously discussed in https://github.com/jashkenas/backbone/issues/1598 and #2257. Feel free to leave a comment on those topics @denar90

[typhonrt]

Greets @denar90 et al. regarding separating on several files this is what I've done presently with backbone-es6. Besides converting everything to ES6 + inline documentation I'm angling to fully modularize in separate repos all the main components of Backbone. I've already done this with Events which has no dependencies between modules or Underscore. The inline documentation is great for ES6 codebases using ESDoc (actually TJSDoc; releasing soon) for documentation generation; current API docs. I've held off on this as I thought 1.4 would have been out a bit sooner. I'm using JSPM / SystemJS for bundling distributed releases and it works great; edit: though I'm keen on getting things out on NPM when finished.

To accomplish full modularization I'll be adding an internal Events instance to Backbone to communicate between modules versus direct method calls; there are just a few points where this is pertinent more or less. The eventbus NPM module is backbone-esnext-eventbus and this allows access to several standard eventbus instances for app dev, but also internal backbone-esnext usage. I also added a few extra trigger methods for Events that are quite handy such as being able to have return results synchronously and to trigger asynchronously and receive a Promise with any results. This is rather handy for message passing for modularization and I have a nice plugin system which allows an app to autowire on an eventbus; typhonjs-plugin-manager. A nice feature too is that event registration is transparently handled for plugins by the manager and events are removed automatically when plugins are unloaded / IE plugin lifecycle.

Right now though I'm considering keeping backbone-es6 100% in sync to Backbone and likely in one repo except for Events just to make it easier to update against the mainline Backbone releases. After creating a comprehensive testing infrastructure I am however considering fully modularizing backbone-es6 then creating backbone-esnext for ES6+ usage in implementation. A primary goal there will be to remove Underscore usage internally where standard library functions exist. This already has been done with backbone-esnext-events which has no dependencies. Other goals include replacing jQuery AJAX support w/ fetch accessible via the internal event bus and making sure View / jQuery can be completely separated with the possible drop in addition of a virtual dom solution (maybe Inferno / undecided there). Having things fully modularized also gives the opportunity to play around with Ramda powered Model / Collection components to see if there is enough of an improvement over Underscore. At this point it will be easy to create custom builds of backbone-es6/esnext via JSPM / SystemJS or other bundler / build tools as requested in #1598; though I'll likely publish on NPM once things are solidified.

With these efforts I'm attempting to stay 100% compatible with Backbone for backbone-es6 and may diverge a little for backbone-esnext. I'd be glad to interface with any Backbone collaborators to see if any of this may be appropriate for the mainline Backbone effort.

[bboydflo]

What about including some basic documentation/example of how to use Backbone with Browserify or Webpack? It seems there are more and more people moving especially to webpack, but documentation on how to use backbone is lacking.

[jaapz]

@bboydflo using backbone with browserify should be exactly like using any other package in browserify, so I wouldn't know why to document this specifically for backbone.

[bboydflo]

@jaapz I am in process of switching an app from using browserify to using webpack. I also use lodash as utility library throughout my project, so I wanted to replace underscore dependency with lodash's core.min.js. I think more and more people are using webpack these days. I thought having few paragraphs about it would help them.

[akre54]

We don't officially support Lo-dash or Zepto but there should be plenty of google results out there describing how to make them work with Backbone.

See this and this for example.

[halfnibble]

@bboydflo Why use webpack? If we're going all ES6, then why not use ES6 modules with something like Rollup.js? http://rollupjs.org/

[bboydflo]

@halfnibble because I am just switching from browserify, and a lot of people are talking about webpack. It would be easier to figure it out. I heard about rollup too.

[halfnibble]

@bboydflo That makes sense. But I wonder if someday everyone will stop using custom module bundlers altogether? One thing is certain, Backbone.js will remain. :)

[ahumphreys87]

hey @megawac how far away is 1.4 from landing?

[Borming]

I would like to know that too, how far is 1.4?

[Borming]

Hello, is anyone here? Can someone get some clarification on where is Backbone heading and are there any developers left that are actually working and maintaining Backbone?

Thanks in advance

[tamalsaha]

We are also interested in understanding the future of Backbone. If the core developers are not interested in maintaining or too busy to spend time in evolving backbone, I think we should see if there is community interest in maintaining Backbone.

[megawac]

If anyone is interested in drafting a changelog and submitting a PR I think its time we publish 1.4

[jbboehr]

Does #3615 have any chance of making it in?

[tamalsaha]

@megawac , will https://github.com/jashkenas/backbone/pull/4133 work?

[megawac]

@TamalSaha we need to update the index.html file (see https://github.com/jashkenas/backbone/blob/master/index.html)

[tamalsaha]

@megawac here is take 2 https://github.com/jashkenas/backbone/pull/4134

[Borming]

@megawac no problem, please send me what needs to be done and I will help. I just want to know if Backbone is still alive,....are lead devs still working on Backbone and is there any interest in developing Backbone? Maybe even some roadmap for future Backbone releases...

Its a shame to let such a great framework unmaintained just because lead devs lost interest in it...or?

[megawac]

@Borming if you're interested in updating some sections piecemeal that would be very useful. For example, documenting using ES6 classes with backbone (#3827).

Another good one to document is https://github.com/jashkenas/backbone/pull/4061

[halfnibble]

@typhonrt I recently read up on some of your ideas. I want to see a virtual dom solution too. We could probably drop underscore.js altogether, but it would be nice to find a virtual dom solution that can render existing underscore.js template syntax. I'd like to participate in this effort. Anything you'd like me to do? Should we setup a slack?

[typhonrt]

@halfnibble I updated my above comment with a few more details. Right now I have backbone-esnext-events published and it works alone of course, but typhonjs-plugin-manager adds nice modularization functionality for autowiring events to plugins and handling transparent event unregistration w/ the plugin lifecycle. I'm using this to great effect with TJSDoc and soon typhonjs-escomplex; both of which are Node CLI apps for documentation gen and complexity analysis of ES6+, so very handy beyond web apps. This thread probably isn't the best to continue a discussion. I do have a Gitter channel if that makes sense.

[iamajoe]

@halfnibble i actually don't think that virtual DOM is the way to go.

There are a lot of options for Virtual DOM on which I would rather go. One of the advantages, for me, on backbone is that it is pretty easy to also set it on legacy projects / server rendered projects. You'll lose that with virtual dom, or at least an easy way to do so.

[typhonrt]

@Sendoushi I think the idea is to modularize Backbone and have a configuration that has a virtual dom implementation of View if so desired. I too am skeptical about vdom per se as at least in all of my efforts BB is just fine. Though I'd like to abstract View as much as possible so that there can be jquery / zepto enabled version and other flavors. At that point its mix and match the modules one wants to use. Want vdom, great. Want BB with everything but View / Router / History that's possible too.

I have a whole BB event driven GUI library built with the original material design lite that I'm upgrading to material components web. The challenge will be to see if things can cleanly sit on top of the jquery View implementation and a vdom version with minimal fuss; not that one replaces the other.

[ahumphreys87]

I created an incremental dom compiler for handlebars (seems pretty popular in the marionette community).

@jridgewell helped me to get working with backbone. Really easy, just call patch inside your views render.

https://github.com/ahumphreys87/handlebars-idom

Not on computer at the moment but I'll dig out a usage example

On Sun, 23 Apr 2017 at 18:38 Michael Leahy notifications@github.com wrote:

@Sendoushi https://github.com/Sendoushi I think the idea is to modularize Backbone and have a configuration that has a virtual dom implementation of View if so desired. I too am skeptical about vdom per se as at least in all of my efforts BB is just fine. Though I'd like to abstract View as much as possible so that there can be jquery / zepto enabled version and other flavors. At that point its mix and match the modules one wants to use. Want vdom, great. Want BB with everything but View / GUI that's possible too.

I have a whole BB event driven GUI library built with the original material design lite https://getmdl.io/ that I'm upgrading to material components web https://github.com/material-components/material-components-web. The challenge will be to see if things can cleanly sit on top of the jquery View implementation and a vdom version with minimal fuss; not that one replaces the other.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jashkenas/backbone/issues/4028#issuecomment-296463923, or mute the thread https://github.com/notifications/unsubscribe-auth/ACZOuEY8WrwSeyTZ_5l1ydVm6lp5Xekgks5ry4yfgaJpZM4IZDmD .

[iamajoe]

@typhonrt on that matter... I do agree. One should be able to select the layer view he wants. It wouldn't be that hard to even use something like Vue as a view layer if things were well structured.

[halfnibble]

@Sendoushi I have large, production Backbone.js apps too. I don't want to have to rewrite every View and Template either. To be honest, I think the JSX template syntax that ReactJS uses is terrible.

But the fact of the matter is, the virtual/incremental DOM concepts are winning. They are gaining popularity because they negate the most complex part of UI templating (partial, in-place rendering of a template). And if BackboneJS doesn't incorporate it or make it easy to use, then my favorite JS framework will quickly fall in popularity, which means bad things in JavaScript-land.

I think we should definitely look @ahumphreys87's solution.

[megawac]

From personal experience I've been using react+backbone with almost no complaints. I prefer using Backbone for Models and Collections over any other existing framework I've tried to date, but I prefer React for view hierarchy and composition. I really enjoy using react.backbone over redux for many types of applications. Although I will admit I do find support for things like react.backbone lacking and I would be tempted to switch to solutions such as react+mobx

[iamajoe]

@halfnibble there are others. you don't need jsx / react :) I use Vue for example and it has been kind of a marvellous experience.

[jbboehr]

Has anyone looked at using Backbone with the Glimmer VM? I poked around their repo, but didn't see any integration tips.

[ahumphreys87]

I've tried glimmer, seems really baked into ember ecosystem though. Really easy to use with ember-cli but Couldn't fathom how to use separately

On Fri, 28 Apr 2017 at 21:24 John Boehr notifications@github.com wrote:

Has anyone looked at using Backbone with the Glimmer VM? I poked around their repo, but didn't see any integration tips.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jashkenas/backbone/issues/4028#issuecomment-298097981, or mute the thread https://github.com/notifications/unsubscribe-auth/ACZOuBEFUJasllL4UunscNPXVe6jNq_Nks5r0ksVgaJpZM4IZDmD .

[bboydflo]

instead of vue which uses a fork of snabbdom (a virtual dom library) I think it's safer to use just the virtual dom library.

Looking forward for some more modularized backbone and support for a virtual dom view layer.

[halfnibble]

Maybe Backbone.js should have official view plugins. One for virtual dom, one for incremental dom, and one for good 'ole fashioned underscore templates.

[valleyspirit]

Here we are a year later. Thank goodness this didn't get shoved, I'm glad someone is keeping a cool head.

That's just a humble opinion nothing more, and I respect dissenting opinions. I (personally) wouldn't rush to improve everyone's hammer by hot-gluing a staple-remover to every one. Backbone and underscore are rare examples of the programming world's equivalent of elegant proofs.

Modularize backbone? Alternate virtual doms? What comes after pre-initialize? pre-pre-initialize? pre-on-pre-init?

The existing plugins and extensions should give a modest idea of what the community has patched in for itself, and thus has actually consistently needed. How many people have had issues with basic getters inside view functions, as compared to "I want to support ES6 classes, because I can"? And yet the library has remained lean and useful and extensible. As a quick example of fluff-lobbying, one of the two use-cases given for the pre-initialize merge was actually closed by jashkenas commenting one line, "Just call setElement in initialize.", and then closing the ticket. That's hardly a use-case.

Let's be sure to celebrate our ability to fork and extend. Almost none of us will have the opportunity to contribute to the web on the order of backbone and underscore, but it's very easy to pollute an ecosystem by being reactive instead of being corrective and functional. I am certainly not rushing to jam my personal backbone extensions into what I see as a rare quality open-source repo which is so easy to extend that almost anyone can do it.

I appreciate the lack of jumping off things, around here, and hope the lack continues. We've made it another noisy year without hot-glue and spinners all over our favorite hammer. I'm just thrilled no mobs have yet picked up backbone and carried it off. Oh, look, I can still use it for my next few projects! Best to everyone.

[halfnibble]

@valleyspirit I don't know that I understand what you're saying. Underscore.js can more or less be deprecated now that ES6 supports most of its useful features natively. I think it's important to upgrade a framework (Backbone) to take advantage of new features in the language it's implemented in. I'd do it myself, but—well, maybe I'll work on pull request.

[tamalsaha]

"I think it's important to upgrade a framework (Backbone) to take advantage of new features in the language it's implemented in."

I whole heatedly agree with this. Instead of just chasing all the shiny things other frameworks are chasing, I would like to see Backbone stay stable but also evolve with the language so that it does not get out-dated.

[typhonrt]

I kind of see some of the directions being discussed as continuing to make BB lean and mean and better suited to deploy web and non-web apps with a bent towards modern package managers. I don't expect the mainline BB release to change much nor the larger surrounding ecosystem to grow much at this point with how things currently stand and that is good and bad. A fork realizing some of these ideas is worth pursuing nonetheless. Even better if there was some way to provide continuity if those new ideas flourish. No one is questioning the impact BB and Underscore has and will have into the future. I assume we're all here discussing these things because BB and the ideas behind it still form our preferred framework of choice.

[akre54]

There's always Exoskeleton (https://github.com/paulmillr/exoskeleton) (disclaimer, I'm one of the contributors) if you want to go the full ES5 route. There are a couple good ideas there but IMO more often than not it's better to stick to mainline BB.

Is there something you would like to see improved that we're not currently doing?

[typhonrt]

Is there something you would like to see improved that we're not currently doing?

That's hard to say as part of it is a culture thing I suppose, so opinions will differ. I'm on the newcomer side around here as things go.

From the tech angle for instance I'd be a bit bearish so to speak in regard to adding "mixin" to Collection & Model, but that assumes moving forward and being bullish with an ES6+ BB version.

If there is one thing that has been a big boon with the modification I've done thus far it would be the Events update: backbone-esnext-events. Adding async / sync trigger & return of results is what I'd consider low hanging fruit for merging back into mainline BB. However for async it kind of assumes ES6 otherwise a separate promise module would be necessary which is undesirable. This modification opens up tons of modularization possibilities to use events for in-process messaging and is the corner stone for future efforts.

This is not really an improvement, but for those like myself that are going to venture out with an ES6+ BB reorganization and modularization it'd be nice to keep an open line of communication going with mainline BB maintainers.

A tech angle that would be nice to have in this regard is figuring out if the tests can be shared between efforts which is something I have to look into at some point. If this were possible, but a few slight modifications were necessary it'd be nice to work with the mainline BB maintainers in this regard.

[tamalsaha]

So, can we have 1.4 now that changelog has been added?

[megawac]

ping @jashkenas @jridgewell @braddunbar

[Borming]

BB and ES6 works perfectly, event mixed with Marionette. What i would like to see is more support and more "life" from BB developers. Marionette is doing a great job at promoting and maintaining their user base and eco system, i would like to see the same from BB.

One user said that its not good to glue shit on a hammer that already does the job, and i agree, but what i would like to add is that the hammer needs improvments to be better and do the job better then it does now. ES6 is one of those things.

I hope someone jumps on board and makes a BB fork with full ES6 compatibility and puts some life back into BB because we all agree, Angular is shit :)

[ogonkov]

May be start dev branch with BB code transferred to ES6? We could split code to parts and add Rollup to effectively build distributable version

[typhonrt]

Respectfully to all, @ogonkov already done / backbone-es6, but I've used JSPM / SystemJS for the distribution versioning which can use Rollup for bundling as well. After BB 1.4 drops I'm thinking of making a BB version that fully embraces Babel / "esnext" / stage 2 perhaps with some extra modularity between elements of BB and a focus on native functions versus library usage.

[paulfalgout]

The https://github.com/typhonjs-backbone/backbone-es6 is nicely done and interesting, but it is breaking and requires deeper inheritance with events instead of treating as a mixin like Backbone currently does. I would definitely support a modular ES6 backbone, but I'd like to see it in smaller iterative, non-breaking steps.

[typhonrt]

@paulfalgout >it is breaking and requires deeper inheritance with events instead of treating as a mixin like Backbone currently does.

This is mainly due to documentation purposes. ESDoc at the time and many other documentation tools including TJSDoc (which I'm just finishing) don't work with mixins as knowledge of how every frameworks mixin API / library would be necessary.

I personally think deep inheritance and mixins are generally an anti-pattern versus explicit composition when static types are not available especially when it comes to core framework code.

As I recall this was the only change, but effectively backbone-es6 works the same as BB mainline so this isn't exactly a breaking change though I haven't got the mainline BB test suite hooked up against it which would be a nice thing to have for proof of compatibility.