I loved meteor. Was committed to it for 6/7 months while still learning JS (and working on ember and rails projects with others). I knew it was a risky decision, but it seemed like a good choice for making it as a one-man dev agency.
For me, there's no stack selection problem, for me, the main problem is the co$t of launching a working demo-app or a prototype. The only thing i wanted was a simpler/cheaper way of deploying apps.
I knew there was something coming, since the beginning i heard about galaxy, an MDG developed deploying solution, which i thought was the solution for all my problems. But then, then came the galaxy launch and its price ($495/mo). At that price I felt betrayed, misrepresented. (still waiting for the individual price several months after)
The big problem i see with meteor for the future, is that MDG has/will have to answer to its shareholders rather than its community.
The biggest downside to meteor for me is that nobody has settled on a good way to use it in production.
We currently have a meteor app in production and it has a few large clients running off of <$100/mo in server. A majority of our production costs are a large amount of redundancy and backups, not the actual server the clients connect to.
With docker it can be very simple to deploy meteor apps as release mode meteor is just a standard node.js app. It takes us about a minute to go from dev->staging (and less for stage->prod as the image is already built). Depending on your app, you can get away with a fairly tiny server (2 cores, 1-2gb ram is fine for demo/pilot).
Starter docker file (note: this is designed to be simple vs best):
FROM node:0.10
ADD meteor.tar.gz /meteor
RUN (cd /meteor/bundle/programs/server && npm install)
EXPOSE 80
CMD ["node", "/meteor/bundle/main.js"]
#Put your meteor.tar.gz file in the same folder as this (name this as Dockerfile), then build and run. Will bind onto port 80
#Build Command: docker build -t meteor-prod ./
#Run command: docker run -d --restart=always -e MONGO_URL=YOUR_MONGO -e PORT=80 -e ROOT_URL=http://YOUR_EXTERNAL_HOST -p 80:80 meteor-prod
You must have missed it, the individual developer galaxy hosting is out. I am using it, its amazing. $13 per month per container. Its not the cheapest ($5 D/O wins there) however so far I have found it to be fantastic! They take care of all the nuts and bolts behind the curtain. You just deploy with a single command in console and it uploads, builds a new container, migrates active sessions, tears down the old container.
To address your "co$t of launching a working demo-app or a prototype" issue, Heroku offers a free app / database for demo purposes[1].
Once you really get going, Heroku is expensive, but it might be worth the cost for teams (or individuals) that don't have the time (or expertise) to effectively manage a production deployment (security, up-time, backups, etc.).
You are right, i've used heroku (haven't seen it in a while though, so thanks for the link). Maybe now it's simpler, but at this time last year, it wasn't.
Also, main problem with free-tiers is that meteor is CPU/RAM-intensive and they do not handle that very well. I'll have to check it up again though.
Surely, there are many ways of deploying meteor apps, but no true simple way (which is why i expected a lot from galaxy). Like a single production line: create > develop > deploy w/ scalable infrastructure and cost. That was the whole meteor attractiveness for me.
There was a meteor based project where i spent 2 weeks developing a prototype and almost a month trying different deploy setups with the client. (heroku, digital ocean, linode, modulus, compose, aws, etc...)
Now, with ember or react + firebase, i can do the same stuff at a fraction of the cost and without having to learn devOps.
Microsoft's fork is meant to be temporary, experimental fork.
"This GitHub fork enables Node.js to optionally use the Chakra JavaScript engine on Windows 10, allowing Node.js to run on Windows on ARM. Our goal is to merge back into master after stabilizing this code, fixing key gaps and responding to early community feedback."
Their goal is to work on it, stabalize it, and then merge it back in once it's ready for general use. Microsoft's "fork" wasn't trying to split the community or create a permanent new path. It's to build something new for Node.js that shouldn't be in the main project until it's ready. Microsoft wasn't trying to split the community, but rather trying to take on an experimental project.
The io.js/Node.js situation wouldn't have been influenced by Microsoft's announcement. Node.js/io.js didn't necessarily have an intention of reuniting in the future and might have stayed apart. By contrast, Microsoft doesn't intend to split off from Node.js at all.
Thanks for all the explanation. I though ending something with :P - could be universally understood as a bit of irony. I'm just happy with the announcement, and used MS fork and this announcement timing for my irony-driven-comment. I'm sorry for the misunderstanding.
<3
I'm aware publishing GIFs on HN is off-topic and I realize this might be a bit childish but I couldn't help myself, and also, you sound like a lad with a sense of humor so you might appreciate it :P
Congrats Yehuda! You are a true inspiration, and i just want to thank you for everything you've done and i'm shure you'll take rust to another level. Congrats to Steve too. 2015, the year of rust(?) :P
The big problem i see with meteor for the future, is that MDG has/will have to answer to its shareholders rather than its community.