Meteor – The next Ruby-on-Rails?(matrixpartners.com)
matrixpartners.com
Meteor – The next Ruby-on-Rails?
http://www.matrixpartners.com/blog/meteor_the_next_ruby_on_rails/
24 comments
Your security should always be behind the API not in front of it and you should never rely on obscurity as a security measure.
Looks like they don't have much in the way of security yet, but they're working on it: http://meteor.com/faq/does-meteor-have-an-authentication-sys...
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.
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.
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.
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.
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.
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.
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.
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.
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.
> restful methods
Sorry, but that's an oxymoron if I ever heard one.
The downvoter would do well in reading about the Uniform Interface constraint of REST. Meteor methods are application specific and therefore the architecture is RPC, not RESTful.
Sorry, but that's an oxymoron if I ever heard one.
The downvoter would do well in reading about the Uniform Interface constraint of REST. Meteor methods are application specific and therefore the architecture is RPC, not RESTful.
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.
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.
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.
There's a really slick answer to this question, but it's not on master yet.
https://github.com/meteor/meteor/tree/auth
https://github.com/meteor/meteor/tree/auth
User submitted meteor app examples:
http://madewith.meteor.com/
http://madewith.meteor.com/
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"
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"
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.
It'd be nice if meteor allows a different way of handling server-side logic using solutions from the Python or Ruby communities.
"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 ?
I guess my alternatives are Rails/Sinatra or Django/Bottle ?
Lua+Mongrel2?
http://tir.mongrel2.org/
http://tir.mongrel2.org/
You can't easily, naturally do things on the client side as easily using Ruby or Python.
I believe CoffeeScript is also an alternative.
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.
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.
Some people like writing JavaScript.
I'm OK with that, I like writing old, insecure code in C :P
Clearly, or else these products wouldn't exist. I'm just saying that, from my experience, I don't see the appeal.
[deleted]
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.
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.
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?
It (can be) page load-time friendly, since there's an overhead for each JS file that's sent.
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.)
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.)
Why not derby.js?
I like where it's headed better, http://blog.derbyjs.com/2012/04/14/our-take-on-derby-vs-mete... except meteor just got a ton of money.
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?
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.)
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.)
So they are betting that enterprises are going to start using Node.js and Mongo for their applications?
I remain skeptical.
I remain skeptical.
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.
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.
Should I assume that this article falls under the Betteridge's Law of Headlines?
http://en.wikipedia.org/wiki/Betteridges_Law_of_Headlines
http://en.wikipedia.org/wiki/Betteridges_Law_of_Headlines
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.
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.
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.
If it could somehow use standard off the shelf packages rather than 'Smart Packages' then we'd really be cooking.
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...
What does this mean for developers working on free open-source frameworks that do the same thing?
Anyone care to explain why they mentioned the Google Spreadsheet as an example?
that read far more like a press release than anything substantial or convincing.
[deleted]
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.