* 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).
etc.
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".
[1] https://www.meteor.com/install [2] http://docs.meteor.com/#/basic/sevenprinciples
But they'll never explain what it is, or how it's solving hard problems for them.
But hey look how easy it is to add social auth!
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.
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).
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?
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.
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?
Platforms, not languages.
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.)
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.
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.
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Type...
Size is a fact:
And Ruby is definitely not faster than JavaScript.
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.
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.
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.
http://blog.loadimpact.com/2013/02/01/node-js-vs-php-using-l...
The performance tends to favor Node over PHP. In fact, it favors NodeJS over a ton of languages in a lot of areas.
https://www.techempower.com/benchmarks/
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 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 :)