Meteor Raises $20M(techcrunch.com)
techcrunch.com
Meteor Raises $20M
http://techcrunch.com/2015/05/19/meteor-raises-20m-to-build-the-one-javascript-stack-to-rule-them-all
162 コメント
SQL support is the biggest ask on their Trello board.
https://trello.com/b/hjBDflxp/meteor-roadmap
There are some good packages on Atmosphere for PostgreSQL, but I think that it needs to be officially supported/integrated for many people to be comfortable with it.
https://trello.com/b/hjBDflxp/meteor-roadmap
There are some good packages on Atmosphere for PostgreSQL, but I think that it needs to be officially supported/integrated for many people to be comfortable with it.
In ToroDB (https://github.com/torodb/torodb) we are currently working on implementing MongoDB's oplog server-side. ToroDB would work seamlessly with Meteor, meaning that at the end of the day your data sits on a PostgreSQL database. Watch out our next coming release! :)
Wow ToroDB looks really cool! Good idea!
Yes, Mongo dependency is a dealbreaker for many people who would like to be using it.
I'm apprehensive of the security model. Everything is highly ease-of-use optimized, to the point that you can query Mongo via the browser console.
My preferred "easy/simple" model of app design is Firebase (backend and JS lib for pure web clients), who have security figured out.
My preferred "easy/simple" model of app design is Firebase (backend and JS lib for pure web clients), who have security figured out.
Meteor's security model allows app developer to validate any operation or RPC going through, based on the arguments or userId (by writing JS code). Also, the published set is controlled by publications, allowing to publish only filtered out data with specific fields.
Unlike Firebase, Meteor actually allows you to send "first top 20 guest posts from November" as an example. The filtering can happen on the server, before sending the data and the data model usually fits into a sets of documents in set of collections. In Firebase, everything is part of a big subtree that is not filterable (the last time I checked).
Firebase is a good choice for keeping your real-time data. But knowing its limitations is as important as knowing its strengths.
Unlike Firebase, Meteor actually allows you to send "first top 20 guest posts from November" as an example. The filtering can happen on the server, before sending the data and the data model usually fits into a sets of documents in set of collections. In Firebase, everything is part of a big subtree that is not filterable (the last time I checked).
Firebase is a good choice for keeping your real-time data. But knowing its limitations is as important as knowing its strengths.
Hey there, I'm Joey, a Firebase dev — last November, we shipped advanced querying support[0] to address this! You can now use orderByChild(), orderByKey() or orderByPriority() to build a query.
We also have limitToFirst(), limitToLast(), startAt(), endAt(), and equalTo() methods to further filter your data.
This allows you to build queries like this:
[0] https://www.firebase.com/blog/2014-11-04-firebase-realtime-q...
[1] https://www.firebase.com/docs/web/api/query/
We also have limitToFirst(), limitToLast(), startAt(), endAt(), and equalTo() methods to further filter your data.
This allows you to build queries like this:
ref.orderByChild("weight").limitToLast(2).on("child_added", function(snapshot) {
console.log(snapshot.key());
});
[0] https://www.firebase.com/blog/2014-11-04-firebase-realtime-q...
[1] https://www.firebase.com/docs/web/api/query/
This is great! I didn't doubt that Firebase will roll out features to paginate and sort data. I also don't doubt that Firebase will implement filtering in the future. Great work.
What you're saying is only true on a barebones default Meteor app. Please don't comment on a tool if you've never used it for anything other than a hello world, you're doing a very sophisticated tool a huge disservice.
You remove the autopublish package and you can no longer query records from the client.
You remove the autopublish package and you can no longer query records from the client.
There's no need to be rude. How many people are going to not know that, or forget? Meteor is highly tailored towards beginners. Additionally, Mongo's out-of-the-box security policies are extremely lax as well, and unsecured Mongo instances in the wild are a huge problem.
I don't necessarily disagree with you, but it's still an astonishingly bad practice as a default.
If there's one thing we should have learned from Rails' various security failures, it's that things must be secure by default.
If there's one thing we should have learned from Rails' various security failures, it's that things must be secure by default.
There's no excuse for insecure defaults.
I disagreed, in OWASP: It is important to understand that by no means does “Secure Defaults” mean turning off all possible network applications or sockets and services. And neither do Secure Defaults mean a 100% secure environment. But, they should ensure the least number of possible loopholes and fewer drawbacks.
Likewise, no matter what languages, majority are insecure by defaults.
Likewise, no matter what languages, majority are insecure by defaults.
What other tech stack allows you to publicly query the application data source by default? I think it's fair to say that shouldn't be possible and I'd be hard pressed to believe that OWASP would disagree with that.
[deleted]
It's more of a development default.
A lot of software engineers are wary of frameworks/tools with an emphasize on ease-of-use over security, or benchmarking over data integrity. Rightly so in my opinion.
It leaves a "I should triple check everything again before going live since I cannot trust the tool to do its job" thread running permanently in the back of the mind. It's such a slowdown. Don't get me wrong, it's important to read the documentation and double check settings, but insanity by default does not build trust.
That said in the case of meteor beyond the autopublish package that should be off by default, I think everything is spot on. I mostly use PostgreSQL, so I cannot use it as much as I'd like to, but hopefully that will change.
It leaves a "I should triple check everything again before going live since I cannot trust the tool to do its job" thread running permanently in the back of the mind. It's such a slowdown. Don't get me wrong, it's important to read the documentation and double check settings, but insanity by default does not build trust.
That said in the case of meteor beyond the autopublish package that should be off by default, I think everything is spot on. I mostly use PostgreSQL, so I cannot use it as much as I'd like to, but hopefully that will change.
I agree with what you're saying, but a lot of people make it look like Meteor allows XSS and SQL Injection by default. You really only need to remove autopublish from the get go right after meteor create foobar and you begin with a secure app.
You should never have to do anything to become secure. The mantra is: secure by design; secure by default; secure by configuration.
In OWASP:
It is important to understand that by no means does “Secure Defaults” mean turning off all possible network applications or sockets and services. And neither do Secure Defaults mean a 100% secure environment. But, they should ensure the least number of possible loopholes and fewer drawbacks.
Anyone remember register_globals in PHP?
Hi Sergio,
One of the things I like about rails (and ember-cli) is that it is "secure-by-default". If I am going to make a choice that potentially has security vulnerabilities, I have to deliberately make that choice - I basically have to create a whitelist of things I want to allow.
One of the things I like about rails (and ember-cli) is that it is "secure-by-default". If I am going to make a choice that potentially has security vulnerabilities, I have to deliberately make that choice - I basically have to create a whitelist of things I want to allow.
> "Everything is ease-of-use optimized, to the point that you can query Mongo via the browser console."
meteor remove autopublish
meteor remove insecure
The Mongo-accessible frontent is genius. This makes your prototyping much faster, and you can totally skip the "model" layer of your frontend. It matches your backend automatically. No further configuration needed. No REST endpoints, no callbacks. And yes, it's secure.
Meteor's security model is very well-designed. The list of things left for the developer to do, security-wise, is very short.
It's still important to learn your tools and understand how security works.
http://docs.meteor.com/
http://security-resources.meteor.com/
https://github.com/themeteorchef/security-essentials
https://www.youtube.com/watch?v=6_3pomxyp8M
meteor remove autopublish
meteor remove insecure
The Mongo-accessible frontent is genius. This makes your prototyping much faster, and you can totally skip the "model" layer of your frontend. It matches your backend automatically. No further configuration needed. No REST endpoints, no callbacks. And yes, it's secure.
Meteor's security model is very well-designed. The list of things left for the developer to do, security-wise, is very short.
It's still important to learn your tools and understand how security works.
http://docs.meteor.com/
http://security-resources.meteor.com/
https://github.com/themeteorchef/security-essentials
https://www.youtube.com/watch?v=6_3pomxyp8M
Well, you can start using JS for your API server, at least. Nodal [1], a full-featured API server and framework for iojs was just released yesterday with full PostgreSQL integration. (Migration and schema support, to boot.) :)
I'm not a huge fan of isomorphic JavaScript. While it seems great for prototyping, I have doubts on its stability, security, and ability to scale. It seems to be a knee-jerk reaction to just having the technology to write web-client and web-server code in the same language and the emergence of SPAs.
The thing is, we've had working client-server application architecture (which is what an SPA is) for decades. Every multiplayer game you've ever played. Chat programs. Etc. Nobody would risk the headache of tightly-coupling your data layer, presentation layer, and business layer just to save a few lines of code. We separate our concerns in our code itself with MVC frameworks, why are isomorphic frameworks trying to tightly-couple our actual application layers? It's a little bit contradictory to me.
While Meteor seems like a great tool for a couple of newbie developers to rapidly prototype an idea, I'm still not convinced it has the potential to grow into a reasonable architecture.
[1] https://github.com/keithwhor/nodal
I'm not a huge fan of isomorphic JavaScript. While it seems great for prototyping, I have doubts on its stability, security, and ability to scale. It seems to be a knee-jerk reaction to just having the technology to write web-client and web-server code in the same language and the emergence of SPAs.
The thing is, we've had working client-server application architecture (which is what an SPA is) for decades. Every multiplayer game you've ever played. Chat programs. Etc. Nobody would risk the headache of tightly-coupling your data layer, presentation layer, and business layer just to save a few lines of code. We separate our concerns in our code itself with MVC frameworks, why are isomorphic frameworks trying to tightly-couple our actual application layers? It's a little bit contradictory to me.
While Meteor seems like a great tool for a couple of newbie developers to rapidly prototype an idea, I'm still not convinced it has the potential to grow into a reasonable architecture.
[1] https://github.com/keithwhor/nodal
Postgresql would be great, though if they wanted to keep the document style database of Mongo, maybe they could use something like RethinkDB and use its javascript driver?
Folks are working on it: https://github.com/numtel/meteor-pg. Also there are plans for core support down the road.
Oh I know, the guys are very open about the roadmap, they have a Trello board. I'm counting the days where I can finally go all in with Meteor. Everyone I know IRL is excited for Meteor but Mongo is what kept everyone sort of away.
I've heard the sales pitch for ember and ember-cli and I've seriously begun developing with Ember for the past 2 weeks. So far, I really like the tooling around Ember but am not a huge fan of the actual framework itself.
I mean, you have routers, routes, controllers, views, templates, and components - how many concepts do you need to display a ui?
Maybe it's just that I can't see the forest through the trees. Perhaps you could help me gain this perspective?
I mean, you have routers, routes, controllers, views, templates, and components - how many concepts do you need to display a ui?
Maybe it's just that I can't see the forest through the trees. Perhaps you could help me gain this perspective?
[deleted]
You have just one router, and that's only a config file that maps URLs to routes.
They're dropping controllers and views in a month, with Ember 2.0. They're being replaced by components.
So really you will only work with routes and components - which should make things much easier to understand.
They're dropping controllers and views in a month, with Ember 2.0. They're being replaced by components.
So really you will only work with routes and components - which should make things much easier to understand.
I know that there are talking about "routable components" with one-way data flow (ala react/flux), which hopefully comes soon. Are templates still being kept?
It seems like Ember is going to become a bit more like React (which I'm very fine with).
It seems like Ember is going to become a bit more like React (which I'm very fine with).
My take on this is that Meteor (and mongo) is perfectly sized platform for individuals and SMBs. If you make a consumer thing meteor will work too as an MVP, but you'd almost certainly rewrite the backend to use more bespoke code (e.g. in Java REST SOA over Postgres etc.)
I think the primary focus on further development in Meteor should be supporting additional databases officially, and after that, supporting operational transformation and conflict resolution strategies come to mind. In my opinion, they are the biggest hurdles towards creating reliable real-time applications.
Official React or Angular support isn't a game-changer. They can already be integrated easily with the reactive data providers.
Official React or Angular support isn't a game-changer. They can already be integrated easily with the reactive data providers.
I do believe that the Meteor team is working on those database strategies as well as scalability and deployability on top of their push for mobile. Taking a look at who they are hiring (and their job descriptions) is very telling. It should be exciting to see what they come up with!
How often do you need OT in practice?
Depends on what you're doing. I'm needing it for my thesis -> app and will probably use ShareJS for now.
Lol Meteor just literally saved my bacon, the combination of meteor + ionic enabled me to build an entire app in less than two weeks working part time on it and if I hadn't told the client it wasn't native there was no way for them to tell, the performance is that good. Plus the error messaging is awesome and the isometric approach is just a huge win, the previous version of the product was in angular + rails, industry standard but slow as hell, absolutely did not perform like a native mobile app, but Meteor is just fantastic in my experience for extreme starup scenarios where we are going with Mongo anyways. Certainly if I needed to tie into legacy sql based systems I would be looking at loopback, but with lookback you are still stuck with the weight of the other available front end frameworks and the back end is easier, but you still have to do tons of boiler plate, except perhaps with react + loopback in the case of place a really modern front end on a legacy system while still having ok performance. Meteor feels native because you're not issuing all this old ajax, its data format is even smaller and tighter than json.
I just wish it wasn't so tightly integrated into everything. I'd love to use Meteor as a library, but I'm always afraid of choosing something that I can't replace later.
Either way, best of luck to them!
Either way, best of luck to them!
You could always use the DDP library [1] ("REST for websockets") for realtime transfer. It's separate from the "core" Meteor package (a collection of packages, really).
There's also a list of libraries for other languages that communicate with Meteor via DDP. [2]
[1] https://www.meteor.com/ddp [2] http://meteorpedia.com/read/DDP_Clients
There's also a list of libraries for other languages that communicate with Meteor via DDP. [2]
[1] https://www.meteor.com/ddp [2] http://meteorpedia.com/read/DDP_Clients
[deleted]
I'm actually looking into meteor at the moment, and the financial backing is a big plus, as it gives me some guarantee that the project will keep being maintained for the foreseeable future.
It is indeed a breeze to prototype applications with it, but I am a little bit concerned about the costs of getting an actual production ready site with it.
For intance, when is it ever OK to let your client write directly in the database, even for their own data? If you're going to pass their calls through a deny and allow call, why not just expose RPCs to the client that will handle any writing?
It seems that a lot of the light versality you have at prototyping time is lost whenever you have to get it production ready. There is definitely some value in light prototypes, but it looks like a real pain to go from prototype to production.
Likewise, I'm confused about how to get around the limitations of mongodb. Say you run a store with a finite inventory, how do you handle concurrent purchases? How about a website to enroll into classes? How about a webforum which can have exactly 5 administrators?
It is indeed a breeze to prototype applications with it, but I am a little bit concerned about the costs of getting an actual production ready site with it.
For intance, when is it ever OK to let your client write directly in the database, even for their own data? If you're going to pass their calls through a deny and allow call, why not just expose RPCs to the client that will handle any writing?
It seems that a lot of the light versality you have at prototyping time is lost whenever you have to get it production ready. There is definitely some value in light prototypes, but it looks like a real pain to go from prototype to production.
Likewise, I'm confused about how to get around the limitations of mongodb. Say you run a store with a finite inventory, how do you handle concurrent purchases? How about a website to enroll into classes? How about a webforum which can have exactly 5 administrators?
> For intance, when is it ever OK to let your client write directly in the database, even for their own data? If you're going to pass their calls through a deny and allow call, why not just expose RPCs to the client that will handle any writing?
Good question. A pattern I like to use for this in Meteor is to rely solely on their Method calls which allow you to restrict any database ops to the server side. The trick is that you lock down all client-side writing from the get go so you're not trying to guess whether you set your rules properly. Here's an example of that pattern: https://gist.github.com/themeteorchef/194a803f8a28840f475f.
Re: concurrent purchases in your store example, you can actually strip reactivity from certain database queries. So, on the front-end you can prevent state shifting out from under users. To control data on the server, you could have a method that checks whether or not the inventory has been depleted before allowing certain operations (e.g. routing to a new page, manipulating the database, etc). Definitely possible to do this without going bonkers.
Does that answer what you're looking for?
Good question. A pattern I like to use for this in Meteor is to rely solely on their Method calls which allow you to restrict any database ops to the server side. The trick is that you lock down all client-side writing from the get go so you're not trying to guess whether you set your rules properly. Here's an example of that pattern: https://gist.github.com/themeteorchef/194a803f8a28840f475f.
Re: concurrent purchases in your store example, you can actually strip reactivity from certain database queries. So, on the front-end you can prevent state shifting out from under users. To control data on the server, you could have a method that checks whether or not the inventory has been depleted before allowing certain operations (e.g. routing to a new page, manipulating the database, etc). Definitely possible to do this without going bonkers.
Does that answer what you're looking for?
Yes, thanks, sort of! The pattern you use is basically the one I would naturally do, but it doesn't feel "meteoritic"... the client side manipulation of the db really seems centric to the magic of it.
Regarding the concurrent store, forget event about the client. You need to check whether or not the inventory has been depleted and then update the inventory, and create the client's invoice. That means blocking calls, double staged commits, and a whole lot of nasty things that have nothing to do with reactivity and everything to do with integrity.
Regarding the concurrent store, forget event about the client. You need to check whether or not the inventory has been depleted and then update the inventory, and create the client's invoice. That means blocking calls, double staged commits, and a whole lot of nasty things that have nothing to do with reactivity and everything to do with integrity.
> but it doesn't feel "meteoritic"... the client side manipulation of the db really seems centric to the magic of it.
In the prototyping sense, yes. I've been working with Meteor for about two years and the pattern I shared above still feels magical when you realize what it's doing in just a few minutes of work. The client-side writes are still okay. The big problem is remembering to specify the correct allow/deny rules.
The pattern above is a sort of brute force approach to saying "I'm an idiot, I'll forget to set rules, let's make this a non-issue." Of note, I recall some chatter about dropping allow/deny rules altogether in the future, so there's likely a better solution on the horizon.
> You need to check whether or not the inventory has been depleted and then update the inventory, and create the client's invoice.
This isn't as big of a problem as it's being made out to be. Really just a few lines of code, e.g.:
```
// Fetch just makes this an array instead of a Mongo cursor.
// The fields part just strips the returned object(s) back
// with only those fields + the _id of the object.
var inventoryAvailable = Inventory.find({product: productName}, {fields: {"available": 1}}).fetch();
if ( inventoryAvailable.available > 1 ) { // Call some purchase function. } else { // Throw an error back to the client. }
```
Re: the concern around race conditions between customers, Meteor could actually have a leg up on this. Because you have reactivity, if say there was only 1 of an item left, if one customer completed the purchase before another, you could throw up an overlay on the slower customers screen saying "uh oh, the last one of these just got snatched up...get on the waiting list?"
A lot of ways to skin this cat :)
In the prototyping sense, yes. I've been working with Meteor for about two years and the pattern I shared above still feels magical when you realize what it's doing in just a few minutes of work. The client-side writes are still okay. The big problem is remembering to specify the correct allow/deny rules.
The pattern above is a sort of brute force approach to saying "I'm an idiot, I'll forget to set rules, let's make this a non-issue." Of note, I recall some chatter about dropping allow/deny rules altogether in the future, so there's likely a better solution on the horizon.
> You need to check whether or not the inventory has been depleted and then update the inventory, and create the client's invoice.
This isn't as big of a problem as it's being made out to be. Really just a few lines of code, e.g.:
```
// Fetch just makes this an array instead of a Mongo cursor.
// The fields part just strips the returned object(s) back
// with only those fields + the _id of the object.
var inventoryAvailable = Inventory.find({product: productName}, {fields: {"available": 1}}).fetch();
if ( inventoryAvailable.available > 1 ) { // Call some purchase function. } else { // Throw an error back to the client. }
```
Re: the concern around race conditions between customers, Meteor could actually have a leg up on this. Because you have reactivity, if say there was only 1 of an item left, if one customer completed the purchase before another, you could throw up an overlay on the slower customers screen saying "uh oh, the last one of these just got snatched up...get on the waiting list?"
A lot of ways to skin this cat :)
Do yourself a favor and set aside a weekend to go through this book: https://www.discovermeteor.com/
All of your questions are answered there.
All of your questions are answered there.
As an onlooker that's discouraging. Can you give one-line answers to the points above?
Other users have answered these pretty well by now, I'd just like to add to the discussion of this question:
>Likewise, I'm confused about how to get around the limitations of mongodb. Say you run a store with a finite inventory, how do you handle concurrent purchases? How about a website to enroll into classes? How about a webforum which can have exactly 5 administrators?
A quick&easy for me has been to just set up a separate REST API to handle critical data like payments and just have a two-server app. Doesn't really add to development time vs a unified server. Meteor doesn't preclude SQL use, it just doesn't support reactive SQL off the shelf like it does Mongo.
It's not cheap and I can't even find a table of content for it. I've also read excerpts that dealt with autopublish etc, and they didn't really address the point I'm making.
Is there a benefit to using meteor beyond the fast prototyping? I'm not saying that's not potentially a huge benefit, but once you're done with your prototype, I still feel like you have to rewrite the whole thing.
Is there a benefit to using meteor beyond the fast prototyping? I'm not saying that's not potentially a huge benefit, but once you're done with your prototype, I still feel like you have to rewrite the whole thing.
Removing autopublish and writing methods is not the same thing as rewriting the whole thing. But if you want to skip autopublish, you can do so from the beginning. As mentioned elsewhere the ability to perform a database action initially on the client allows for latency compensation, which is a significant user benefit beyond fast prototyping.
The table of contents is right there on the homepage. And you can read the first four chapters for free here: http://book.discovermeteor.com
> For intance, when is it ever OK to let your client write directly in the database, even for their own data? If you're going to pass their calls through a deny and allow call, why not just expose RPCs to the client that will handle any writing?
If you have a client-side mirror of your server-side database whose changes are monitored by the templating engine, you can execute what Meteor calls "latency compensation", where changes users make are instantly reflected in the UI and synced to the server in the background. This is a central feature of Meteor. More here: https://www.meteor.com/full-stack-db-drivers and in this Youtube video: https://www.youtube.com/watch?v=tqLbodVH3dw
> It seems that a lot of the light versality you have at prototyping time is lost whenever you have to get it production ready. There is definitely some value in light prototypes, but it looks like a real pain to go from prototype to production.
It's actually very easy to go from prototype to production; you just remove some convenience packages (autopublish and insecure), set up your security rules, do some basic performance tuning (eg. don't publish entire documents if you only need 3 fields, which is a standard practice for any app) and that's about it. Of course the definition of "production" varies per project, but after shipping over 20 Meteor apps since 2012 these are the most common things I tend to do.
> Likewise, I'm confused about how to get around the limitations of mongodb. Say you run a store with a finite inventory, how do you handle concurrent purchases? How about a website to enroll into classes? How about a webforum which can have exactly 5 administrators?
You can express most of these in code. Yes, in relational databases you can express constraints in the database. But then you're having a NoSQL vs SQL debate, which is sort of out of scope of this discussion.
If you have a client-side mirror of your server-side database whose changes are monitored by the templating engine, you can execute what Meteor calls "latency compensation", where changes users make are instantly reflected in the UI and synced to the server in the background. This is a central feature of Meteor. More here: https://www.meteor.com/full-stack-db-drivers and in this Youtube video: https://www.youtube.com/watch?v=tqLbodVH3dw
> It seems that a lot of the light versality you have at prototyping time is lost whenever you have to get it production ready. There is definitely some value in light prototypes, but it looks like a real pain to go from prototype to production.
It's actually very easy to go from prototype to production; you just remove some convenience packages (autopublish and insecure), set up your security rules, do some basic performance tuning (eg. don't publish entire documents if you only need 3 fields, which is a standard practice for any app) and that's about it. Of course the definition of "production" varies per project, but after shipping over 20 Meteor apps since 2012 these are the most common things I tend to do.
> Likewise, I'm confused about how to get around the limitations of mongodb. Say you run a store with a finite inventory, how do you handle concurrent purchases? How about a website to enroll into classes? How about a webforum which can have exactly 5 administrators?
You can express most of these in code. Yes, in relational databases you can express constraints in the database. But then you're having a NoSQL vs SQL debate, which is sort of out of scope of this discussion.
Sure you remove the autopublish package, but then your app stops working. You need to explicitely publish what you want published, you need to explicitely check and validate every input from the client... and that's fine, but then what exactly have you gained from using meteor over, say, socket.io or autobahn? Fast prototyping, yes, you've definitely gained that, but have you gained anything else? I'm genuinely asking, not making a rhetorical point.
Since meteor integrates very tightly with mongodb, a nosql database, I don't see how the limitations of nosql are out of the scope of the discussion? I also don't know what you mean by "you express most of these in code". The problem isn't writing a piece of code that expresses that constraint... the problem is doing so without introducing a race condition!
Since meteor integrates very tightly with mongodb, a nosql database, I don't see how the limitations of nosql are out of the scope of the discussion? I also don't know what you mean by "you express most of these in code". The problem isn't writing a piece of code that expresses that constraint... the problem is doing so without introducing a race condition!
To answer your first question, there are a number of attractive advantages to using Meteor over say socket.io or autobahn on top of Node. One major one would be a consistent API for accessing your data on the Client and Server. I would argue that using Javascript on both backend and frontend with Node boosts a developer's productivity by reducing language/context switching. In the same vein accessing data using the Mongo query api on both backend and front end with Meteor's MiniMongo improves development. Also Meteor comes with built-in latency compensation when using either RPCs (with stubs on the client) or Minimongo operations. Latency compensation is a non-trivial problem which would need to be implemented by the developer when using something like socket.io. You also gain access to a growing list of great packages that implement things like user accounts which you would otherwise need to write yourself or wire together from various projects.
As for your second question. There are certainty use cases where MongoDB isn't appropriate, and support for other databases is on Meteor's roadmap. For now there are some community created packages for interfacing directly with SQL databases in place of MongoDB, but there are a number of issues with them. You could also pipe data in and out of an SQL database inside RPCs, however the data would not be updated in 'real-time' to clients. I anticipate SQL databases will get some good support options in time.
As for your second question. There are certainty use cases where MongoDB isn't appropriate, and support for other databases is on Meteor's roadmap. For now there are some community created packages for interfacing directly with SQL databases in place of MongoDB, but there are a number of issues with them. You could also pipe data in and out of an SQL database inside RPCs, however the data would not be updated in 'real-time' to clients. I anticipate SQL databases will get some good support options in time.
> I also don't know what you mean by "you express most of these in code". The problem isn't writing a piece of code that expresses that constraint... the problem is doing so without introducing a race condition!
I agree, and this also exposes a weakness of javascript as a backend language. If you use Java/Scala, you have multithreading support and can sync the threads + concurrently verify that an item isn't being purchased more than X times. Which makes this problem solvable even with a NoSQL database. Javascript is single threaded though, which makes this problem a lot harder and I don't know how you'd solve it without an RDBMS with transactional support.
I agree, and this also exposes a weakness of javascript as a backend language. If you use Java/Scala, you have multithreading support and can sync the threads + concurrently verify that an item isn't being purchased more than X times. Which makes this problem solvable even with a NoSQL database. Javascript is single threaded though, which makes this problem a lot harder and I don't know how you'd solve it without an RDBMS with transactional support.
> If you use Java/Scala, you have multithreading support and can sync the threads + concurrently verify that an item isn't being purchased more than X times.
That does cause you to have a hard limit of one application server for the app, which can be a pretty big deal...
That does cause you to have a hard limit of one application server for the app, which can be a pretty big deal...
No, you could have multiple servers talking to each other via something like ZooKeeper. But individually, each node/server would use multithreading to keep track of its state.
I guess, but that's some monumental hackery to overcome something that works perfectly fine in an RDBMS :-)
Until the time comes when you need to scale out your RDBMS and need to shard it. IMO that's a bigger pain ;).
Plus if you have multiple servers, they will most likely need to pass messages for other things too.
Plus if you have multiple servers, they will most likely need to pass messages for other things too.
I dunno - you've presumably got to implement code to make sure that other servers get unlocked when your locking app server goes down, for example. Personally I try to avoid implementing ad-hoc distributed systems if I can avoid it. Having to shard is pretty damn crappy, but under the circumstances I'd favour it.
Further, I tend to think that if your application is heavy enough to outgrow a reasonably fat db server with (say) 500+GB of RAM, strategies like reimplementing consistent-db-esque locking in an app server + zookeeper setup are also likely to hit some pretty weird performance issues.
Further, I tend to think that if your application is heavy enough to outgrow a reasonably fat db server with (say) 500+GB of RAM, strategies like reimplementing consistent-db-esque locking in an app server + zookeeper setup are also likely to hit some pretty weird performance issues.
> you've presumably got to implement code to make sure that other servers get unlocked when your locking app server goes down
Don't see why you'd need locking. Node A receives a request to buy an item, A asks nodes B, C, and D to confirm that the item is in stock in each node's internal state. If all give the OK, A lets the purchase go through. If node B goes down, then A just asks C and D. I don't see the need for locking or a master/slave.
> a reasonably fat db server with (say) 500+GB of RAM
You have a single point of failure with a single, monolithic server. If its hd dies, you will be in serious trouble restoring terabytes of db.
Don't see why you'd need locking. Node A receives a request to buy an item, A asks nodes B, C, and D to confirm that the item is in stock in each node's internal state. If all give the OK, A lets the purchase go through. If node B goes down, then A just asks C and D. I don't see the need for locking or a master/slave.
> a reasonably fat db server with (say) 500+GB of RAM
You have a single point of failure with a single, monolithic server. If its hd dies, you will be in serious trouble restoring terabytes of db.
EDIT: On rereading it occurs to me that I'm getting caught up in poking holes here. The proposed ZooKeeper solution will likely work fine in the simple case, if used with care and attention. It gives me the willies a bit (because I don't think it's a good idea to force users to separate locking from the DB level), but as long as the use case is restricted to compare + set on a single document, there's little reason to think that there's much wrong with it. Apologies if I come across as belligerent.
-----
> Don't see why you'd need locking. Node A receives a request to buy an item, A asks nodes B, C, and D to confirm that the item is in stock in each node's internal state. If all give the OK, A lets the purchase go through. If node B goes down, then A just asks C and D. I don't see the need for locking or a master/slave.
Presumably in order to ensure that B, C, and D can consistently check the object's state, nothing else can be allowed to write to it at that time - A effectively has to lock the object using zookeeper. You then have to make sure that the object gets unlocked if A goes down after locking it, or most particularly if A hangs, keeping the zookeeper session open? Otherwise your other app servers could get caught in a very long or infinite lock wait.
You've also got to keep track of the rest of your code, and make sure it never alters these same objects without locking. I'm assuming here that you only distributed-lock objects when you absolutely have to, in order to improve performance: otherwise you're going to start hitting some of the issues that make it hard to cluster relational DBs with decent performance (modulo some coarser lock granularity for a document-based system).
As you add complexity to this approach (say, perhaps you need to work on two objects at once), you also start having to think about other problems like deadlocking, or what happens if your zookeeper session fails part way through your work, where you've made half of the changes you want to make, and you can't easily roll back. This is all fine if you have programmers who are competent to think about these kinds of problems, but they're typically pretty expensive - and my experience is that most people just don't really bother to think about it.
> You have a single point of failure with a single, monolithic server. If its hd dies, you will be in serious trouble restoring terabytes of db.
Any system of value will of course have a replica, meaning you're perhaps more likely to be worried about network problems than the server falling over. Of course this is still less reliable than a perfectly implemented multi-master distributed system, but it's also hugely easier to use correctly - and the likelihood of failure of a single node is actually very low. Obviously if you literally cannot afford any downtime, maybe you go with a distributed system (or follow the banks and use mainframes..), but businesses that will be killed by network blips are certainly in the minority.
-----
> Don't see why you'd need locking. Node A receives a request to buy an item, A asks nodes B, C, and D to confirm that the item is in stock in each node's internal state. If all give the OK, A lets the purchase go through. If node B goes down, then A just asks C and D. I don't see the need for locking or a master/slave.
Presumably in order to ensure that B, C, and D can consistently check the object's state, nothing else can be allowed to write to it at that time - A effectively has to lock the object using zookeeper. You then have to make sure that the object gets unlocked if A goes down after locking it, or most particularly if A hangs, keeping the zookeeper session open? Otherwise your other app servers could get caught in a very long or infinite lock wait.
You've also got to keep track of the rest of your code, and make sure it never alters these same objects without locking. I'm assuming here that you only distributed-lock objects when you absolutely have to, in order to improve performance: otherwise you're going to start hitting some of the issues that make it hard to cluster relational DBs with decent performance (modulo some coarser lock granularity for a document-based system).
As you add complexity to this approach (say, perhaps you need to work on two objects at once), you also start having to think about other problems like deadlocking, or what happens if your zookeeper session fails part way through your work, where you've made half of the changes you want to make, and you can't easily roll back. This is all fine if you have programmers who are competent to think about these kinds of problems, but they're typically pretty expensive - and my experience is that most people just don't really bother to think about it.
> You have a single point of failure with a single, monolithic server. If its hd dies, you will be in serious trouble restoring terabytes of db.
Any system of value will of course have a replica, meaning you're perhaps more likely to be worried about network problems than the server falling over. Of course this is still less reliable than a perfectly implemented multi-master distributed system, but it's also hugely easier to use correctly - and the likelihood of failure of a single node is actually very low. Obviously if you literally cannot afford any downtime, maybe you go with a distributed system (or follow the banks and use mainframes..), but businesses that will be killed by network blips are certainly in the minority.
Here's step 10 of the tutorial, which demonstrates how you can write custom RPCs to handle writing data in Meteor: https://www.meteor.com/try/10
You don't have to use the client-side insert/update/remove syntax if you don't want to. Unless you add an 'allow' call to let some of them through, they will all be automatically rejected by the server.
(I work at Meteor)
You don't have to use the client-side insert/update/remove syntax if you don't want to. Unless you add an 'allow' call to let some of them through, they will all be automatically rejected by the server.
(I work at Meteor)
Thank you, I know that you can do that. My concern is more of a soft question: in practice, in production, isn't that what you always end up doing anyway? And if that's the case, how much of meteor's coolness is lost in the process? If I'm going to be writing rpcs for all writes, why not just use some websocket library?
Meteor's RPCs support automatic optimistic UI updates, where the same code can be used to update the client side data store and the server side database, resulting in the perception of zero latency between server and client.
Building that functionality out yourself from scratch could be difficult, since all of the components of Meteor work together to make that experience possible.
Building that functionality out yourself from scratch could be difficult, since all of the components of Meteor work together to make that experience possible.
Has anyone seen DDP used outside of Meteor? https://github.com/meteor/meteor/blob/devel/packages/ddp/DDP...
I haven't seen a push for it outside of Meteor yet, but i'm sure that is one of the things that they would want to push for later.
Although, there are various DDP clients for other languages as you can see here: http://meteorpedia.com/read/DDP_Clients
Although, there are various DDP clients for other languages as you can see here: http://meteorpedia.com/read/DDP_Clients
(I work at Meteor).
There have been some discussions with Asana (asana.com) teams who are building their new data store with a DDP API published for their clients.
There have been some discussions with Asana (asana.com) teams who are building their new data store with a DDP API published for their clients.
We use it to interface with our Django projects https://github.com/commoncode/django-ddp/
One example: https://github.com/whitesmith/meteor-motion
I'm writing an Arduino library at the moment as a small part of my thesis which I'll release.
Is anyone here running Meteor in production? I've seen so many intro's and demo's and prototypes but have yet to see any actual products / companies built around it yet.
A couple months ago we launched edgee, a platform for sharing high-quality content in carefully curated collections, called edgees. The app runs on Meteor and we're very happy with it.
http://www.edgee.com
I browse with cookies disabled for privacy reasons.
How is it that every time I visit a webpage made with meteor, the only thing I get is a blank page ? Is it specific to meteor to not work without cookies enabled, couldn't it at least display a message asking me to enable cookies, even an error page explaining why I get nothing but a white background.
Great site, awesome UI. I'm also working on a web app using Meteor. This just gave me some inspiration.
Thanks for the kind words :)
Check their home page - and those exact words you used just now, those look awfully familiar to what people used to write when Rails first came out. :)
I have such high hopes for Meteor!
I have such high hopes for Meteor!
Sidebar.io is based on Telescope which powers a number of sites: http://sidebar.io/
Hmm. Sidebar is an example of a site that has no reason to use client-side scripting at all. It's a plain list of links, and yet doesn't work without Javascript, and is far, far slower than it should be.
A good summary of pop-webdev in 2015
Creator of Sidebar here. You're right, it's not the best showcase of Meteor. The reason it's this way is because it's running on a very old fork of Telescope (http://telescopeapp.org), and I haven't had time to update it.
But you make some good points. Meteor is not for everything, and if I had known from the start that Sidebar would end up being just a list of links I might have used a different stack (like Rails, or even a static site generator).
But you make some good points. Meteor is not for everything, and if I had known from the start that Sidebar would end up being just a list of links I might have used a different stack (like Rails, or even a static site generator).
Workpop is a large production app running on Meteor. They also raised $7.9m http://techcrunch.com/2014/09/16/workpop/
I have two Quora answers on similar questions:
- http://www.quora.com/Which-startups-use-Meteor-in-production - http://www.quora.com/What-open-source-software-uses-Meteor-f...
- http://www.quora.com/Which-startups-use-Meteor-in-production - http://www.quora.com/What-open-source-software-uses-Meteor-f...
I like meteor, I think it's a good framework, that solves well the "Make a webapp with non critical data but where real time is critical" problem.
I've also used angular, which I also like, but has a little bit more of a learning curve drawback.
I do unfortunately believe that a project or framework should make it not because it's CEO or leader is good at selling something, pitching VC's, and creating a brand, I think a project or framework should make it because it is the crowdsourced best solution to a problem. And this kind of money raising worries me a little, because it gives an unfair advantage to a framework. Now meteor might be the best answer, but if it's not, this is a shame and we all stand to miss out on a potential right answer for this...
Anyway, all of this is a little moot because I believe you shouldn't be using javascript for this kind of stuff ^^ but that's another debate altogether
I've also used angular, which I also like, but has a little bit more of a learning curve drawback.
I do unfortunately believe that a project or framework should make it not because it's CEO or leader is good at selling something, pitching VC's, and creating a brand, I think a project or framework should make it because it is the crowdsourced best solution to a problem. And this kind of money raising worries me a little, because it gives an unfair advantage to a framework. Now meteor might be the best answer, but if it's not, this is a shame and we all stand to miss out on a potential right answer for this...
Anyway, all of this is a little moot because I believe you shouldn't be using javascript for this kind of stuff ^^ but that's another debate altogether
In the long run, you'll probably be happier if you realize there are no "right" answers in software engineering. People who can't get past the belief that there is spend a lot of their time telling kids to get off their lawn.
[deleted]
It's way too late for that anyway. AFAIK DerbyJS was better than Meteor all along but no one has heard of it.
I've heard of it and have used both and disagree.
Keep in mind both are open source projects. The community has been immensely successful filling up Meteor's gaps.
Keep in mind both are open source projects. The community has been immensely successful filling up Meteor's gaps.
The investors are extremely appreciative of that... it'd be a shame if they had to invest in actual filling out their own gaps with the 20M they've raised.
That money is better spent convincing other developers that Meteor has no gaps.
That money is better spent convincing other developers that Meteor has no gaps.
I don't agree about the unfairness or that it will have a negative effect. But I do think that Meteor's nature as a framework, might be its downfall as a company. I have a hard time imagining how Meteor is going to be able to contain or maintain control over the project given how broad it is. They'll need to provide really strong integration benefits to fight unbundling.
This is not a zero sum game.
I think the main issue with Meteor is that it has the possibility to change the status quo and be an important player in the market. That 'pisses' a lot of people (like once rails did) because it might turn some of their personal investment into obsolete. I am not 'invested' (my background is not CS) but if I was, I would certainly be pissed also.
People here are even pissed that they got more money and other frameworks didn't. Nobody invest (their money at least) without a good risk/reward ratio.
People here are even pissed that they got more money and other frameworks didn't. Nobody invest (their money at least) without a good risk/reward ratio.
Not trying to sound like a jerk, but I'm just wondering is it really a good thing to put on your homepage that there are nearly 12K questions posted on StackOverflow about Meteor? Seeing a number like that makes me wonder if maybe the documentation and or APIs are not very well done if it's generated that kind of activity on SO.
Maybe you're right and everyone else on this comment thread are suffering from some cognitive dissonance?
I'd be willing to bet much of those SO questions and replies are a part of keeping up the Meteor hype with most questions being answered by a core group of devs.
The PR machine for Meteor is crazy. It's funny because this 20M will go to generating more hype and PR opportunities, while the actual development will fall to these wide-eyed open-source evangelists who will give up their time for free to make it better.
Then Meteor will be sold to Facebook and all these open source developers will realize that their work was driving up the valuation for a bunch of investors who couldn't care less about their code or the products it powered.
I'm having a relatively cynical day, I can't tell if I woke up this way or if this Meteor news is what set me off.
I'd be willing to bet much of those SO questions and replies are a part of keeping up the Meteor hype with most questions being answered by a core group of devs.
The PR machine for Meteor is crazy. It's funny because this 20M will go to generating more hype and PR opportunities, while the actual development will fall to these wide-eyed open-source evangelists who will give up their time for free to make it better.
Then Meteor will be sold to Facebook and all these open source developers will realize that their work was driving up the valuation for a bunch of investors who couldn't care less about their code or the products it powered.
I'm having a relatively cynical day, I can't tell if I woke up this way or if this Meteor news is what set me off.
I wonder where all of the dislike for Meteor originated. It's a cool product built buy some really smart people. They have the best cli tool I've used in a dev environment, and they're making a ton of progress. They're constantly publishing materials on integrating with third-party components including react, rethinkdb, famo.us.
I hear you about the potential implosion by acquisition. It's definitely a risk. It's not much different than other burgeoning technologies in that regard.
Meteor is advancing a new paradigm of building consumer applications, much like Django and Rails did for REST. It lowers the barrier to entry, and it really has the potential to expose a new generation of programmers to modern techniques.
I also think they've been pretty clear about when Meteor is unsuitable, despite the hype. It's not going to magically scale. It's not a bad place to start, though.
I hear you about the potential implosion by acquisition. It's definitely a risk. It's not much different than other burgeoning technologies in that regard.
Meteor is advancing a new paradigm of building consumer applications, much like Django and Rails did for REST. It lowers the barrier to entry, and it really has the potential to expose a new generation of programmers to modern techniques.
I also think they've been pretty clear about when Meteor is unsuitable, despite the hype. It's not going to magically scale. It's not a bad place to start, though.
Seems to me I'm one of the few people who are willing to openly express their dislike while also having a real life use case where it caused harm to a startup actively seeking funding.
I was brought into a company where the lead dev was doing everything in Meteor, if I wasn't open to Meteor at the time I would not have taken the job. Over the course of 6 months I watched this dev utilize their ability to sound smart to fool everyone into thinking Meteor was the right tool for the job when they really just wanted to become a Meteor expert since they thought this would be the next .NET that would give them sweet cushy consulting gigs in industries with crazy technology budgets.
I worked with the technology and was unimpressed. Everything needs to go through Meteor and it leaves no room for flexibility. Going with Meteor is an all-in strategy... and anyone who knows strategy ought to know that going all-in is for when you're exceedingly confident or exceedingly desperate.
I recognize Meteor's utility as a rapid prototyping tool. I will openly say anywhere that if you have little development resources and want to build out a proof of concept. Yes, utilize Meteor. But if you don't throw it away after you've shown whoever needs the proof, you are asking for trouble.
The problem with lowering the bar with a new paradigm exposed to a new generation of programmers is that they're being taught bad habits and bad patterns. Tightly coupling the front and back end (what "isomorphic javascript" really means) is Meteor's main selling point. Tight coupling of systems is a universally accepted anti-pattern and anyone who has a product that eventually requires flexibility in their client-server communication is going to find themselves stuck when everyone just stares blankly repeating "but... DDP?"
Creating a new generation of programmers who call themselves rockstars because they know how to run a couple Meteor CLI commands and make a Todo list app in 20 minutes is not going to make the Internet a better place.
I was brought into a company where the lead dev was doing everything in Meteor, if I wasn't open to Meteor at the time I would not have taken the job. Over the course of 6 months I watched this dev utilize their ability to sound smart to fool everyone into thinking Meteor was the right tool for the job when they really just wanted to become a Meteor expert since they thought this would be the next .NET that would give them sweet cushy consulting gigs in industries with crazy technology budgets.
I worked with the technology and was unimpressed. Everything needs to go through Meteor and it leaves no room for flexibility. Going with Meteor is an all-in strategy... and anyone who knows strategy ought to know that going all-in is for when you're exceedingly confident or exceedingly desperate.
I recognize Meteor's utility as a rapid prototyping tool. I will openly say anywhere that if you have little development resources and want to build out a proof of concept. Yes, utilize Meteor. But if you don't throw it away after you've shown whoever needs the proof, you are asking for trouble.
The problem with lowering the bar with a new paradigm exposed to a new generation of programmers is that they're being taught bad habits and bad patterns. Tightly coupling the front and back end (what "isomorphic javascript" really means) is Meteor's main selling point. Tight coupling of systems is a universally accepted anti-pattern and anyone who has a product that eventually requires flexibility in their client-server communication is going to find themselves stuck when everyone just stares blankly repeating "but... DDP?"
Creating a new generation of programmers who call themselves rockstars because they know how to run a couple Meteor CLI commands and make a Todo list app in 20 minutes is not going to make the Internet a better place.
How did Meteor fail and cause harm?
It sounds like you were in an organization where there was some fundamental disagreement that caused the contention.
I don't have any skin in the game, but I find this account to be an unfair characterization of Meteor, so I'd like to refute some of your claims.
First, I really don't know where you got the idea that Meteor is an all-or-nothing stack. Sure, it provides everything you need, but you're not compelled to use what it provides. Meteor works very well with all sorts tech.
* The website has a whole subdomain devoted to using it with Angular: http://angular-meteor.com/.
* Here's talk given about using React: https://youtu.be/-QtrkXKvQFc. I'm currently doing this with great results.
* Here's one of a few projects providing support for PostgreSQL: https://github.com/meteor-stream/meteor-postgres/wiki/Gettin...
Basically, if there is javascript support for it, you can use it with Meteor.
Secondly, it's disingenuous to say that Isomorphic Javascript is just bad tight coupling by invoking "universally accepted anti-pattern" because someone can come along and spout equally broad and obnoxious engineering-speak, calling it DRY and touting its core principle of code reuse as best practice.
Now, I am genuinely interested in specific shortcomings and outright failures of the technology. If you had a bad experience with DDP, I'd like to hear about it so I don't make the same mistake.
It sounds like you were in an organization where there was some fundamental disagreement that caused the contention.
I don't have any skin in the game, but I find this account to be an unfair characterization of Meteor, so I'd like to refute some of your claims.
First, I really don't know where you got the idea that Meteor is an all-or-nothing stack. Sure, it provides everything you need, but you're not compelled to use what it provides. Meteor works very well with all sorts tech.
* The website has a whole subdomain devoted to using it with Angular: http://angular-meteor.com/.
* Here's talk given about using React: https://youtu.be/-QtrkXKvQFc. I'm currently doing this with great results.
* Here's one of a few projects providing support for PostgreSQL: https://github.com/meteor-stream/meteor-postgres/wiki/Gettin...
Basically, if there is javascript support for it, you can use it with Meteor.
Secondly, it's disingenuous to say that Isomorphic Javascript is just bad tight coupling by invoking "universally accepted anti-pattern" because someone can come along and spout equally broad and obnoxious engineering-speak, calling it DRY and touting its core principle of code reuse as best practice.
Now, I am genuinely interested in specific shortcomings and outright failures of the technology. If you had a bad experience with DDP, I'd like to hear about it so I don't make the same mistake.
If I want to use Angular, I can include a single javascript file and then bootstrap my entire page, or a portion of the page with an application module.
If I want to make an application where one page is an Angular client app and the other is an Ember app, but they're both served by the same server and communicate to the same API you can do that with number of server-side frameworks and architectures... not Meteor though.
Meteor is an all-encompassing server+client package. You'd need to include all your angular application code along with all your ember application code because they share the same meteor server application and meteor is not built to separate clients from servers.
My bad experience and much of my frustration comes from Meteor's hype machine. This person was hyping Meteor as a production ready framework to a startup when it was not... hell it hadn't even reached the arbitrary 1.0 version number yet.
In fact, when Meteor upgraded to 0.9 it force upgraded everyone... i couldn't run `meteor -v` without Meteor saying "Upgrading to v0.9...", which of course would break all the atmosphere packages we were dependent on to have Meteor connect with all the normal functionality that NPM modules would offer.
Meteor evangelists will say "oh, but it wasn't 1.0 and atmosphere isn't a thing, or whatever", because it's always a deflection when it comes to this conversation. The fact that this is a thing that COULD happen is never addressed, the architecture and patterns that led to something like that happening is just ignored.
If I want to make an application where one page is an Angular client app and the other is an Ember app, but they're both served by the same server and communicate to the same API you can do that with number of server-side frameworks and architectures... not Meteor though.
Meteor is an all-encompassing server+client package. You'd need to include all your angular application code along with all your ember application code because they share the same meteor server application and meteor is not built to separate clients from servers.
My bad experience and much of my frustration comes from Meteor's hype machine. This person was hyping Meteor as a production ready framework to a startup when it was not... hell it hadn't even reached the arbitrary 1.0 version number yet.
In fact, when Meteor upgraded to 0.9 it force upgraded everyone... i couldn't run `meteor -v` without Meteor saying "Upgrading to v0.9...", which of course would break all the atmosphere packages we were dependent on to have Meteor connect with all the normal functionality that NPM modules would offer.
Meteor evangelists will say "oh, but it wasn't 1.0 and atmosphere isn't a thing, or whatever", because it's always a deflection when it comes to this conversation. The fact that this is a thing that COULD happen is never addressed, the architecture and patterns that led to something like that happening is just ignored.
Exactly. Coming from a different background (not CS), Meteor is a great place to start. The barriers to entry are really low and specially the risk is also very low: it's javascript ,"late bloomers" can't afford to learn something that might not be directly useful if their bet turn out a loss.
I am all in.
I am all in.
Just because they've raised $20M doesn't mean every single positive comment about Meteor is part of their "PR machine". How do you know people are not genuinely happy with it?
Disclaimer: I'm one of these "wide-eyed open-source evangelists", I guess.
Disclaimer: I'm one of these "wide-eyed open-source evangelists", I guess.
I was under the impression most of the meteor devs work for meteor?
Well-compensated, talented, and trusted in-house developers committed to making the framework the best it can be for all their client's use cases.
Either that or they're a part of their huge open source community which will still work tirelessly to make the framework better, even if Meteor isn't commercial viable and people move on to the next best thing.
I'm sure the truth is based more on who's in the room at the time than anything else.
Either that or they're a part of their huge open source community which will still work tirelessly to make the framework better, even if Meteor isn't commercial viable and people move on to the next best thing.
I'm sure the truth is based more on who's in the room at the time than anything else.
Maybe on SO questions are answered very efficiently. It doesn't mean the documentation is bad.
It means the community is very at it and its a place to go if you have a question and don't want to dive into the docs
Alot of people do prefer personalised answers over the effort of finding it in docs, sad reality.
It means the community is very at it and its a place to go if you have a question and don't want to dive into the docs
Alot of people do prefer personalised answers over the effort of finding it in docs, sad reality.
Someone described this as "high WTF factor".
http://larseidnes.com/2015/01/05/the-wtf-factor-quantifying-...
http://larseidnes.com/2015/01/05/the-wtf-factor-quantifying-...
Personally I see it as positive - it means people are using it and I often find searching SO answers faster than searching docs.
Maybe it works as the opposite. On SO there are ~800,000 questions about Java, Javascript, and C#, each.
That's cool.
Does Meteor actually make, sorry for using such a dirty word, money from something?
Is that still a requirement for start-ups? Now, if they are not going to spend at least half the money on a new fancy office - that would be a major concern for investors.
Hosting.
I couldn't find any pricing information on their website and that's why I asked.
I've heard people using Meteor on Heroku, DO, etc. but I've always wondered why someone would choose Meteor's hosting rather than host Meteor on Heroku (for example) and use a ton of other available plugins.
I've heard people using Meteor on Heroku, DO, etc. but I've always wondered why someone would choose Meteor's hosting rather than host Meteor on Heroku (for example) and use a ton of other available plugins.
Meteor's hosting platform will be optimized for websocket-oriented always-connected applications, with monitoring/auto-scaling features for that sort of app.
Hmm, I didn't know that apps that use websockets needed a different kind of auto-scaling and monitoring.
That's interesting. Thanks!
That's interesting. Thanks!
Yep, that's... interesting. For sure real time web application needs better reactivity when scaling up and down. But you can already achieve this kind of reaction time on existing platforms that uses Docker for example (disclaimer: I'm working on the Scalingo PaaS that already supports MeteorJS app, see https://scalingo.com/meteorjs-hosting).
Meteor's solution will also use containerization: http://info.meteor.com/blog/meteor-and-a-galaxy-of-container...
At the moment Meteor only has free development hosting, they haven't launched their production hosting yet so the pricing hasn't been announced either.
Some investments are multipliers not profit centers.
If you invest in 9 companies that use Meteor then investing in Meteor means you've invested in those 9 companies. It's an investment in infrastructure.
If you invest in 9 companies that use Meteor then investing in Meteor means you've invested in those 9 companies. It's an investment in infrastructure.
> If you invest in 9 companies that use Meteor then investing in Meteor means you've invested in those 9 companies. It's an investment in infrastructure.
Except that I don't think you could find a single a16z, Matrix, or Trinity startup actually using Meteor in production.
Meteor is great for toys and prototypes. But as soon as you start wanting to build an actual organization and team, it's the exact opposite of what you want.
Except that I don't think you could find a single a16z, Matrix, or Trinity startup actually using Meteor in production.
Meteor is great for toys and prototypes. But as soon as you start wanting to build an actual organization and team, it's the exact opposite of what you want.
If you invest in 9 companies that use Meteor then investing in Meteor means you've invested in those 9 companies.
Until they stop using Meteor.
Until they stop using Meteor.
Beginner question: how does Meteor handle storing server-side web socket connections in a scalable way? Are they kept in ram? Redis? Mongo's ram?
The complexity of this is why I always end up reaching for hosted WS solutions like pusher or fanout.io.
The complexity of this is why I always end up reaching for hosted WS solutions like pusher or fanout.io.
Why is this complex? There are so many ways for pub/sub implementations.
However I always ended up using Playframework for WS, since it's really really easy to set this up in a scalable way.
However I always ended up using Playframework for WS, since it's really really easy to set this up in a scalable way.
WS are fundamentally more complex than HTTP since connections are stateful and that state needs to be stored somewhere. It's another dimension that needs to be properly distributed and load balanced to be scalable.
It's not something you need to worry about for small applications, but for a scalable architecture, it's important to know the details of how this works. What happens to Meteor (or Play) with 100k simultaneous connections? How much ram and how many servers will I need? How do I load balance WS data between them? Will another datastore like redis be required? If so, how does it integrate with the framework? What if I outgrow a single instance of that datastore?
If I use pusher, I don't have to think about any of this.
It's not something you need to worry about for small applications, but for a scalable architecture, it's important to know the details of how this works. What happens to Meteor (or Play) with 100k simultaneous connections? How much ram and how many servers will I need? How do I load balance WS data between them? Will another datastore like redis be required? If so, how does it integrate with the framework? What if I outgrow a single instance of that datastore?
If I use pusher, I don't have to think about any of this.
Congratz to a very smart team. Love how Meteor seeks to include other good Javascript frameworks into the platform (like React, Angular), rather than trying to force an artificial "one true way" — looking forward to seeing Galaxy.
Can anybody tell me what is the business model of Meteor? If they are getting investments, the investors has some idea of a ROI and what that could be?
I wouldn't be surprised if someone saw Google's acquisition of Firebase as a sign that they can invest in similar technologies and hope that Apple, Facebook or Yahoo will buy them in response.
It's a terrible model, but hey... Clinkle.
It's a terrible model, but hey... Clinkle.
My best guess...20m is a small amount to invest in your tools. It's a development budget so other companies can utilize the tool for greater leverage. (What they believe to be faster development time with quick iterations and quick MVPs)
They're working on a paid hosting platform called Galaxy that will be designed for quick, easy deployment of Meteor apps. If you work with the framework now, you can deploy to an early version of Galaxy using the command `meteor deploy` (yes, that's it) from your project directory. The goal is to keep that level of simplicity, but offer a platform that's production-grade.
What happens to Meteor if Galaxy fails as a commercial endeavour?
https://github.com/meteor/meteor is open source, so the community will be tasked with maintenance in the case of MDG running out of money.
When Meteor is no longer commercially viable and runs out of venture capital brewed hype-juice everyone will jump to the Next Big Thing and companies that listened to their Meteor evangelist will have to furiously find someone to port from Meteor to ANYTHING so they can continue to build features and support new services.
Bless me with your downvotes Meteor zealots! I'll still be here when Meteor is has gone the way of Flash and ColdFusion.
Bless me with your downvotes Meteor zealots! I'll still be here when Meteor is has gone the way of Flash and ColdFusion.
As mentioned, it's open source and gaining traction. If MDG goes away, I see no reason why meteor could not or would not stand as a viable web framework.
Gaining traction because of the venture capital hype juice I mentioned.
There are lots of open-source and "viable" web frameworks out there.
People want Meteor because it makes a lot of promises regarding productivity, but (as the presence of this article and multiple comments prove) the real interest is in a framework that has money for continued development.
So without the financial backing Meteor is just another open-source web framework. Except if that happens, instead of just replacing it with Angular, Ember, Knockout, etc, you'll also have to replace the entire backend too!
I've already had to do this and while I enjoyed it in some ways and learned a bunch... I really don't think that my company enjoyed paying me to rebuild a platform that they already paid for because the Meteor evangelist they hired before me decided they wanted to be an overpaid consultant instead.
There are lots of open-source and "viable" web frameworks out there.
People want Meteor because it makes a lot of promises regarding productivity, but (as the presence of this article and multiple comments prove) the real interest is in a framework that has money for continued development.
So without the financial backing Meteor is just another open-source web framework. Except if that happens, instead of just replacing it with Angular, Ember, Knockout, etc, you'll also have to replace the entire backend too!
I've already had to do this and while I enjoyed it in some ways and learned a bunch... I really don't think that my company enjoyed paying me to rebuild a platform that they already paid for because the Meteor evangelist they hired before me decided they wanted to be an overpaid consultant instead.
> People want Meteor because it makes a lot of promises regarding productivity, but (as the presence of this article and multiple comments prove) the real interest is in a framework that has money for continued development.
I can't speak for others, but the reason I find meteor interesting is because it's one of the only frameworks to address isomorphic javascript, and because it has some really interesting realtime features out of the box. The fact that it's backed by a team that has some venture funding (and therefore some runway to continue improving it) is a definite plus.
> So without the financial backing Meteor is just another open-source web framework.
I don't understand this point. Even _with_ the funding meteor is just another open source framework. Isn't it great that we have a number of open source framework options to suit different needs?
> I really don't think that my company enjoyed paying me to rebuild a platform that they already paid for because the Meteor evangelist they hired before me decided they wanted to be an overpaid consultant instead.
You haven't really explained _why_ you needed to rebuild it. Perhaps meteor didn't suit the use case for this project or perhaps you felt more comfortable/productive in another framework. You haven't really made a case against meteor or a convincing argument about why adopters would need to switch to another framework if MDG failed as a commercial business.
I can't speak for others, but the reason I find meteor interesting is because it's one of the only frameworks to address isomorphic javascript, and because it has some really interesting realtime features out of the box. The fact that it's backed by a team that has some venture funding (and therefore some runway to continue improving it) is a definite plus.
> So without the financial backing Meteor is just another open-source web framework.
I don't understand this point. Even _with_ the funding meteor is just another open source framework. Isn't it great that we have a number of open source framework options to suit different needs?
> I really don't think that my company enjoyed paying me to rebuild a platform that they already paid for because the Meteor evangelist they hired before me decided they wanted to be an overpaid consultant instead.
You haven't really explained _why_ you needed to rebuild it. Perhaps meteor didn't suit the use case for this project or perhaps you felt more comfortable/productive in another framework. You haven't really made a case against meteor or a convincing argument about why adopters would need to switch to another framework if MDG failed as a commercial business.
What about "isomorphic javascript" needs to be addressed? That was a term that almost seems invented as a problem for Meteor to solve. The fact that code in completely different environments (browser vs server) needs to look different is not something that needs to be addressed.
A) With financial backing Meteor is an open-source framework which MUST provide an ROI for those backers.
B) Read the comments, the reason Meteor is more hyped is because it is funded. The reason people use to justify the enormous investment in building a production app with Meteor is based on it being funded. Take away the funding and you take away a compelling reason to use it... so if that reason is removed after you have already invested, you have lost on your investment.
Meteor was not the right tool for the job, but good luck trying to have that conversation with a Meteor evangelist. Just like any other evangelist they're pragmatic when it suits their argument and dogmatic whenever it doesn't.
In closing, I'm not against Meteor as a tool. I love tools and I love a lot of the concepts in Meteor (not isomorphism, that is a fools errand).
What I don't love are people/companies that misrepresent themselves and put more money into sounding good than they do into actual being good.
My experience using Meteor was resoundingly negative and yet negative experiences are shouted down while positive ones are lauded. The "maybe it didn't suit your use case" only comes up when I show I'm willing to stick to my guns and articulate myself.
Want to convince me Meteor is really dedicated to being a great and lasting web framework and not just a cash grab? Why don't you put an article to the front page of HN describing the use cases that Meteor ISN'T good for?
You admit they exist, so why not, right? They could learn a ton about their product while being brutally honest about its limitations with the community they want to win over.
Of course, it'll never happen, because Meteor isn't really a community project to build the next best framework. It's an investment vehicle and no investor would ever willingly let doubt be shined on their investment vehicle.
A) With financial backing Meteor is an open-source framework which MUST provide an ROI for those backers.
B) Read the comments, the reason Meteor is more hyped is because it is funded. The reason people use to justify the enormous investment in building a production app with Meteor is based on it being funded. Take away the funding and you take away a compelling reason to use it... so if that reason is removed after you have already invested, you have lost on your investment.
Meteor was not the right tool for the job, but good luck trying to have that conversation with a Meteor evangelist. Just like any other evangelist they're pragmatic when it suits their argument and dogmatic whenever it doesn't.
In closing, I'm not against Meteor as a tool. I love tools and I love a lot of the concepts in Meteor (not isomorphism, that is a fools errand).
What I don't love are people/companies that misrepresent themselves and put more money into sounding good than they do into actual being good.
My experience using Meteor was resoundingly negative and yet negative experiences are shouted down while positive ones are lauded. The "maybe it didn't suit your use case" only comes up when I show I'm willing to stick to my guns and articulate myself.
Want to convince me Meteor is really dedicated to being a great and lasting web framework and not just a cash grab? Why don't you put an article to the front page of HN describing the use cases that Meteor ISN'T good for?
You admit they exist, so why not, right? They could learn a ton about their product while being brutally honest about its limitations with the community they want to win over.
Of course, it'll never happen, because Meteor isn't really a community project to build the next best framework. It's an investment vehicle and no investor would ever willingly let doubt be shined on their investment vehicle.
But not all of us are using Meteor for work. I just started using Meteor for a fun side project last week (after first banging my head against the still-a-work-in-progress ember-cli and ember-data), and I am having a grand time of it. It's amazingly intuitive, and I'm making great progress, mostly because they already handled so much of the grunt work already.
Oh, so that's why they have been trying to sell it here on HN.
A few of us have been happily hacking away on SocketStream (https://socketstream.com/) for quite sometime. It's a smaller, piecemeal framework that borrows more from the community of Node pluggable/playable modules.
With this 20M, Meteor just became a heavy-weight—
That said, I still like the idea of a more community-drive approach.
With this 20M, Meteor just became a heavy-weight—
That said, I still like the idea of a more community-drive approach.
Also, shameless plug, but we've been keen to sponsorship and/or other contributors to get a little more momentum in the SS community. Ping me over here if interested so I don't completely derail this thread. ;) http://robertlangfordhall.com/contact/
Is anyone hiring Meteor developers? In the Bay Area?
Yep, Edthena is! You can see our profile and job description here:
http://careers.stackoverflow.com/company/edthena
If interested, you can apply through the site or just email me: dave at edthena dot com
http://careers.stackoverflow.com/company/edthena
If interested, you can apply through the site or just email me: dave at edthena dot com
Hedgy.co is looking for awesome people and we happen to be using meteor for our FE development.
Feel free to reach out to me directly at kevin at hedgy dot co
Feel free to reach out to me directly at kevin at hedgy dot co
I'm the CEO of a stealth mode startup in SF that is using Meteor in a B2B CRM application. We are looking for Meteor developers and you can reach me at jim at clozertech dot com.
Serious question: does Meteor scale well in these days?
Just published a post related to this topic. Short answer: Yes. - http://blog.differential.com/scaling-meteor-to-20000-users-i...
Awesome job and congrats on the massive traction on launch day. Thanks for sharing!
[deleted]
What I don't understand with Meteor is how you can build secure applications if you actually write your database queries in the front-end. Can someone enlighten me? How do you hide logic or prevent people from manipulating however they want?
Database modifications on the client are usually disabled in Meteor. There are two ways to control database access in Meteor:
1. You can write allow/deny permissions rules to allow only certain modifications: http://docs.meteor.com/#/basic/Mongo-Collection-allow
2. You can not use client-side modifications at all and instead write all of your database code inside Methods, which are basically supercharged RPCs that give you automatic optimistic UI updates: https://www.meteor.com/try/10
I think this issue comes up a lot because new Meteor apps come with the "insecure" package by default to enable faster initial development and debugging, but most or all production apps will remove this package.
(I work at Meteor)
1. You can write allow/deny permissions rules to allow only certain modifications: http://docs.meteor.com/#/basic/Mongo-Collection-allow
2. You can not use client-side modifications at all and instead write all of your database code inside Methods, which are basically supercharged RPCs that give you automatic optimistic UI updates: https://www.meteor.com/try/10
I think this issue comes up a lot because new Meteor apps come with the "insecure" package by default to enable faster initial development and debugging, but most or all production apps will remove this package.
(I work at Meteor)
My worry is that with JavaScript-based stacks evolving so fast these days, monied interest in one way of doing things would ultimately be incentivized to suppress better ways of doing things, as they emerge.
[deleted]
[deleted]
For those who're looking for a full stack framework, I can't recommend GWT enough. GWT lets you write java for both client & server, and then compiles the client code to javascript. This compiled js is highly optimized and your css / images / html templates are bundled together to minimize HTTP requests. On the server side, this lets you use java which is a lot more performant than javascript is.
> On the server side, this lets you use java which is a lot more performant than javascript is.
Is it? http://benchmarksgame.alioth.debian.org/u64/javascript.html
Is it? http://benchmarksgame.alioth.debian.org/u64/javascript.html
Yep: https://www.techempower.com/benchmarks/
Its also fairly obvious that a statically typed / compiled language will have better performance than an interpreted language. Compiler optimizations make a huge difference as well.
Also, even the link you gave shows js being slightly faster in 2 or 3 benchmarks, but for the remaining 4-5, java is significantly faster.
Its also fairly obvious that a statically typed / compiled language will have better performance than an interpreted language. Compiler optimizations make a huge difference as well.
Also, even the link you gave shows js being slightly faster in 2 or 3 benchmarks, but for the remaining 4-5, java is significantly faster.
Woot, congrats folks!
Out of curiosity, did ever rails raise any money?
It's amazing how many developers willingly giving up their entire tech stack in exchange for a proprietary one.
If it was MSFT trying to pull this off, would the reaction on HN be as positive?
If it was MSFT trying to pull this off, would the reaction on HN be as positive?
Maybe I am getting lost in your comment but, are you trying to suggest that Meteor is a proprietary stack?
sigh
At least judging by www.meteor.com, they are still insisting their users accept the risks[1] of javascript and sending an empty body tag.
[1] If you think these risks don't exist, you haven't been paying attention. I don't care if you want to run exploit code from an ad or be used as ammunition by the Great Cannon; just don't insist that others must accept that risk if they want to read your page (slower loads or reduced functionality with the javascript is perfectly fine).
edit:
So you all value convenience over safety. really, it's probably because you're so used to spying on people that the idea of losing that ability is a thought you cannot abide. After all, why would the idea of losing javascript be attacked so strongly? This gets downvotes faster than anything else. What a lot of website developers don't seem to understand is that recording hover times, click paths, reading times and the like may be "metrics" or "important business data" to you, to normal people that is "creepy peeping-tom" behavior.
I know, you're thinking that this is off topic, or that it's just a tool. No, you're making a political/sociological decision by forcing people to take the risk of javascirpt - and business recording information about people is risk #1.
The non-technical people I know, after slowly learning about how the tech industry really works, have been doing a lot to reduce their internet use. A few have turned luddite. Others are trying to reduce their dependence on network services. That is the end game of people finding out the real price of using some webapp - you're driving people away from the entire concept.
Of course, I'm wasting my breath - clearly the features of some tool are more important than the reality of the future you're creating.
Either that, or djb is right. ( http://cr.yp.to/talks/2015.05.08/slides-djb-20150508-a4.pdf )
At least judging by www.meteor.com, they are still insisting their users accept the risks[1] of javascript and sending an empty body tag.
[1] If you think these risks don't exist, you haven't been paying attention. I don't care if you want to run exploit code from an ad or be used as ammunition by the Great Cannon; just don't insist that others must accept that risk if they want to read your page (slower loads or reduced functionality with the javascript is perfectly fine).
edit:
So you all value convenience over safety. really, it's probably because you're so used to spying on people that the idea of losing that ability is a thought you cannot abide. After all, why would the idea of losing javascript be attacked so strongly? This gets downvotes faster than anything else. What a lot of website developers don't seem to understand is that recording hover times, click paths, reading times and the like may be "metrics" or "important business data" to you, to normal people that is "creepy peeping-tom" behavior.
I know, you're thinking that this is off topic, or that it's just a tool. No, you're making a political/sociological decision by forcing people to take the risk of javascirpt - and business recording information about people is risk #1.
The non-technical people I know, after slowly learning about how the tech industry really works, have been doing a lot to reduce their internet use. A few have turned luddite. Others are trying to reduce their dependence on network services. That is the end game of people finding out the real price of using some webapp - you're driving people away from the entire concept.
Of course, I'm wasting my breath - clearly the features of some tool are more important than the reality of the future you're creating.
Either that, or djb is right. ( http://cr.yp.to/talks/2015.05.08/slides-djb-20150508-a4.pdf )
Most sites use javascript anyway. How is this different? If people want to use Meteor to solve their business problem (even internally) how does the negligibly low chance of a great canon infecting a site make this different.
There's also a couple of libraries that implement server-side rendering if the blank page is something that disturbs you.
Ps the loads are faster due to caching & are highly CDNable as they don't change at all. Mostly static.
For the great canon issue: it's not difficult to check against a hash on the script either right? Besides not exlusively being a Meteor problem.
There's also a couple of libraries that implement server-side rendering if the blank page is something that disturbs you.
Ps the loads are faster due to caching & are highly CDNable as they don't change at all. Mostly static.
For the great canon issue: it's not difficult to check against a hash on the script either right? Besides not exlusively being a Meteor problem.
The one thing that made me drop it as the choice for a primary stack was the fact that it's tied so heavily into MongoDB. Meteor has a mongodb 'server' replicated client side, that's how they can actually make Meteor so god damn snappy, it's latancy compensation.
If they were to integrate something like Postgresql into Meteor, I would easily switch over from Rails and it would become my de-facto web stack.
I'll just keep building Rails APIs with EmberJS clients until then, I do hope it's soon though. I loved working with Meteor.