
Meteor – The next Ruby-on-Rails? - rktaparia
http://www.matrixpartners.com/blog/meteor_the_next_ruby_on_rails/
======
alinajaf
Yeah so, I suck profoundly at web application security, even on your everyday
vanilla CRUD app. Having all of this logic available on the client needs
tptacek approval before I will go anywhere near it.

Then again, I'm quite technologically conservative. I'm sure this is very
exciting for early adopters but I'm not going to put any time into it until I
know I can build something useful with it.

~~~
lucisferre
Your security should always be behind the API not in front of it and you
should never rely on obscurity as a security measure.

------
blackjack160
They are going after the enterprise market.

There are two solid tells:

1> Raising $11M+ led by AH has a lot to do with giving CTOs some assurance
about Meteor's commitment level. One can draw a parallel with Cloudera and how
it gave Hadoop legitimacy with Enterprise customers.

2> The same enterprise CTOs identify strongly with Rod Johnson (Spring
founder) who is on the Meteor board. He's someone who understands the Java
enterprise space intimately and knows how to disrupt it (given his
SpringSource exploits).

I also don't think the Github / Asana / Meteor connections are incidental.
It's being positioned as a whole new way to execute on tech projects within
the Enterprise IMO.

------
evaneykelen
The obvious question which comes to mind is? How is Matrix Partners going to
get a solid return on this investment?

Is (the company behind) Meteor going to follow the Red Hat route? Or are they
going to license the platform to developers for a fee (i.e. the Sencha model)?

Although I'm impressed by anyone who lands a major VC deal, I simply don't
understand why $11.2 million is needed to build out a development framework.

Red Hat started selling consulting services (among other services and
products) well after Linux was well entrenched in the market.

The same goes for Sencha (a combination of Ext JS, jQTouch and Raphaël). I.e.
the products were proven, the time was right to start offering paid-for
services around these products.

It's a sincere question, not being cynical, it's a great deal for the folks
behind Meteor. It just doesn't make business sense to me from an investor
point of view.

~~~
patrickaljord
It's not just a development framework, I'm pretty sure they said they planed
on offering hosting for apps too, actually you can already upload your meteor
apps to yourapp.meteor.com.

------
andrewvc
The big difference is Rails was already powering 37 Signals' success. Meteor
is a framework without a major success story. APIs that are not direct
extractions tend to be problematic.

~~~
patrickaljord
But the first version of 37 Signals product was a basic todo list. Meteor was
released with a real-time collaboration todo list and a chat and other demo
apps. Doesn't mean it will be successful though, just a good thing to keep in
mind.

------
ehutch79
Ok, I'm sure this address places, but if I can access the db api on the
client... what's preventing someone on the client from screwing with my
database? getting around read/write permissions and such.

~~~
user49598
Wide open DB access is for rapid development. In production, which meteor is
totally not ready for yet, you'd restrict the db, have proper auth(which isn't
built into meteor yet), and call restful methods from the client that have
both client side and server side validations.

~~~
ehutch79
so, it's no where near done yet then? cause this is in the FAQ:

Nonetheless, if we were starting a new project today, we would use Meteor.
It's open source, so you can decide for yourself if it's finished enough to be
useful to you.

~~~
user49598
Yeah thats funny, I don't think they'd really recommend putting a meteor app
into production. Auth is still in it's own branch
<https://github.com/meteor/meteor/tree/auth> and meteor's version is "preview
0.3.8". Plus you can't yet do things like respond to restful requests.

------
user49598
User submitted meteor app examples:

<http://madewith.meteor.com/>

------
bascule
Node.js: the next evented Tcl?

Seriously though, given what you have to go through to even use Meteor, i.e.
finding libs compatible with Node fibers, they are certainly not putting
anything "on Rails"

------
vph
Meteor does not take advantage of Node.js async thing. Then, I'm not sure
about the advantage of javascript being both on the server and client side.
Javasccript just feels weird on the server side. Server-side apps written in
Python, Ruby feel much more natural, and perhaps easier to manage.

It'd be nice if meteor allows a different way of handling server-side logic
using solutions from the Python or Ruby communities.

------
dysoco
"Meteor lets you write your entire app in pure JavaScript" And there is my
problem.

I guess my alternatives are Rails/Sinatra or Django/Bottle ?

~~~
chimeracoder
FYI, Django/Flask would be the better Python analog; Flask is more similar to
Sinatra in its structure (not just syntax), and it was in fact modeled after
Sinatra.

But as for your main point, I agree - I don't see the appeal of writing an
entire application in Javascript. You pick the best tools for the job, rather
than picking one and shoehorning it into every use case. Server-side and
client-side needs are different, so I don't see any problem in using a
different language on each side.

To preempt the responses of 'But it's so much easier to use one common
language for an entire stack', I'll have to say that, at least for me, passing
data between client and server feels no easier (syntactically _or_
conceptually) in Node.js than in Python/Ruby. YMMV.

~~~
debacle
Some people like writing JavaScript.

~~~
dysoco
I'm OK with that, I like writing old, insecure code in C :P

------
matrix
I think it's fair to say this is an example of the general rule that the
answer to a headline in the form of a question is always "No".

Rails and Django will be replaced with something else sooner or later, but I
have a hard time believing Meteor is it given their goal of being a
commercial/enterprise offering.

------
WiseWeasel
I noticed Meteor outputs your entire web app to a single JavaScript file,
which seems peculiar to me. Is it seo-friendly? Is this something that will
scale? Is it mobile-friendly? Are the any drawbacks to this approach? Why
would I base a large project on Meteor rather than Backbone.js?

~~~
dgant
It (can be) page load-time friendly, since there's an overhead for each JS
file that's sent.

------
deanotron
I'm not so sure the "next Ruby on Rails" necessarily prescribes a full stack
framework like meteor.

They have an impressive demo that showcases what you can do with full stack
javascript, but having spent a few years now in that full stack environment..
none of it is new. ie. all of this is out there, just not packaged together.

IMO the next Rails is anti-Rails. It's more about building from the ground up
than having all your decisions made for you. (meteor packages?? Fibers?? no
thanks.)

------
dgudkov
Why not derby.js?

~~~
JTxt
I like where it's headed better, [http://blog.derbyjs.com/2012/04/14/our-take-
on-derby-vs-mete...](http://blog.derbyjs.com/2012/04/14/our-take-on-derby-vs-
meteor/) except meteor just got a ton of money.

------
trung_pham
We worked so hard over the past decade to separate the presentation code from
the business logic code. And moving away from SOAP/RPC to simple REST
protocol. Then come nodejs and friends like Meteor/Derby/SocketStream/Firebase
now trying to undo that separation. Have we gone backward?

~~~
ebiester
There is nothing stopping you from separating presentation from business logic
in node. The difference is that with single page apps, we're returning to a
true client/server model. The server is very basic and easy to write, the
server becomes more complex.

Now, while it is true that the goal of meteor is the sharing of code between
client and server, that is business logic code (ideally) separated from the
presentation code on the client. (Further, we're still a ways away from truly
sharing that code.)

------
robfig
So they are betting that enterprises are going to start using Node.js and
Mongo for their applications?

I remain skeptical.

------
EternalFury
I am very interested.

I just wonder about performance and deployment practicality.

One thing is certain though, the days of wondering "Is Java fast enough for
this?" are long gone. These days, people have no issue promoting deep stacks
far above and beyond any OS platform.

------
dacilselig
Should I assume that this article falls under the Betteridge's Law of
Headlines?

<http://en.wikipedia.org/wiki/Betteridges_Law_of_Headlines>

------
dysoco
Anyone tried to install it in a non RedHat/Debian Linux distro ? I'm running
Arch Linux and found Meteorjs in AUR, but it's outdated and I can't update it.

~~~
pfeyz
You can edit the PKGBUILD from the AUR. change the pkgver to 0.3.8, and update
the md5sums to a292c8d0cd2e9269ea71bcd45f2f7908 and
9a7077a8dd3e5a2c9531e2943cba2f43, respectively. This worked for me.

------
easternmonk
Meteor I believe is not using the asynchronous nature of Node.js it is using
it sequentially. Single reason why I am not using it yet.

------
speg
If it could somehow use standard off the shelf packages rather than 'Smart
Packages' then we'd really be cooking.

~~~
user49598
A smart package is just a regular javascript library with a configuration
file, heres underscore's:
[https://github.com/meteor/meteor/tree/master/packages/unders...](https://github.com/meteor/meteor/tree/master/packages/underscore)

------
dreamdu5t
What does this mean for developers working on free open-source frameworks that
do the same thing?

------
swah
Anyone care to explain why they mentioned the Google Spreadsheet as an
example?

~~~
harrylove
See <http://en.wikipedia.org/wiki/Reactive_programming>.

------
zem
that read far more like a press release than anything substantial or
convincing.

