Hacker News new | past | comments | ask | show | jobs | submit login

I'm surprised that you're using Meteor for what would seem to be a single-user use-case. Meteor's strength seems to be multi-user real-time apps, but this looks more like a job for Angular/Ember plus an API backend.

I was looking toward Meteor for a similar project because of its handy client-server syncing capability, but decided not to use it because it didn't seem to suit the more traditional webpage model and the click-to-save-changes paradigm. But your site is making me reconsider this. I've been learning and implementing my site in Angular/Restangular, which involves me writing code to POST to/GET from my Rails backend. I'm aiming to let users add and remove nodes in a plan/document and rearrange their ordering - would that be easier to do in Meteor? I'd love to make use of Meteor's object syncing and other features. What's your experience been like? Did you try Angular or other JS MV* frameworks?

By the way, I love your site's design and iconography. If you built the whole service alone, I'd be very impressed.




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.


It's cool how it does the multi-user realtime stuff, but if you think about it, that's solving problems that almost every networked application deals with (latency, consistency, etc) but in more subtle ways. I'd say really its strength is just how amazingly simple and easy it is to get something going.

It's been a year since I played with it, but at least at the time the weak side seemed to be integrating with any existing systems you may have, whether front or back or middle or sideways. In those cases the magic doesn't work for you and you've got to figure out how to plumb it. (Again this may have improved in the past year.)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: