Can I ask which meetup you've been attending? We (the organizers of such meetups) would love to hear where you're having a great time!
2,627 karma · joined May 19, 2010
A talk demoing it: https://youtu.be/puoD7b4Ow7k
Here's how to integrate AngularJS with Meteor: https://github.com/Urigo/angular-meteor
A talk demoing it: https://youtu.be/s6IgKYsZAyI
It's not "tightly coupled" to MongoDB; Mongo is simply the only database that livequery (https://www.meteor.com/livequery) has implemented support for at the moment. There are community projects for MySQL and PostgreSQL, as well as partially complete drivers for Redis and Elastic. Official (My)SQL support is on the roadmap and will probably appear later this year.
"Writing software is too hard and it takes too long. It's time for a new way to write software — especially application software, the user-facing software we use every day to talk to people and keep track of things."
1. Meteor isn't a client-side framework, it's a full-stack platform;
2. This post was written by a member of the community, not someone on the core team, so I don't think you can say "desperate to jump on the React bandwagon"
If this isn't what you meant, ignore my post, just wanted to mention those two things :)
You can switch to Firebase (https://atmospherejs.com/mrt/firebase) or Parse or even REST APIs if you want. Someone is even writing a reactive MySQL driver (https://github.com/numtel/meteor-mysql).
You should take a look at the Roles package: https://github.com/alanning/meteor-roles
I recommend taking another look at Meteor's security because although it's different to other platforms, different doesn't mean inferior. It's actually very powerful and simple once you get the hang of it.
Lots more: http://www.quora.com/What-are-some-startups-using-Meteor
Visit http://meteor.com/about and you will find this:
> [...] a new platform for cloud applications that will become as ubiquitous as previous platforms such as Unix, HTTP, and the relational database.
Meteor is not "an MVC framework", it is a platform for creating applications. The investment seems to reflect the ambition described on this page and after having watched them execute over the past two years, I'm glad they're funded, because it clearly enabled them to continue working on this without running out of steam and having to go back to their old jobs.
They have also been quite open about their future plans for making money, such as in the post announcing their funding back in 2012: https://www.meteor.com/blog/2012/07/25/meteors-new-112-milli...
> Eventually, we plan to make a commercial product too, called Galaxy. Galaxy will be a product that the operations department at a large company might buy. It'll be an enterprise-grade, multi-tenant hosting environment for Meteor apps.
There are more and more solutions and patterns emerging every day as more and more people try building complex stuff in Meteor, though. Just look at some of the packages by Arunoda like fast-render, subs-manager, and kadira: all designed to ease development around common bottlenecks you run into as you start to scale up.
In other words, I think this problem will eventually go away as more people keep trying.
Just like it did with Ruby on Rails 8 years ago :)
The site was developed by the same teams who created the Rijksmuseum website last year and uses some of the same technology.
I'm not sure why you're claiming Backbone isn't an MVC framework. It was pretty much designed to be MVC or at least MVVM, and checking the Backbone website, it still says it pretty much in the first paragraph: models, collections, and views. That's fine, but I like Meteor because it doesn't need the MVC crutch to provide structure and elegance. Somehow, it gives me more power as a developer without also asking me to write the kind of boilerplate code normally associated with data binding, getter/setters, models, and things like event emitters.
If you still prefer Backbone, that's great! But I just wanted to explain to the OP that for me, Meteor is about getting rid of spaghetti code, not adding to it.
For web apps, I tend to define spaghetti code as the huge layers of glue and boilerplate you have to write to get your data out of your database in the server, serialized into some JSON or XML format through your controller in order to send to the client and into an XHR callback hell or confusing promise-driven architecture, all so that you can finally concatenate everything into a string inside some jQuery function where you then have to manage your own state.
None of which even comes up when building with Meteor, since it takes care of all of that for you, leaving you more time to build your app. So as far as I've experienced building apps in Meteor for two years, spaghetti code is a thing of the past. Not to mention that just the fact that the API works this way dramatically simplifies your application architecture just as a side effect of how the templating system, reactivity and javascript-everywhere approach work.
Yes, there are MVC frameworks like Angular and Backbone that help you take care of the client side of that. But they don't handle the server at all, so IMO they still haven't matched Meteor's feature set.
Our product is for HTML prototyping and intended to be used for making quick interactive mockups of web apps and sites. Part of the reason it exists is because we've always felt that you need to write code to accurately mock interactions; just using canned stuff provided by most drag-and-drop interaction design tools doesn't cut it. We launched in 2010 and in the four years since, no one has really addressed a similar niche.
Framer seems to be a cool alternate approach: first off, it's focusing on mobile apps and small touch-based interactions with a lot of animation. That's great since that's where the market is now. But it's also different in that it looks like you only write Coffeescript and no HTML or CSS. I guess that's a good development too, since during prototyping you just want to describe behaviour and not focus on managing semantics, document structure, styling, etc - best to just have the tool handle it for you through the abstraction provided by FramerJS.
Good to see Framer is being developed by fellow Dutchies, too! We should organise a prototyping meetup or something. :)
Also, please allow user interaction while things are loading. Right now when I drag the map around, the UI freezes and I can't do anything, which comes across as poor performance (locking), and some may blame Meteor. Just let me continue doing my thing as stuff loads.
Sit down with 2-3 people (including someone not in the Gittip loop!) this weekend and list all of the nouns and verbs that you associate with Gittip's mission, its market, what users do on Gittip, and what people achieve through Gittip. Then pick one of those. Register the domain. If it's taken, use 37signals' approach of appending "app", "hq" or some other unique identifier to it. It will only take up as much of your time as you allow it to.
When I visit the homepage, I see "Sustainable crowdfunding: inspiring generosity", followed by a call to action input asking me to enter someone's username, and finally three groups of lists of people. None of these things mean anything to me if I'm new to Gittip.
The headline at the top describes your company mission statement, not what the product does. Instead of telling me the abstract of what Gittip is about, it should tell me the benefit of using your product. For instance, "Support your favourite people by automatically donating to them weekly." Skip the generosity, sustainability, and crowdfunding mentions for now. Put them behind the About link, which I might click if I'm interested in learning more about how and why you're doing this (I'm probably not).
The call to action input doesn't help me much. It's asking me to enter someone's name off the top of my head, and it's using a very vague label ("who inspires you?") to do so. I would scrap this approach and instead provide a way to sign up to Gittip with a call to action that ties back in to the headline. So you want to donate to people you like? Step 1: sign up for an account. Step 2: add people from your Twitter, Github, Facebook, etc. Step 3: Look through the list of people (Gittip should use some magic to prioritise the people by likelihood of my wanting to support them, such as looking at how close they are to me on Facebook, or how many followers/stars they have on Github and how many of their projects I've starred) and select up to 3 that I like. Done! Step 4: Decide to give someone something minimal (say, $0.25) per week by entering my credit card details. If I choose not to do that, at leat I made a profile on the site, got familiar with how it works, taught you a bit about who I am and where I came from, and you can maybe email me later and remind me if someone I have in my friends list did something interesting (like published a new project, blog post, insightful tweet, etc)
The list of people at the bottom of the homepage is boring. It's not contextual to the goals of the homepage, which are converting users to understanding Gittip and wanting to join in. Right now you show me static lists of new users, top givers, and top receivers. I don't really care about new users other than as proof that this site isn't dead, so you can reduce their importance right off the bat. Top givers and receivers aren't relevant to me unless you tell me what they're giving or receiving. So I would reformat these lists: andyet gives x per week to a, b, c, and more. ashedryden receives x per week from a, b, c and more. I need to understand that Gittip is about creating a direct personal relationship between people giving money and receiving money. Right now, these lists don't imply any kind of relationship.
I also think you need to revise the name. I know you've decided that "Gittip" is just a new word and shouldn't be understood as a portmanteau of git and tip, but it's a terrible, hard to remember, hard to spell word. "Giddip? So with a D?" "No, with two T's" "The heck does that mean?" "I dunno, it's just some weird word" -- you're missing the opportunity to give the product a memorable, clear, unique name that either represents your product as it stands apart from competition, or is memorable and quirky enough that it just sticks. Patreon got it right: it evokes "patron" but it's slightly different, so you can intuitively guess what it's about and still remember the brand itself.
I recommend reading the book Seductive Interaction Design by Stephen Anderson: http://www.amazon.com/Seductive-Interaction-Design-Effective... - it will help you combine your existing ability to reason about the product with some basic psychology and mental modeling that will allow you to word things in such a way that the benefit is more clearly communicated and you're speaking to the user instead of rambling about the company vision to nobody in particular.
Good luck with Gittip in year 3. I'll be watching - and giving :)