A couple of things really bother me about Meteor.js.
One, the Atomosphere package manager site is insanely slow and buggy. Everything feels like it takes forever to render or rerender. Opening the side menu is a jaggy experience.
If performance is that terrible on a super simple list of packages how terrible is it on an actually reactive site?
Two, I've never seen an article on meteor that wasn't also an advertisement. They all list how easy it is to start a project or add a package as the main draw. That and constant connectivity/"reactive" application structure.
Is it possible the site is just a little over-designed? I'm not sure it's fair to judge an entire full-stack framework over the front-end of a single site.
I've visited Atmosphere from time to time and while performance wasn't as optimal as it could be with a less sophisticated design, it was never what I would call 'jaggy'.
Usually I would agree, but this is a website built by the team behind the framework. When you're making a tool for people to use you really need to put your best foot forward.
Recently someone posted a fast alternative to Atmosphere to the user mailing list: http://fastosphere.meteor.com/ I think it uses Atmosphere's DDP connection so it should be up to date.
@rezistik: I've been working on a site called The Meteor Chef for the past couple of months and think some of the stuff I've covered will give you a solid idea of Meteor's power. The focus is on implementations of features for Meteor apps in the form of "recipes," so it's much less about _why_ Meteor is cool and more of a demonstration.
@rglover, I'm actually about to do a side project for a family friend. I'd really like it to be something I could do quickly. Basic crud dealing with a lot of inputs, but I want to use Postgres.
What's meteor got for me?
I am honestly interested, as much as the marketing edge of Meteor annoys me I'd like to believe there is some truth to some of the hype.
I added some inline comments to explain how everything is tied together, but if you have questions shoot me an email/gchat! ryan.glover@themeteorchef.com.
If you're looking to build a quick CRUD app, Meteor would be a great candidate.
Edit: In this example, the interaction would be when I type a taco name into the field provided and click "submit," it would immediately appear in my tacos list :)
I'm open to giving it a look, but honestly I really love ES6, React and Express. I can't think of much reason to leave them anytime soon.
I've been known to be tempted. And if it really increases productivity the way the marketing claims than I can see it's use case at the company I work for as well.
My fear is kind of two fold.
One I really like the NodeJS micro-modules/micro services architecture. I like being able to consider each entity of an application it's own application. It's really easy to scale, it's really easy to completely replace portions of the application when I want to update them.
Second, I don't like 'automagic', I found both Rails and Ember really awful for me personally. I had to constantly check the documentation to understand what is expected of each layer, and there are always so many layers.
Last question if you'll continue to indulge me. I prefer functional programming to OO, since Meteor is reactive is it safe to assume it is also geared towards a functional paradigm?
Re: functional programming, yes. Meteor is very agnostic to a specific pattern/structure, so you're able to organize your application however you see fit. There are definitely "automagic" functions that they give you, but it's more of a "box of legos" mindset than "build this model of this airplane and if all the parts aren't organized by the manual, you will fail."
You can bring your own way of thinking and work it into Meteor. The platform has conventions, for sure (e.g. client code vs. server code), but none that force you into a rigid way of writing your code.
Is that what you're asking (I'm not much of a programmers programmer so my terminology is spotty)?
Edit: give it a try, but if you have a preference for writing your apps: work with that. The marketing bullshit is just that: marketing. Meteor is great, but it's not for everyone or every application. Instead of getting caught up in the woo, it's helpful to play with it for an afternoon to see if it maps to your mental model of what an application should (or could) look like. If not, stick with what ya like :)
What does meteor have for you? Well, not so much right now. Crud applications talking to SQL isn't its focus point.
You want to build apps quickly that automatically sync up between uses (think google docs) and like using mongo? Then there is a LOT of goodness to be had with meteor.
I've written a lot of meteor apps. It is really really good, but not for everything.
(MDG-er here) On #2, I think you may enjoy browsing https://www.meteor.com/projects. :-) Lots of meaty technical detail on the different subprojects that make up the Meteor stack.
Please bear in mind while reading that this is the same author as the rather controversial 'Why Meteor will kill Ruby on Rails' from last year (HN discussion: https://news.ycombinator.com/item?id=6642893)
I'll repeat my thoughts from back then – Meteor is a great experiment that tries out some interesting ideas for what web apps might look like in the future.
I maintain that it's absolutely not production-ready, or even very good. I don't want to store data in Mongo. I don't want Cordova baked-in (wtf is that about anyway?). But we absolutely need people playing with this sort of technology. I just wish the hype would die down a bit…
I don't even see how one could compare Rails and Meteor. They are intended to solve two very different web development problems.
Discover Meteor, the most popular book about Meteor, even uses Middleman for their blog and website - because using Meteor for something like a blog or information based site just makes no sense at all.
It is production ready. We use it a lot. Mongo? Well, yes, you are stuck with Mongo - there isn't good database support outside of that, and as for Cordova? I have no idea why they baked that in either :)
It IS good though, the ability to out put really good applications quickly, with simple code shouldn't be overlooked.
I'm surprised at all the negativity. Advocating C++/Java instead of Meteor/Node.js makes about as much sense in my opinion as comparing 18-wheeler trucks to Smart cars, and I wonder if the people who do so have really worked with the latter or are just dismissing it out of hand. The right tool for the job and all that, and you want your toolbox to be comprehensive, right? No serious craftsman ever said "Wrenches? Oh, we're a strictly pliers-only shop".
At my company, we have critical API services with SLA's that will cost us $$$ if broken. We develop on the JVM with Scala, the number of currently open bugs can be counted on one hand, with millions of daily users. But some of the dashboards for monitoring the service are Node.js. Want a new fancy gauge on that board that measures X by interacting with API Y? There's probably a NPM module for that, so give me 30 minutes, OK? I see that the web frontend serving is increasingly being done in Node as well, because it's a good fit for that environment.
Don't get married to your platform! Try many things, and figure out where on the spectrum the tools fit and use them where appropriate. I've done many years of C++ server and embedded development, but working with Meteor just gives me the biggest dumb grin. It's fun!
Node is the fastest growing ecosystem today, and it's not because everyone using it are idiots. Meteor takes that energy and kicks the out-of-box productivity up to 11. Java/Scala/Go/C++ are and will continue to be the workhorses of the Internet when performance and stability are of the utmost importance. So, no matter where on the platform spectrum you're currently on, go check out what's happening at the other end!
An example of a sophisticated meteor app I've built to test scalability http://www.qckt.me. I've noticed some performance issues (to be fair it is running on meteor's free hosting service, however they don't set resource limits or anything like that) maybe I'll share some stats I've been collecting in the future.
Like every web framework, I've run into problems. The simplicity of the server-client reactivity is keeping me in. Its a good idea and the got the funding to keep it going.
As someone who doesn't know what Meteor.js is this doesn't actually tell me what it is, what it can do, or what it can be used for. Now to be fair I'm not a webdev so I don't much about most of these technologies nor am I really the target audience. But still. I feel like if your article is literally called "What is X" it should do a better job telling you what X is.
Meteor.js is basically Ruby on Rails for Node.js and MongoDB, plus a Javascript library for view-model binding. It's a monolithic framework for building database-backed single-page applications in 100% Javascript.
> Meteor.js is basically Ruby on Rails for Node.js and MongoDB...
As a long-time user of Meteor in production I have to say this is just about the exact opposite of how I think of Meteor. I'd encourage anyone interested to try out the simple tutorial [1] and glance over the principles behind meteor [2].
For my take on it, Meteor is great for "real-time" apps where user actions should be disseminated across a broad network quickly. It has helpful things like built-in latency compensation which make the end-user experience much nicer and the "database-on-the-client" is just glorious.
The most beautiful part of Meteor is that these features are provided for developers without us needing to make sacrifices or in most cases even change our way of coding. Latency compensation is purely controlled by whether a method is made available on both the client and server or just on the server. The client-side DB is automatically kept in sync with the actual back-end DB via a familiar pub/sub mechanism.
To me, these features (and the many others not mentioned) make Meteor much different than simply a "Ruby on Rails for Node.js".
Not if you're unfamiliar with Ruby on Rails, I guess. It's a little tricky to characterize because of how much stuff it contains. Basically it has a number of different components, that work together to make a structured environment for developing Web applications. Some of the prominent features include:
* Web server that runs on Node.js
* MongoDB integration
* Custom build tools
* Package manager (supports installing JS packages for either client-side code, server-side code, or both).
* SignalR-style remote function execution (call functions on the server from the client, and vice versa)
* JS client-side database caching
* Data binding in Javascript templates using Handlebars (or something similar, I don't remember exactly).
That's honestly just how the Meteor.js blog posts are. Google around a bit and you'll find two dozen articles stating Meteor.js is the best thing since sliced bread, beer, marijuana or Ruby on Rails. It will completely revolutionize your face, twice over!
But they'll never explain what it is, or how it's solving hard problems for them.
I know a guy who hooked up a Nunchuck to an Arduino, blasted the x/y/z data into MongoDB and used Meteor.js just to show the coordinates on a website, in realtime. He is also the kind of guy who likes to use Node.js and thinks MongoDB "is a database for when you need scalability". Though I must say he hacked it together rather quickly.
I like to use NodeJS too, JavaScript is a great misunderstood language that will handle the vast majority of use cases in the world of CRUD.
Honestly, there is something to be said for hacking something together quickly. Prototyping is a great way to explore ideas and find the interesting problems nested in the problem you're trying to solve. I just don't like the evangelism of Meteor because I've never seen anything really explaining it's value.
Sure it will handle CRUD just fine, like PHP did for all those years, but thats a low standard to measure yourself against. ECMAScript 6 does look kinda decent, but thats the future, not the present.
Also, why use it (Node.js) on the server? Its not even that fast, 21th on the techempower Json benchmark, which should be its strongest discipline (all I/O, no computation, emitting Json).
> Also, why use it (Node.js) on the server? Its not even that fast
Not only it's still reasonably fast (21st is great, it's mostly surpassed only by C and Java), but it also has a much better ecosystem than most platforms (especially C and Java), it's faster to develop in (especially C and Java) and shares language with client side.
Sharing a common codebase is very important for me. I found in most of my web projects I'm reusing code between server and client. Ever worked with code that does (or should do) the same thing in different codebases? It's just a nightmare.
Having the same React code be rendered in the server (fast, SEO-friendly) and in the client (offloads resources off the server) is just too good.
NodeJS looks like a decent compromise to me, isn't it?
I agree it is reasonably fast. I don't agree its ecosystem is better than Javas, neither in size nor in quality.
Same language is an advantage, so is development speed, I agree.
But: C++, Java, Lua, Ur, Go, Ruby and Erlang are all faster than JS, and especially Ruby is a much nicer language. I don't hate Node.js, it has its sweet spots and the tooling feels nice and lightweight, but its not (yet) a very good general purpose tool. Its just not yet on the sane part of the hype curve, and I don't want to be the guy who has to maintain that callback hell 5 years from now.
But ECMAScript 6 is definitely moving into the right direction.
> C++, Java, Lua, Ur, Go, Ruby and Erlang are all faster than JS
Wrong column. You're looking at languages, but a language does not affect performance: its platform does. E.g., the only Ruby benchmark which is faster than Node is actually JRuby, i.e. Java.
> and especially Ruby is a much nicer language
That's a matter of preference. I don't like Ruby myself (nor most languages encouraging classes as their primary constructs).
You shouldn't evaluate languages, but platforms.
> but its not (yet) a very good general purpose tool
Why? I mean, no tool is a very good general purpose tool, but what makes NodeJS worse as a tool than, say, Ruby?
> I don't want to be the guy who has to maintain that callback hell 5 years from now.
Neither do I. That's why I don't use JavaScript for anything else than a target language. You seem to like ES6, why don't you use it and transpile it to plain JS?
> You're looking at languages, but a language does not affect performance: its platform does.
Both language and platform affect performance, otherwise JRuby would be the same speed as native Java, which is not the case.
> E.g., the only Ruby benchmark which is faster than Node is actually JRuby, i.e. Java.
Which still means that Ruby (as a language, using the JRuby implementation) can be faster than Node (assuming the benchmark at issue is meaningful at all.)
> That's a matter of preference. Anyways, you shouldn't evaluate languages, but platforms.
Since you actually need to choose languages to use, you absolutely should evaluate them. You should, of course, also evaluate platforms since you need to choose those, too (and part of evaluating languages is evaluating the constraints language choices put on platform choices, and vice versa.)
> Both language and platform affect performance, otherwise JRuby would be the same speed as native Java, which is not the case.
No. JRuby is the platform, that's why JRuby is not the same speed as native Java.
But CoffeeScript has the same speed as plain JavaScript, because both are running over the same platform (NodeJS) even if they're different languages.
It just happens JRuby can only run a single language (Ruby).
> Which still means that Ruby (as a language, using the JRuby implementation) can be faster than Node (assuming the benchmark at issue is meaningful at all.)
Ruby is neither fast nor slow. Languages don't have speed.
> Since you actually need to choose languages to use, you absolutely should evaluate them.
Of course, but you shouldn't evaluate languages on their speed, because then you're measuring something completely unrelated to the language. You can measure platform speed (and the constraints they put on languages you can choose), not the other way around.
---
So, to sum it up, software engineering is all about compromises. Dismissing NodeJS because it ranks 21st in a benchmark is a bit shortsighted.
Of course Java and C are going to beat JS at speed, but... do you want to deal with Java's interfacing mess? Do you want to deal with C's manual memory management? I certainly don't. Especially for a web app.
I'd like to disagree. The language specifications provide various limits on the kind of performance you can get, regardless of the platform.
Performancewise, for the record, I find JavaScript to be wholly adequate for writing servers, but to say that the platform is what makes it slow(er) doesn't ring true to me. For example, JavaScript has a few poor design decisions that make implementing performant arrays really hard. Some other interpreted languages get this right, and their performance can be (and usually is) much better in that regard. However, this is kind of splitting hairs since you only care about its performance on whatever environment on which you are running it.
A lot of work really can be boiled down to CRUD though.
For more advanced stuff, it's great for prototyping ideas, in fact I think that's where it really excels. It's a super simple language with a massive ecosystem, you can very easily play with ideas or start the basis of an application. Then once you've solved the business logic problems it's generally simple to move to a higher performance language.
I fully agree. Performance is not even that important, but for much of the Node.js/MongoDB hype cycle, thats what people often claimed was its biggest advantage; that "average" developers could now write servers that scale beyond what was thought to be practical.
But if that isn't true, then JS has to be measured against other languages on different merits, and e.g. Ruby and Lua are just as suitable for quick prototyping.
Anyway, these discussions usually end in language zealots downvoting each other and not much else, even on HN. Facebook still runs on PHP, so theres that.
If you compare apples to apples I think the hype for NodeJS for most development is well deserved.
The fact that we are comparing static typed compiled languages like C and Java to NodeJS in order to find higher performance alternatives says a lot about it.
NodeJS isn't a replacement for those lower level languages, however when compared to other dynamic languages like PHP, Ruby, or Python it's suddenly far more competitive.
PHP is probably the main target in my opinion for Node. It's an incredibly popular language for nearly any web application use case.
These benchmarks really only place Java, Go and Lua above NodeJS in terms of performance.
Bundle in the ecosystem and developer productivity and it does earn the praise it received.
At the end of the day, the vast majority of developers will never need to optimize their applications past what NodeJS offers. Few of us will really deal with massive scaling issues on a day to day basis, nearly any modern language will handle the majority of applications. By the time performance is an issue it's probably time for a major refactor or rewrite building on the knowledge gained in the original version.
I guess I would love to hear what you are missing. I think there is a gap between your unknowing and my knowing and I tried to bring that gap a little.
I am still trying to figure out how to explain Meteor to someone brand new to web dev and would love for something more constructive from you here :)
It's actually quite pleasant to compose your application out lots of small modules, libraries, and frameworks. It's not akin to building your own platform, since all the pieces are there.
It's really, really good. Even if you're a web designer, building stuff is really quick and effective. I recommend checking out Differntial's GitHub page [0] as they provide a nice boilerplate and also a cute blog that you can setup in two minutes, gives you an idea of the very basics.
Either way, Atmosphere [1] has thousands of packages to choose from, just use the search function. Good alternative is Fastosphere. [2] Many people have said that if you write a lot of code with Meteor, you're doing something wrong.
The framework is brilliant from a productivity and sheer enjoyment perspective. I don't know if it will scale; you don't either. My estimation, though, is that the team building it is very clever and super-aware of what they need to do to make the framework succeed from a scaling perspective.
A lot of the comments here are spitballs from the back row of the classroom. They are willfully uninformed and unfair. It is hard to imagine these commenters are paying much attention during the learning portion of class.
So go forth, meteor team. You're fighting a great fight here. Ignore the naysayers and do the great work you know you can do. Your best way forward is to prove the haters wrong. Maybe a few will even become lovers, though I wouldn't count on it. If you build it, they may come. [update to spell 'perspective' correctly. Ugh]
Also, people are scaling it, we just aren't hearing about it much. I am working to correct that, these trials of scaling need to be more public right now.
Scaling Meteor is my biggest concern right now as I contemplate diving any deeper with it. I'm well aware of Mongo's oplog but the lack of Mongo sharding, the sticky session requirement, server resource consumption (RAM required per client), lack of proper offline support (last write wins) and sheer devops work required to scale is off-putting. Hopefully tomorrow's release of the remaining Bulletproof Meteor content will ease my worries. But I cannot shake the feeling that in terms of cost, something like Firebase would work out to be much more cost efficient.
Also, the whole ecosystem of wrappers is plain silly. It feels like the MDG & the community are just reinventing the wheel time & time again. Oh we got Cordova support? What's that exactly other than some CLI tools? Of course any web tech should support Cordova, that's what it's built for. The Ionic Framewoek are light years ahead in this regard.
I sense that you don't really want an answer to this, you have already made up your mind...
Why is the sticky session requirement a huge devops concern?
From what I understand Mongo sharding shouldn't be hard to implement, but I haven't tried it myself. I spoke to Abigail Watson about it, and she said her first tests with it were promising.
RAM is always a precious resource, so I understand being concerned about it. Are you seeing some absurd usage per client? I am seeing about 350mb processes to handle around 75 connected clients.
Is there a framework or platform that gets the 'last write wins' correct? I seriously doubt that because I doubt you can apply a blanket set of rules for offline support.
I don't think scaling is off-putting, you just need a mongo cluster and then you can add oplog enabled Meteor processes to your pool. I don't see how this is any different than something like Java or Ruby...
The idea of adding Cordova may seem simple or small, but MDG putting it in led me to building my very first mobile app. Prior to trying Cordova and Meteor integration, I usually advised clients it would be easier to just build a responsive design instead of trying to build a native app.
I am sure if you looked at the commits around adding Cordova, it was a little more then just glueing together some CLI tools.
That being said, if Ionic floats your boat, go enjoy it :)
I programmed 2 small apps now with Meteor and my learning is that if you want to prototype something fast you can use it but if you want to have something polished afterwards then don't expect to save time by using it instead of other tools. It has its quirks...
Meteor.js is great, but the instant you try to do something complicated (or simple and not covered in the often repetitive documentation), you need to be a JS expert or spend a frustrating amount of time looking for a solution.
If anyone is curious about what it looks like to build with Meteor, I've been working on a site that shows off building day-to-day features with the platform: http://themeteorchef.com/.
"What is Meteor.js?" Yet another framework that encourages developers to pipe into their shell. Until this changes, I will never give it a second look.
It is unfortunate people think piping into a shell is cool. But don't let that keep you away from the actual framework, which is actually pretty cool by itself without gimmicks like that.
I'm not sure what PGP would buy us over everything going over https from sites under Meteor's control? Cryptographic verification is great when you want to deliver the bulk of the content over http, or via untrusted mirrors, but we're not doing that.
However, if you want greater assurance, Meteor is open source, and easy to run from a git checkout. That seems to solve even more problems than PGP would, though then you should worry about whether you should compile nodejs yourself, and eventually you start eyeing your CPU suspiciously... :-)
(BTW, I think this is why just linking to a HN thread is tricky... it's difficult to know which of the many viewpoints on any thread you share!)
It buys you almost nothing. The only thing it buys you is avoidance of knee-jerk reactions from certain people, who most likely never were interested in Meteor in the first place.
> I'm not sure what PGP would buy us over everything going over https from sites under Meteor's control?
Rogue CA certificates, targeted MITM -> RCE attacks (Nation State Adversaries, etc.)
By using PGP (or, hell, openssl) to sign the package with a key that remains offline/air-gapped and then writing installer instructions that verify the signature before running anything, you reduce the odds of this happening significantly.
Additionally, it allows you to mirror the contents on CDNs with some peace of mind.
PGP would get you a lot. See this discussion for why https "only helps in a small way and is not enough to provide users with a reasonable level of trust that it's safe to use your
software."
I've built several apps with Meteor, and so far it's been fantastic. Development is lightning fast, the interface is snappy enough, and it's easy to maintain. My latest Meteor app is online at http://stoplight.io.
I'm a webdev at an agency, and Meteor looks great from a prototyping perspective. Javascript is already a key component of much of our work, so this framework could help us roll out concepts much faster than we're doing now... looking forward to learning more about Meteor!
There's a problem I have with frameworks in general. They tend to streamline your thinking too, which is fine if you don't care about making something original or can't see how developing with new approaches can impact the outcome of your product.
The motivation people have for creating frameworks to begin with is because of bad practices by developers. By not 'making something original' you probably also avoid doing things incorrectly.
Why do they keep announcing Meteor.js as if it's something new. It came out 2 years ago.
Oh I know why, because it has major funding and they have some marketing blitz going on right now beating into people's mind that Meteor is great/grand.
This would be a huge selling feature for me to jump on meteor.js again. Would love to have SQL in meteor.js but again the mysterious "DDP" and it's reliability and ability to scale still remains doubtful.
One, the Atomosphere package manager site is insanely slow and buggy. Everything feels like it takes forever to render or rerender. Opening the side menu is a jaggy experience.
If performance is that terrible on a super simple list of packages how terrible is it on an actually reactive site?
Two, I've never seen an article on meteor that wasn't also an advertisement. They all list how easy it is to start a project or add a package as the main draw. That and constant connectivity/"reactive" application structure.
It just feels too orchestrated.