Re: the choice for Meteor, this was somewhat of a fluke. I'm not a traditional developer, and only dabbled with Rails and the like on an anecdotal basis. My past experience with things like jQuery made it easy to pick up Meteor and its basic concepts, so I just started building the app above (it's something I really wanted/needed and I didn't want to waste a lot of time inner-bickering about what tech to build it with).
I guess for your idea I'd have to see a sketch, but on the surface, yes, I'd say something like that would be pretty easy. The cool thing about Meteor is that it takes a lot of the thinking/logic out of the loop. So for example, you would have the nodes as a Mongo collection and for each plan/doc, just store their position info. Meteor/Mongo update automatically, so if say you used something like jQuery UI drag/drop, you would just have it update the given object in Mongo when you pick it up or put it down. Make sense?
My overall experience has been that I haven't gotten frustrated with Meteor like I did with other frameworks. It's not as rigid, sure, but if you take the time to develop a good design practice, it can be really efficient. Plus, having both front and backend code in JS is a serious time saver.
Thanks for the complements on design. Save for the octopus, logo, and animated gifs outlining the process (oh, and the nice header on the blog), this was a 100% solo effort.
Comments
Re: the choice for Meteor, this was somewhat of a fluke. I'm not a traditional developer, and only dabbled with Rails and the like on an anecdotal basis. My past experience with things like jQuery made it easy to pick up Meteor and its basic concepts, so I just started building the app above (it's something I really wanted/needed and I didn't want to waste a lot of time inner-bickering about what tech to build it with).
I guess for your idea I'd have to see a sketch, but on the surface, yes, I'd say something like that would be pretty easy. The cool thing about Meteor is that it takes a lot of the thinking/logic out of the loop. So for example, you would have the nodes as a Mongo collection and for each plan/doc, just store their position info. Meteor/Mongo update automatically, so if say you used something like jQuery UI drag/drop, you would just have it update the given object in Mongo when you pick it up or put it down. Make sense?
My overall experience has been that I haven't gotten frustrated with Meteor like I did with other frameworks. It's not as rigid, sure, but if you take the time to develop a good design practice, it can be really efficient. Plus, having both front and backend code in JS is a serious time saver.
Thanks for the complements on design. Save for the octopus, logo, and animated gifs outlining the process (oh, and the nice header on the blog), this was a 100% solo effort.