I tried to sell them but luckily almost got scammed, bank refused transaction and I didn't lose much. So i ended up keeping 8 BTC still :)
1. You're young and still figuring out what you love doing; no better time to experiment and learn. I still have fond memories over the php site I wrote in high school. You could visible tell which functions were written at the beginning of the project versus the end because you'll improve drastically. 
2. The project will be more successful with someone who cares for it. Hiring a contractor will make it difficult for you to maintain and improve. Contractors will also expect a specification with penalties if you need to change it. My guess is that you're still experimenting with what can best serve the community so this probably isn't a good fit for contracting as well.
 Recommended tech stack (optimizing for documentation and availability of help). Ruby, MongoDB, Heroku (or if ambitious, Linux on Amazon EC2 + nginx). Everything else is pretty similar so once you learn these, the concepts apply reasonably well.
p.s. If money is a concern, you should look into contacting some companies PR/DevRel people and see if they are willing to donate some compute time or services to your cause. (It's probably doing this after launch and getting a better sense of usage and will be easier to convince them that you're legit).
* Anonymity is vitally important, especially since you are an inexperienced programmer with a high risk of introducing security holes. Don't collect any personal details (including email addresses) that could cause problems for people if they were leaked. Don't implement Facebook or Google signin!
* If there are any social components at all, consider the potential impact of trolls. This project may require 24/7 moderation.
* This is a major emotional commitment. Talking down suicidal strangers is not something to go in to lightly! Make sure you have a professional advisory network in place.
Since lots of people have offered to help, I suggest getting them added to a mailing list ASAP while they are interested.
You could consider building the project in public on GitHub - that would allow technical advisors to review your code for you and use the issue tracker to discuss features.
This list of cognitive distortions and how to fix them might be relevant:http://www.apsu.edu/sites/apsu.edu/files/counseling/COGNITIV...
This was created by Dr. David Burns and is supported by research in cognitive therapy. The full information is available in his book "Feeling Good". The interactive medium could afford some interesting possibilities.
Another thing that I remember reading is that tracking your happiness level and sharing that information with others seems to improve mood. Somebody was experimenting with this on the web. Seems like a perfect fit for a social app.
I second the opinion that you should make sure that you pay attention to research. Some common sense approaches might be counter-productive. For example, the clich: "suicide is a permanent solution to a temporary problem" can make suicide sound even better to the seriously depressed. Be suspicious of common sense here.
An app like this, especially if it were wildly successful in attracting users, could do a lot of harm if the underlying idea isn't thought out well and based on good ideas. You're 15. You love your idea and the competition judges did too. Great! Are you or them experts on suicide prevention?
Fortunately, your goal isn't to make money or something similarly self-serving. You're trying to save lives. That opens up tremendous resources to you what would be denied to most trying to make their first app. Psychologists, doctors, professors, etc. will all be happy to help you get the idea right, free of charge, because it could save lives.
If you see a psychologist, ask them for their input and ask them for contacts. Go to your local university and knock on doors. Find people who teach or do research in the field and ask for their input. Make some phone-calls. Email professors at other universities.
I know your instinct is to immediately try to advance your idea towards a working app, but a great app based on a faulty idea is usually pretty useless and this one could actually be dangerous. Get help immediately.
All the advice you get here, much of it good, and all the advice you will get throughout the project (especially if you open source it on github which I highly recommend) is for you to assimilate and then build into your opinion.
Listen to experienced dev's telling you why and why not a particular course will work, listen to people here on the research and the unintuitive nature of suicide, but in the end this grant was given because you seemed to have an insight or a gleam in your eye.
Trust that gleam, and tell us lot to go hang, if you think you are being pushed into something that in your informed opinion is not the best for the app.
And remember, Its not the only suicide prevention work out there, so the weight of the world is not on your shoulders - your job is to do a good job and be proud of the work. Let the world decide if thats going to solve its problems or not.
Good luck and all the best
I hope you get offers to work on the backend with you. If not, here are some ideas:
(1) Find a like-minded person at meetup groups. The Atlanta Ruby User Group, for example, has a contingent actively working on public good kind of apps, things more for non-profit work than for-profit work. While your local technical meetup group is a good place to start, there is nothing stopping you from emailing the ATLRUG mailing list and asking. There are other platform meetups you can try, like ones for Node.js, Erlang/Elixir, various Python groups, etc.
(2) Use the Tim Ferris method of calling up famous people. You never know. Being someone versed in JS, you could try Resig, or Katz, or the AngularJS core folks. You could also try one of the startup CEOs/CTOs you admire. I don't think someone's work should be judged on the novelty of being young, but it happens (people think, could I have pulled it off at your age?) Older folks who have amassed experience and power like teaching and mentoring young people, as it is not as threatening to one's power base as young competition. You might not necessarily get such a person to work directly with you on the code, but you're likely to get access to a network that you normally would not have access to.
(3) Scour the web for other similar competitions and contact the winners. Maybe you can trade.
Considering the fact that you already received a grant, I would imagine you have a few details of what you want to build, but you will find the real tangles in the details.
I would greatly advise that you dive deeply into the various requirements and untangle the details and drive clarity throughout the design, before you start writing a lot of code.
Once you feel comfortable that you won't run into any big surprises and you understand your general feature set you should prioritize these features, I like to do the most risky and difficult features first, and then get started. You will of course have a lot of ground work to lay, but that could be counted as a feature.
After you have your first shippable set of code done, should take between 2 weeks and 2 months, shouldn't be perfect. Get it in front of someone that's relevant. As it will be hard to find somebody suicidal that also wants to review an app, probably somebody at a crisis center or a counselor that helps people in this situation.
After a few demos you should find plenty of improvements and features you never thought of, as well as defects. Now it's time to add these into your priorities and start over.
Good Luck, I hope this goes well for you. Let me know if you would like any further advisement, I would be glad to take emails and what not. I have been developing software professionally for the past 3 years.
Background, I've been suicidal many times in my life, having spent >3 weeks in the psychiatric hospital. Been in the mental health system for YEARS. Been around many many many suicidal people in that time.
This seems so naive. You have a lot of legal issues here, and also social and ethical. You want to make sure you are cleared legally, you want to make sure you are not violating HIPPA. You want to make DAMN sure you are doing the right thing, and not encouraging the behavior you are trying to prevent. You are describing this as some kinda "social network" and there are studies that social networks can make you MORE lonely and depressed.
You want the help of a trained psychiatrist for god's sake.
You want to be damn sure you "suicide prevention" app doesn't get overwhelmed by trolls and well meaning people giving bad advice, and if it does, you aren't legally on the hook.
This is just way too big. This isn't some weekend project. This really really is serious business. Don't do it. It's way too risky.
So many of the little hobby projects I've worked on over the years (long since abandoned) have provided a fantastic base for something else. A website I managed when I was a teenager taught me all sorts of server admin skills that still pay off 5 years later. When you're 15 you have absolutely oodles of free time (it might not seem that way now, but it will when you're working full time!). Make use of it!
I'd recommend you ping Prof. Joshi at Stanford, who was involved with a suicide prevention program in Palo Alto. And if only to run your idea by him and solicit some feedback.
This is a video of him talking about suicide risk factors in teens: http://www.youtube.com/watch?v=9lIqp6odvp0
I suggest you check out node.JS, it's easy to learn since you have a JS background and it should handle well with what you're doing.
Also if you're intrested, I'm willing to help out for free, you can contact me at: email@example.com.
If you disagree, fine, but have an informed opinion.
I suspect a project like this has more complex Governance, Risk and Compliance issues than most. Where possible, work with an existing charity working in this area, as they should already have practices in place to manage this.
There's very little description of what it would do beyond that it's an app and it prevents suicide. And that it's a social network. That really isn't enough to describe the idea.
I can see the possibility of a social network site for depressed people.
Dunno. It's a big goal, but very hard, and I think it's extremely important to take into consideration the mentality of someone who is considering suicide.
Now whatever happens next, it will only be valuable. You will only learn things from that point, outsourcing is not an option when you're willing to learn. Because this is an opportunity to learn, it is not an opportunity to succeed.
1) Determine how much back-end I really need (or whether I need one at all). I'm going to assume your grant proposal contains use-cases (or user stories) that describe the interaction with the back-end.
2) Decide what framework(s) your front-end will be using and make a list of the back-ends that you believe would work with the front-end.
3) Define the interface between the front-end and back-end ... an ICD or API document will help you with both sides of the connection.
4) Find a mentor who can get you started with your chosen back-end technology as well as help you out when you get stuck.
I'd use this as a means to learn at least a little about back-end architecture. On the other hand, you could ignore the typical back-end development and go with something you know - e.g. CouchDB uses a RESTful API to store JSON documents, provides facilities for making views, lists (an HTML transformation of a view) and shows (an HTML transformation of a JSON document.
4) Find a mentor who can get you started on the chosen back-end, and help when you get stuck.
I think you should spend a grant on your education and skills related to the app. This is a sustainable approach given that the grant is not really large and you are in the exploratory phase of your project.
Do everything yourself while consulting with the community non-stop, lots of people will be eager to help you.
Btw, I consult startups on marketing and I think your story is straight techcrunch/mashable/thenextweb material, ready to inspire other young people to learn programming. If you need any help spreading your mission, this app or teen2geek, for the greater good, just drop me an note, I'll be eager to help you pro bono. My e-mail is in the profile.
As an example my partner volunteers with a suicide prevention hotline that also has a chat client, I'm sure they'd love something mobile that works with their chat system, etc.
I've got a lot of years doing backend work, and I'd be more than happy to help pro bono.
I personally would not get too hung up on the stack you use. Find something that will get you up and writing tests and building pages as quickly as possible.
Discussions about various stacks usually have to do with scaling and scaling usually is a problem after the prototype stage (which is the goal I'm guessing).
Up and coding.
I also agree that you should do the bulk of the work yourself. The knowledge you gain will be priceless, and in today's software development world, it is helpful for front-end guys to know what the backend guys do and vice-versa.
Certainly lean on people here for help and advice, but I wouldn't have someone do all the backend work for you.
Good luck to you!
Anyway, I wish you good luck.
Some people are suggesting research. I'd be interested in suitable papers and organisations.
One good place is the University of Oxford Centre for Suicide Research:
Whoever gave you this money isn't expecting you to build a suicide prevention app directly. They are saying that they like your idea, they like you, and they want you to keep at it. It's a grant, not a loan so don't worry about treating it as a loan.
Use it to get some training you might want, use it to set up a business and learn about business, use it to buy a piece of hardware you might otherwise not be able to afford. Use it to further your chances of eventually being able to make a difference, don't put pressure on yourself to make the absolute most of it.
Lastly, put it on your resume.
As others have mentioned, due to the sensitive nature of a project along these lines, I would strongly recommend finding a mentor in the psychology realm. You'll want to make sure that you carefully consider some of the functionality aspects of the app to make sure things won't be unnecessarily/accidentally harmful.
You could (carefully) curate a list of this sort of advice from people who have actually felt suicidal at one point or another and pop up a random message on demand in the app. Carefully, as most cheerful advice does not sound so good when you are depressed.
They do a lot of work in this area and will have the best advice on what things you can do to help.
Best of luck.
And maybe reach out to other suicide prevention non profits?
Take it all with a grain of salt. What I'd suggest to get started is create a public github project for it, put together some wireframes and sequence diagrams (publish them in the github project) so that people can see what it's meant to look like and how it's mean to work. Then just start coding.
Post the github project here on HN and ask for contributors. Keep a curated list of features, tasks and bugs in the github project and let people pick them up and help you build it.
Rule #1 though, don't let people get you down. Everyone has an opinion and we software people can be pretty harsh, especially when, frankly, we're just arguing our opinion rather than fact.
Rule #2, done is better than perfect. What's your Minimum Viable Product? Build that, maintain tunnel vision on completing that, then worry about everything else it could do.
I can do the literal translation, and I can surmise that it means a person who builds and designs UIs, but I always thought that was a designer, not a developer.
I also think you should come at this with a dark sense of humor. You're not going to save many lives if you don't get attention, and you're not going to get anyone's attention if it's Just Another Web App. Tasteful gallows humor is a good way to grab the audience you're looking for.
I suggest you open source all of it, and keep HN up to date on progress. List out what the product should do, and how you want to design your models. You'll get some solid feedback.
Web iterates fast, so I'd use web rather than jumping right into native. You'll be able to show your code to coders, and show your product to social workers and those who support at-risk people.
Having said that, I am not sure about the time constraints you are working with. If the timeline is tight and you have never done this before, it's better to outsource it as opposed to building a sub-standard app yourself.
I'm actually working on an application (www.happsee.com) for tracking happiness. Somewhat similar, but not exactly. It's already had some huge benefits for me as far as understanding my own emotions.
If you want to chat more about making an app (mine is for android), machine learning (predicting stuff from other stuff), or building a backend, let me know. Email is in my profile.
On the projectside: Cool that you would take your time and skills to work on a project like that. I had the sad experience of losing someone close through suicide, so... yeah. Thanks.
And the correct answer is nothing stops them from doing that (or even stops them from having done that in the past).
Its generally presumed that they haven't and won't because it is presumed the cost to do so would exceed the value to the government of doing so.
The question I would have is what objective would that satisfy? Is there some power in holding a slight majority of the currency? I mean, they already hold quite a lot of regular cash (or at least do transiently), but that doesn't seem to be affecting dollars in the same way that shares in a corporation does.
Perhaps I'm missing it, but I don't know what significance would arise from a single entity holding a majority of the currency. If there is, and I'm clueless, my apologies.
To buy it, they would borrow the money from China. China would provide it by using the BTC they own at whatever price they choose to sell it at.
You could also consider looking for a legal team member or mentor that could either contribute directly or steer you towards an attorney experienced in this space. As I've said for a while, having a plan for your legal needs is just as important as having one for server infrastructure etc. There are more legal grads than there are legal jobs at present so this might a good time to seek a business-minded cofounder with legal training.
If you're not sure where to start, call the bar association in your state and ask for a referral. You could also consult DIY legal texts such as the NOLO series, which are often quite well written and helpful, but knowing nothing about your business it's very hard to say how well or badly they'd fit your needs. Also, they're mainly aimed at consumers so I don't know if they'll cut it for B2B stuff.
The Small Business Administration has general resources: http://www.sba.gov/category/navigation-structure/starting-ma... or this affordable book provides an excellent introduction to the general principles of business law and the sort of situations any business owner should be prepared to encounter (the whole series is good in fact): http://www.amazon.com/Business-Law-Barrons-Review-Series/dp/...
Why, because I had $30 to waste and wanted to learn about it. Bought a simple USB miner. Using a pool at at 0.00063331 BTC since Saturday morning. Pretty sure I am never going to break-even, but it was just an experiment to try and understand Bitcoin.
If the date 2004 worries you, then download a draft of version 3 of SWEBOK here http://computer.centraldesktop.com/swebokv3review/ and click on SWEBOKV3_Ballot_public.pdf on the left sidebar of the page.
Actually, if you want to put together a plan for self study, then work through SWEBOK and Google for papers on the various sub topics covered. One thing about software engineering is that just about all research is published openly on the web particulary in CiteSeerX.
Your app can fuck up a LOT of things, and maybe you'll lose users, or maybe you'll lose marketshare... but the one thing you shouldn't lose is user data.
+ Over 20 Quality control innovations exist, use at least 1/2 of them.
I was lucky enough to find 1.02BTC still sitting there, and now I can only hope that I can get Coinbase to verify my bank account before anything pops.
Don't be too wedded to your initial revenue model. There are lots of ways you can make money here - subscription, ads, etc. The middle-class investment industry relies heavily on getting a finger on the pulse of the cash flow for ordinary people. If you're deliberately avoiding touching that pulse, and deliberately avoiding remarketing to investment businesses, you may have a hard time getting reasonable return for your work from subscriptions or whatever.
You might want to look into investment clubs and how they work, not as a market but rather as an insight into your customers.
I've not seen any lessons on frameworks or responsive design though, but still a good resource in my opinion.
It's also not video learning, but the interactive courses are pretty nice. Learn by doing philosophy.
So, all I can at this point it, you won't know what you want to know until you go through those experiences. And, stop listening to everyone else. We're all different and have different values and beliefs. What works for me probably won't work for you. I can say follow your passion, and that may just completely backfire like it did me. I can say save all of your money and be frugal, look at what's happening to most Americans! But, you could end up with cancer and die in your 30's without having truly lived. I guess what I'm saying is, 15 years from now, when you look back at your life, and you think, "Man, I shoulda, coulda, woulda..." Realize, your decisions are half chanced. Just like everybody else's...
You can see the evidence of this by the fact that companies going through YC are getting better and better. They're better at the start of YC, and they're better at the end of YC (than previous batches).
Is this a good thing or bad thing? For YC - definitely a good thing.
Venture Capital is, at its very best, a gamble, and it's a gamble in which there are a near infinite amount of variables. Product, team, market, vision, future, government regulations, etc.
I don't really know how this would equate them to Google, Microsoft or IBM, especially as except at a very surface level, those companies aren't really all that alike. If the accusation is just that they're slow moving giants incapable of innovating, I'd warn that 1) that accusation isn't fairly applied to the references, and 2) that even if that were the case, isn't really a critique, except where it might be applied in the context of failing to make money.
Seeing the recent batches, it appears that the money-making focus has definitely been more B2B than in earlier batches, but that's likely as a result of B2B proving more profitable over the long run than it is to be attributed to a lack of innovation. As a money-making endeavor, I'd wager that betting for more companies to make less profit than in the hopes of finding one Facebook amongst a bunch of flops is the more humanitarian path of funding as well, but that's another topic altogether.
- You won't know until 10 years from now. Even still, it won't be enough to say they missed a lot of firms. Of course they will. They can't possibly have 100% market share. A sign of the them turning into a large boring behemoth is if they miss all of them.
- If they are too worried about missing a Dropbox, then that risk taking will cause them to miss the next big thing.
- As long as it's entrepreneurs making the decision on who gets into YC, they have a big shot of taking risks. My sense is most of the YC crew is independently wealthy, and are keeping score by "great companies" rather than "minimizing variance of returns".
- All this said, the amount of YC firms acquired by larger tech companies suggest that they are filling an important niche of being the R&D investment arm of large firms who aren't structured to chase ideas that seem too crazy.
They will inevitably miss some awesome companies as well as select some companies which wont amount to much. This is just part of doing something that is speculative. But they need to limit the number of companies in order to actually help the ones they do accept.
YC is a good program that certainly helps a lot of companies, but by no means is it the be all end all. There are many very successful startups that didn't go through YC and many not very successful startups that do go through YC. So if a company doesn't get into YC it's not the end of the world. There are plenty of paths to success that don't go through YC.
Contradictory, however, is these lower risk, already figured out, companies are not really in need of an incubator as much as some younger companies. Anyways, I'm really interested in seeing the next batch of YC companies and where they are going with that.
What's your management style like? What do you like and not like about your previous bosses?
Here's a few questions to consider:
How proactive are your reports? You might notice individuals on your team fall into two camps. One group will keep you updated at all times. That's good. The other won't say anything unless asked. They only do what they're told and stay under the radar. You'll have to figure out what works best for you to have an idea what everyone is up to.
How do you listen to them? Not all my teammates speak English as their first language so initially I had a lot of trouble. I learned over time to just shut up and let them work out their thoughts.
How do you grow your team? I encourage them to explore side projects and I ask what they want out of their careers. Not everyone is the same - some want to eventually run their own companies, others want to stay purely technical. Some just want to tag along. Doesn't matter if they're being 100% honest or not. Just go the distance and help them grow, whatever resources they need. I've always been pleasantly surprised when I genuinely invest in someone.
How do you win over your team? I have never, ever been able to successfully drive an agenda long-term by twisting someone's arm. It's far easier for me to take the time and persuade rather than bark orders.
For reading - Effective Executive and How to Win Friends and Influence People are two books that come to mind. One of my management mentors also recommended reading fiction as a way to understand motivations. Here's an article on this: http://www.npr.org/blogs/health/2013/10/04/229190837/want-to...
I've only been managing for a few years. Maybe everything's still rosy. I see management as achieving results, not controlling people. Management is a way to multiply my effectiveness and accomplish more than a group of individuals.
Let me know if you want to discuss anything else.
1)Create a review package with the code and a brief discussion of what it does. (if its an update then we'd provide code diffs).
2) Have reviewers (at least 3) submit a list of bugs to the person holding the review.
3)The reviewer could accept the comment or flag it to discuss.
4) Then everyone got together (meeting) and discussed the ones that where flagged to discuss. Generally this made the reviews themselves not last too long (going through every line of code thats fine is boring) and some interesting discussion could be had and a conclusion reached.
5)The moderator would write a ticket in the bug tracker for the items and then when the updates are made the moderator would verify the changes were made a close out the ticket.
Learn by doing: Read "A Discipline for Software Engineering" by Watts S. Humphrey. Skip to the exercises at the back, as 95% of the value is in the exercises, the main book is not that good (wants a re-write).
Often, people make the mistake of only doing a code review. While this helps, much better is possible. A review will typically remove 60-80% of the bugs, but to hit 99%, you need to compound your reviews. Capers Jones shows it is easy to hit 99% bug removal if you combine several quality control reviews, such as requirements, design and code reviews.
Quality control is not one innovation, it is a combination of several innovations. Several innovations that improve quality and there are many such innovations, more than 20.
1. You didn't say your third paragraph or didn't say it loudly/clearly/often enough. If this is the case, be more clear about it next time.
2. You said it but they disagree with you. If this is the case, maybe they are right, or maybe you need to find a way to prove the adaptability. Keep in mind everyone thinks their startup is adaptable to a huge market to a degree. You need to be relatively more able to develop a huge market than other interviewees.
I got started by writing PR's, reading the codebase of the projects and making myself helpful whenever I could.
0. Obviously, its major strength is its "real-time" nature: I have built multiple chat systems (and presumably so has anyone else who's used Meteor, because it's an example of something that's fun and easy with Meteor but relatively hard with a traditional stack) as well as a map application that tracked the motion of a company's employees in relation to their destination (as part of a dispatching system).
1. It's also the least complicated way of sharing code between the browser and the server that I've seen to date.
0. It's non-npm package manager feels like NIH to me (although I'm sure the team had valid reasons, I've never looked into it). Apparently it's still possible to require npm modules, although I've never tried it.
1. You're more or less stuck with MongoDB for the time being, which I guess a lot of people like but it's not really my thing.
3. It's kind of too auto-magic for me sometimes. The documentation is generally very good, but I occasionally run into weird variable scoping issues and the like, without any way of really figuring out what's happening. Of course, the source code is available if I had time to read it. (Well-written, but big, and I find reading Node code to be mentally more taxing because of all the callbacks.)
4. The biggest con, for me, is that Meteor is basically limited to web applications. I really enjoy the typical single-page web app approach of building an API first, which you can access from other apps later (ie. mobile/tablet). I have no idea how I'd do that with Meteor. I'm experimenting with bundling a Meteor project and inserting the client-side code into a Phonegap app, for a mobile chat thing I'm working on, but that's obviously not ideal.
Generally, I love working with Meteor. I know I've written more cons than pros, but the pros I've listed are huge, and they've allowed me to work on cool stuff. You just need to know what you're getting into.
0. The scare quotes are for the people familiar with embedded real-time systems who seem to always find these comments and complain about how that word has an entirely different meaning when it comes to web applications.
I started using Rails in professional work in late 2005. That turned out to be a good decision. There is hype around Meteor in the same way there was hype around Rails in 2004/2005. The praise and objections are similar. Meteor is not Rails, so don't go looking for too many parallels. And the development climate in 2013 is not the same as 2005. You won't be able to predict Meteor's success or failure in five years, so it's not worth speculating.
When Rails came out, I was ready for it, technically speaking. My skills were in the right place and I was ready for a change. Similarly, I felt I was in a good spot to learn Meteor last year.
So the real question is, are you excited, ready, and able to learn it? If so, go for it. The worst that will happen is you will learn a new programming paradigm (perhaps) and it will inform any other development work you do.
The biggest negative is simply the immaturity of the ecosystem. Everyone has different standards. There are no de facto standard packages (yet). Everything is changing rapidly. What worked well last week may not work well this week. The bleeding edge truly bleeds.
From a pure technology perspective, I'm excited about meteor because (to use a clich) it shifts the paradigm. I wouldn't compare it to Rails/Ember/Backbone/etc because meteor is full-stack. There is no client/server. There's no ajax. Everything is one codebase. Even though it's built on top of node, it doesn't even feel like node because of the reasons above, and most of meteor is synchronous.
We wrote a couple blog posts about making the jump to meteor. I think the 1st one directly answers your question. The 2nd caused quite a stir here on HN.
Bottom line: Very interesting platform; nicely done in many ways; some concerns about architectural choices; not quite ready for prime time (production use) but probably will be soon.
- It's nice that it comes with pretty much all the grunt work done, out of the box (asset packaging, live reload, deployment bundles, even the database!)
- It reminds me of early Rails, as it is still in a bit of a "hacky" phase. The level of commenting in the code is very low, there's TODO's everywhere, lots of things are shoved into the global namespace, etc. This is a sharp contrast with Angular or Ember, which have codebases I'd be proud to have my name on.
- The template binding is done in a simple-yet-effective way, which works without being too complicated but if your data isn't just a simple key/value map you'll need to learn a bit about it.
- Perhaps due to the simple binding, it's possible to use legacy code (e.g., jQuery plugins) in a lot of places where it would be tricky with Angular/Ember.
- It's very opinionated and you certainly wouldn't want to stray from the "happy path" of what's included in the stack (e.g., mongodb.) This was pretty much a deal killer for my app, though every case is different.
Everything(almost) is worth learning , the question is , is it worth using ? you give 0 clue as to why you'd need that stuff.
0. Meteor is in version 0.6.6.4 so there are things not as good as they could/will be.
1. scaling: meteor is 100% scalable. There are meteor smartcollections which use the MongoDB optlog. Nice read: http://meteorhacks.com/lets-scale-meteor.html .
2. Right now you have to stick to MongoDB this will change in a later version.
3. Meteor will get a new rendering engine which will allow you to put angularjs( god only knows why ) or haml or some other templating thingy in meteor.
4. You can use meteor with phonegap right now.
Will meteor solve all your problems? No!
Will meteor will make you not think? No!
It's a great new piece of technology and you will learn new pattern and things. the livedata package and ddp package are great packages on their own.
They have packages to take care of most of the stuff for you such as their accounts-ui package.
One helpful place to learn meteor from beginner to advanced is via the screencasts on.
Meteor buzzed me out - the auto-updating views, syncing data across client & server. Your app can achieve amazing real-time capabilities with very little code.
But now I'm a few thousand LOC into an application, admittedly I've pretty much hit the "wall". The magic baffles me. I'm struggling to solve problems in performance, code organisation and security.
I've been disappointed by the progress and the team behind it. All that funding and I can't see it progressing quickly. The docs are quite weak, there's not many example apps, progress seems slow.
So... on one hand it's awesome and well worth learning. But I'm reluctant to back it for the long term, as I don't see the team/framework moving in the right direction.
 - http://www.discovermeteor.com/
Meteor.js seems great but is still a bit of a gimmick in my eyes. But If I'm pressed to pick one, I have to say I'm much more interested to see what happens with Go and web frameworks like martini.
I built http://opentalk.me with it
It works for some cases, but it quite limited in the type of database tables it will support. And in the end it's polling mysql for changes to feed to meteor clients.
I also added meteor support to a leaflet-draw package to allow users to share drawing on a map:
Powerful and fun!
If real time collaboration is at the core of your web app, then you'll love Meteor.js.
3 good reasons why:
1. It's ambitious.
Meteor is not yet another nodeJS web-framework or client side JS framework. It also doesn't stop at combining the both (with a beautiful DDP to share data between C/S). Meteor' s architecture will make it possible to use it's components for all sorts of applications (other then the obvious web-apps).
2. It's as easy or as complex as you want it to be.
You can write a meteor app in 4 files or in a complex packaged structure. No need to overcomplexify, if you dont't want to. But you cn write large, complex, stable and maintainable code.
3. It embraces the eco-system.
You can rely on all of the NPM packages out there for your serverside logic and use all of the available frontend UI libraries and scripts. It will also enable writing complete reusable components in 1 package: servers-side logic, data-model, client-side logic, UI, ... all in one.
Biggest upcoming updates:
* Meteor UI.Better approach then any other UI framework out there (including Facebook's react or FTLab's fruitmachine)
* Galaxy.Deploy and scale your app on your own infrastructure or in the cloud by pressing a few buttons.
To counter a few of the cons in this thread:
* It's not reached 1.0 and it is therefor not production ready. I'd suggest writing your new applications in meteor anyway. Meteor matures quicker then any other framework out there. Is is well funded and here to stay.
* It is not scalable. Maybe not easy right now to make it scalable. But it certainly will be soon, when using mongodb oplog and galaxy will make it really easy to scale your service.
I run an agency in Belgium (redandivory.com) and we switched completely to meteor for all of our new projects. I think it's the framework of the near future.
If not, then learning Meteor would be a great way to become familiar with JS frameworks, and make the move to more complex frameworks (Angular FTW!) in the future.
Either way, awesome tool!
Was it worth learning? I'd say yes, it has a low barrier to entry and is great for practicing front-end development.
Meteor is a combination of handlebars, jquery, mongo, sockets, and a handful of other technologies. It can be hard to debug or develop unless you are familiar with those technologies. I think meteor would benefit from more transparency, make it clear which frameworks provide which features.
You will find more applicable documentation by searching "Handlebars Templates" instead of "Meteor Templates".
Charleston Road Registry (CRR) is a subsidiary of Google. Because ICANN requires that registrars and registries remain separate entities, and Google is already an ICANN-accredited registrar, CRR exists as a separate company from Google. We don't favor any registrar over any others in terms of pricing, awarding domains, or any other domain operations; we'll partner with any ICANN-accredited registrars that are interested in our domains"
I think this is actually the remaining argument. JQuery was the best at selecting DOM elements and grew from there. I think the question now is whether you find enough value in the other parts of JQuery to include its (rather massive) .js file.
Its ubiquity also means that problems are often already solved in it. Every time I've run into a jQuery bug there has been discussion and work-arounds already posted online by people much smarter than myself.
Also jquery neatly abstracts single/ multiple element operations making for shorter code.
Use jquery 2, it's tiny and gives you the tenseness without the extra code for all the old stuff.
Or cut a few pixels from the top of a single image and save bandwidth that way.
Plugins are not the reason and fortunately it is changing already, because UI/UX feature developers do not want to be jQuery plugin vendors anymore, they want to promote their stuff under their own brand.
1. Strong U.S. or Chinese regulation
2. An irreversible, fatal flaw in the Bitcoin protocol is discovered
3. A competing cryptocurrency, or other emerging form of money, manages to outpace it in growth and steal its thunder