Need advice about which tool to choose?Ask the StackShare community!
Meteor vs Play: What are the differences?
Meteor: An ultra-simple, database-everywhere, data-on-the-wire, pure-Javascript web framework. A Meteor application is a mix of JavaScript that runs inside a client web browser, JavaScript that runs on the Meteor server inside a Node.js container, and all the supporting HTML fragments, CSS rules, and static assets; Play: The High Velocity Web Framework For Java and Scala. Play Framework makes it easy to build web applications with Java & Scala. Play is based on a lightweight, stateless, web-friendly architecture. Built on Akka, Play provides predictable and minimal resource consumption (CPU, memory, threads) for highly-scalable applications.
Meteor and Play belong to "Frameworks (Full Stack)" category of the tech stack.
"Real-time", "Full stack, one language" and "Best app dev platform available today" are the key factors why developers consider Meteor; whereas "Scala", "Web-friendly architecture" and "Built on akka" are the primary reasons why Play is favored.
Meteor and Play are both open source tools. It seems that Meteor with 41.2K GitHub stars and 5.03K forks on GitHub has more adoption than Play with 11.2K GitHub stars and 3.77K GitHub forks.
According to the StackShare community, Meteor has a broader approval, being mentioned in 195 company stacks & 156 developers stacks; compared to Play, which is listed in 112 company stacks and 47 developer stacks.
What is Meteor?
What is Play?
Need advice about which tool to choose?Ask the StackShare community!
Why do developers choose Meteor?
- Real-time245
- Javascript149
Why do developers choose Play?
Sign up to add, upvote and see more prosMake informed product decisions
What are the cons of using Meteor?
What are the cons of using Play?
What companies use Meteor?
Sign up to get full access to all the companiesMake informed product decisions
What tools integrate with Meteor?
What tools integrate with Play?
Sign up to get full access to all the tool integrationsMake informed product decisions
PRIZ Guru
Some may wonder why did we choose Grails ? Really good question :) We spent quite some time to evaluate what framework to go with and the battle was between Play Scala and Grails ( Groovy ). We have enough experience with both and, to be honest, I absolutely in love with Scala; however, the tipping point for us was the potential speed of development. Grails allows much faster development pace than Play , and as of right now this is the most important parameter. We might convert later though. Also, worth mentioning, by default Grails comes with Gradle as a build tool, so why change?
Mixmax
Mixmax was originally built using Meteor as a single monolithic app. As more users began to onboard, we started noticing scaling issues, and so we broke out our first microservice: our Compose service, for writing emails and Sequences, was born as a Node.js service. Soon after that, we broke out all recipient searching and storage functionality to another Node.js microservice, our Contacts service. This practice of breaking out microservices in order to help our system more appropriately scale, by being more explicit about each microservice’s responsibilities, continued as we broke out numerous more microservices.
As Mixmax began to scale super quickly, with more and more customers joining the platform, we started to see that the Meteor app was still having a lot of trouble scaling due to how it tried to provide its reactivity layer. To be honest, this led to a brutal summer of playing Galaxy container whack-a-mole as containers would saturate their CPU and become unresponsive. I’ll never forget hacking away at building a new microservice to relieve the load on the system so that we’d stop getting paged every 30-40 minutes. Luckily, we’ve never had to do that again! After stabilizing the system, we had to build out two more microservices to provide the necessary reactivity and authentication layers as we rebuilt our Meteor app from the ground up in Node.js. This also had the added benefit of being able to deploy the entire application in the same AWS VPCs. Thankfully, AWS had also released their ALB product so that we didn’t have to build and maintain our own websocket layer in Amazon EC2. All of our microservices, except for one special Go one, are now in Node with an nginx frontend on each instance, all behind AWS Elastic Load Balancing (ELB) or ALBs running in AWS Elastic Beanstalk.
MeteorI discovered Meteor thanks to my daughter who used it for a project at MIT. I was amazed at how much she had built in such a short time. I had also been trying to figure out how to build a browser-based crypto app so I jumped into Meteor and had an MVP for cloak.ly in a few short months starting from nothing. Learning Meteor really alters what you perceive as easy and difficult in full-stack development. It has an amazing ability to simplify your thinking and your code. Community support in terms of packages is outstanding as well which saves tremendous time. The quality of the software is outstanding with very few regressions cropping up during their frequent releases.
Being at the bleeding edge of the js community does have its downsides however. While early Meteor (with Blaze/handlebars templates) was exceedingly simple, Meteor have had to introduce support for both angular and react. In combination with the move to ECMAscript this has resulted in a lot of work for developers to just keep up with the evolution of the platform. Someone who was an expert 6 months ago might quickly find themselves being a newb again. If you're someone who doesn't like change you may want to stick to jQuery.
Living in the bay area I have the luxury of being able to attend Meteor events frequently. Having met many members of the MDG team, I have tremendous confidence in the future of the platform. This is a very solid group with a rare combination of broad vision and excellent execution.
MeteorMeteor is my favorite framework. It makes everything fun. Syncing data across devices is really easy and you don't have to mess around with sockets at all. You can insert data into the database on the client. There's tons of security options. There's over 3000 packages on the packaging system. Instant iOS and Android apps. Amazing, reactive routing. Free hosting. Easy deployment with Meteor Up. What's not to like?
MeteorMeteor is so powerful and flexible. I love it. In the near future, it will be the top-used framework.
PlayPlay is a central framework/component/library (not sure what to call things these days) in Scala. We <3 Scala, and therefore we <3 Play.
Play is on of several frameworks we are prototyping and vetting for various public-facing websites, and may ultimately be the framework behind the main datapile.io website.
MeteorWithout Meteor cloak.ly could not have been built as quickly by such a small team. Meteor was instrumental to getting an MVP up quickly and dealing with the complexities of browser-based encryption.
PlayI used Play to build a configuration UI for the service, which let you create and manage the menus (a hierarchical tree of options and actions).
MeteorBuilt on Node.js, Meteor's real time reactivity and its wide package ecosystem allows us to quickly prototype and build apps in a lean way
MeteorWe would like to make magic with Meteor for the future of GiftStarter.
MeteorHooked is built with Meteor as the primary application framework.
PlayMoving some micro services to Play Framework with Scala
Playused play at talenthouse. uber powerful backend.
MeteorTypical buzz tech. Nothing practical in here.
PlayAPI server framework