General ideas for Spine version $Next

[adambiggs]

Given the recent buzz in this repo, I wanted to open up a dialog about ideas for the next big Spine release (v2.0 maybe?). I have more open-source time coming up, and would love to contribute it to Spine!

Here's my wishlist:

• New API for Spine.Model based on Alex's Gist
• @find() to return falsey for missing records instead of throwing exceptions. (discussion in Fix #427 #428)
• AMD support via UMD (See comment)
• CoffeeScript source maps (CoffeeScript source maps! #431)
• Inline docs via Literate CoffeeScript (Include Spine docs in the main repo? #433)
• Updated version of spinejs.com
• Swap out Cake for Grunt/Gulp/other?
• Refactor tests as CoffeeScript, switch to Mocha & Chai, and run CLI tests via mocha-phantomjs (See comment)
• Refactor Spine.Stack to allow nested stacks & handle multiple routes properly (Why not mutil match in Spine.Route ? #373, Multiple event listeners for one route #398)
• Storage callbacks (Storage could take callbacks #371)
• IndexDB storage module (Support for IndexDB/WebSQL instead of localStorage #343)
• Simple many to many model relationships (I have a module to contribute if there's interest)
• Ability to include related records in @toJSON() output (I've also got code for this)

Edit - More stuff:

• Return promise objects from any relevant async methods (Update Spine.Ajax's Queue To Return Promise Objects. #328, Add always callback option on methods that trigger ajax. #429)
• Module for live-binding between models & views

Thoughts?

[cengebretson]

I think most, if not all, of those points are definitely worth looking at. I do like the idea of using literate coffescript for the documentation. And I think it does make sense to have the spinejs.com website built entirely on an all javascript platform :o) I'm glad that spine is coming back to life, even with the amazing number of javascript frameworks popping up I feel Spine still has its niche in that its simple and feels light weight.

One other area I want to dive into is improving the Hem project, feels like there is a lot of potential there to make spine even easier to use, but I'm interested to hear how others are compiling their spine apps.

One thing I think would be very slick with spine/hem is to add a livereload type of feature where changes to css (or even views) would be displayed in realtime without having to reload the browser. I just started looking at this so it has a ways to go but feels very doable.

[texastoland]

👍

[MylesPenlington]

AMD support gets my vote. Was on the plan but a bit further away. Had not looked at in detail. Was working from the point of view of a composite UI loaded from many different services/ URL's so was thinking that it would require loaders.

Map files gets my vote too!

[aeischeid]

Pretty decent roadmap there!

I think what is in master now is getting close to ready for a 1.1 release. After that I could see us switching to only maintenance mode on spine 1 while focusing on getting a spine 2 out. Of course version numbers are as arbitrary as we want them to be I guess. Maybe it is more like a 1.2 release? Open to other opinions on that, as I don't really care to much either way to be honest.

I agree with @cengebretson that one of the killer features of spine development is, or could be, Hem. If others don't agree about Hem in particular there are other tools out there like Yeoman. The point being that we want spine to be awesome for developers and I think designing spine with a tool like Hem or Yeoman in mind is essential, and should be a priority on a roadmap such as this.

[adambiggs]

The point being that we want spine to be awesome for developers and I think designing spine with a tool like Hem or Yeoman in mind is essential, and should be a priority on a roadmap such as this.

Agreed. We don't use Hem because at the moment we have a PHP back end. We've put together a dev stack very similar to Yeoman, and in fact plan on restructuring it as a Yeoman generator before starting our next app.

I've never even really looked at Hem, so forgive my ignorance... But would it be easier/more flexible to create a Yeoman generator for Spine instead of maintaining Hem? Does Hem do stuff that Yeoman/Grunt can't? It seems like Hem might be a niche of a niche :)

[maccman]

Looking good!

On Fri, Mar 15, 2013 at 8:58 AM, Adam Biggs notifications@github.comwrote:

The point being that we want spine to be awesome for developers and I
think designing spine with a tool like Hem or Yeoman in mind is essential,
and should be a priority on a roadmap such as this.

Agreed. We don't use Hem because at the moment we have a PHP back end.
We've put together a dev stack very similar to Yeoman, and in fact plan on
restructuring it as a Yeoman generator before starting our next app.

I've never even really looked at Hem, so forgive my ignorance... But would
it be easier/more flexible to create a Yeoman generator for Spine instead
of maintaining Hem? Does Hem do stuff that Yeoman/Grunt can't? It seems
like Hem might be a niche of a niche :)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/434#issuecomment-14968866
.

Alex MacCaw

+12147175129
@maccman

http://alexmaccaw.com

[adamrights]

+1 to a yeoman workflow. I've spent the last few months using yeoman and tinkering with aura.js -- but I was always a fan of Spine after reading Alex's book. I'll keep a closer eye on this repo and see if I can help anywhere.

[zohararad]

Not sure if this deserves a separate ticket or should be here, but I'd love to see Spine v1.2 remove jQuery-specific code (in particular inside Spine.Ajax) so Spine can be used with Zepto / Tire with greater ease.

[adambiggs]

@zohararad I've never used Zepto or Tire, but I was under the impression both their APIs were compatible with jQuery's API.

[aeischeid]

the tests for the ajax and routing modules are currently jquery dependent, and that is something we should fix, but I don't think the modules themselves should be. I like the idea of supporting zepto at least, at some point it will be quite a bit of work to keep up with the nuances of incompatibility between multiple libraries. So unless someone jumps in to help with that task I am thinking tire.js is not going to be officially supported.

[cengebretson]

Not sure if zepto, at least by itself has all the promise/deferred functions available that the ajax module is dependent on. I could be wrong on that, but at first glance that stood out...

[metaskills]

Just saw the list above, I am the author of mocha-phantomjs and I would love to lend a helping hand if that bullet point moves forward. Cheers.

[metaskills]

Also, perhaps double down on returning promise objects for model.save() and the like as started in the work in #328. Again, this would semi-concern the base implementation with the possibility of extensions like ajax driving the return value. To me, this makes sense.

[adambiggs]

@metaskills Sounds great! Love your idea about promise objects too. Added it to the list above :)

[00defeat]

How about allowing for a custom idAttribute? Also adding instance done and error callbacks to fetch?

[aeischeid]

Still a fan of this roadmap!

Currently in dev branch and lined up in the pull request queue we have a handfull of good features and enhancements. Feels like we could do a release soon, but also feels more significant than a 1.1.1 type release, so maybe we should bump this discussion to be spine ++ spine 2.0 or whatever and the upcoming release is 1.2.

[cengebretson]

Another thing to perhaps look at for version 1.2, https://github.com/component/component. This would allow another way to install/use spine. There is bower too, but it looks like component uses commonjs for packing so it should be fairly easy to support.

[adambiggs]

@cengebretson Personally I lean towards Bower since we use it for our projects and it has a bigger community. Plus @maccman is one of the Bower authors 😉

[cengebretson]

I honestly haven't dived in to deep into javascript package managers for the client side. But I like the idea of providing alternative methods for downloading/using spine. The part that looked interesting to me using the component method is that it could potentially allow a user to install different parts of spine (probably would require some code restructuring).

Say for example somebody wants to use the controller part of spine without needing to use the model/event code, they could just install the controller component (and probably have some other way to model data). Overall it seems like spine could have several components: controller, model, routes, and manager that could exist on their own independent of the other.

But maybe in real world cases developers wouldn't do this, just thought the component model is an interesting approach/idea to be able to pick and choose the pieces you wanted...

[johanlunds]

Perhaps investigate implementing the controller release feature explained by Alex in http://blog.alexmaccaw.com/jswebapps-memory-management.

[adambiggs]

Not that this is an official roadmap or anything, but I just removed AMD support from the list.

Took a stab at it a while back, and found that AMD didn't like it when models dynamically required related models... Along with some other more minor issues.

Given that ES6 modules are coming natively, It's probably best for people to use Browserify or wrap Spine in an AMD shim as needed until the dust settles.

[adambiggs]

Just removed the item about refactoring tests. This would end up being a lot of work without any tangible reward...