Earlier quoted context omitted.
Still waiting for the killer testimonial for meteor, until then I'd be too scared to try it with anything larger than a prototype or brochure site. I don't want to be the first person attacking a completely new class of scaling problems using a proprietary tech stack that I may or may not have the ability to control.
What do you mean by "proprietary"?
Announcing Meteor 1.2 – ES2015, Angular, React, and More
121–130 of 140 posts
Re: Announcing Meteor 1.2 – ES2015, Angular, React, and More
#122Earlier quoted context omitted.
What do you mean by "proprietary"?
Proprietary is the wrong word, as it is open source. The right word would be "immature", as meteor is an entire tech stack that hasn't been battle hardened by years or decades of other software that currently exists in other tech stacks. The other piece is the meteor stack is designed to be hosted by meteor. Sure, you can, in theory, run everything yourself - but I haven't seen good case studies of that. What do you…
I use Digital Ocean with MUP and it works great with minimal efforts.
Re: Announcing Meteor 1.2 – ES2015, Angular, React, and More
#123Earlier quoted context omitted.
It's coming! MDG is focusing 100% on their Heroku-like platform called Galaxy and once that's done they may push on to relational database support.
Graph DBs support is ok too :)
Re: Announcing Meteor 1.2 – ES2015, Angular, React, and More
#124Earlier quoted context omitted.
What do you mean by "proprietary"?
Proprietary is the wrong word, as it is open source. The right word would be "immature", as meteor is an entire tech stack that hasn't been battle hardened by years or decades of other software that currently exists in other tech stacks. The other piece is the meteor stack is designed to be hosted by meteor. Sure, you can, in theory, run everything yourself - but I haven't seen good case studies of that. What do you…
As the lead developer of Sandstorm.io, I have deployed Meteor:
* As the Sandstorm front-end, where Sandstorm is designed to be installed by end users on their own machines.
* As apps that run on Sandstorm, and are designed to be extremely fine-grained (each app instance handling a tiny amount of data, e.g. a single document).
* As oasis.sandstorm.io, a highly-scalable centralized Sandstorm host.
* As apps.sandstorm.io, a fairly mundane use case (whereas Sandstorm is, comparatively, highly unusual).
I would argue that Meteor is not at all designed for Meteor hosting. Rather, Meteor is designed such that anyone wanting to build a PaaS around it will have a much easier time doing so than they will with just about any other environment. On Sandstorm, we find Meteor apps much easier to package than anything else, because the Meteor tools will output a self-contained app bundle that operates in a consistent fashion for all apps -- thus allowing us to write a common packaging tool that works with all Meteor apps. Other stacks are comparatively much more fiddly.
I would expect Meteor's hosting will turn out to be the best way to run Meteor apps primarily because they have kick-ass engineers there who will build an awesome product (disclosure: I know several of them), not because they've biased the framework in their favor.
Re: Announcing Meteor 1.2 – ES2015, Angular, React, and More
#125Can't wait to start learning this language. Are there any great resources like how the Laravel community has Laracasts, but for Meteor?
Re: Announcing Meteor 1.2 – ES2015, Angular, React, and More
#126Earlier quoted context omitted.
That's not data management. That's schema management (migration). And yes, you have to script a change to every document.
Right. And I see. Are these managed by something like migrations?
Re: Announcing Meteor 1.2 – ES2015, Angular, React, and More
#127One of the things still holding me back from using Meteor with React is the lack of support for a module loading system. It seems like if I want to define a component in a separate file, I'll have to assign it to a global variable if I'm going to compose it in another file.
Using global variables isn’t even the worst part. The big problem with this sharing model is that files are loaded in the alphabetical order, thus the only way to control that file a requires file b as a dependency is to give to b a file name that is before a in the alphabet (this is not true for Meteor packages where we can control the file order). Thankfully MDG plan to address this issue soon.
Re: Announcing Meteor 1.2 – ES2015, Angular, React, and More
#128Re: Announcing Meteor 1.2 – ES2015, Angular, React, and More
#129Earlier quoted context omitted.
Proprietary is the wrong word, as it is open source. The right word would be "immature", as meteor is an entire tech stack that hasn't been battle hardened by years or decades of other software that currently exists in other tech stacks. The other piece is the meteor stack is designed to be hosted by meteor. Sure, you can, in theory, run everything yourself - but I haven't seen good case studies of that. What do you…
You can easily use things like Heroku and Modulus to host your site. I think perhaps you are misinformed about your options and should read up a bit more. I use Digital Ocean with MUP and it works great with minimal efforts.
What kind of load does that app you host on digital ocean have?
Edit: I'm not at all suggesting that isn't possible to self host a meteor app, I am saying that I don't know what the "beaten path" is for other companies/apps/products that have self hosted a meteor app to a significant scale.
Re: Announcing Meteor 1.2 – ES2015, Angular, React, and More
#130Earlier quoted context omitted.
Proprietary is the wrong word, as it is open source. The right word would be "immature", as meteor is an entire tech stack that hasn't been battle hardened by years or decades of other software that currently exists in other tech stacks. The other piece is the meteor stack is designed to be hosted by meteor. Sure, you can, in theory, run everything yourself - but I haven't seen good case studies of that. What do you…
So... as it happens I have a lot of experience deploying Meteor apps to servers that don't belong to Meteor. In fact, I may have a greater variety of such experience than anyone. As the lead developer of Sandstorm.io, I have deployed Meteor: * As the Sandstorm front-end, where Sandstorm is designed to be installed by end users on their own machines. * As apps that run on Sandstorm, and are designed to be extremely fi…
What does that mean exactly? I admit, I only kind of know what sandstorm does from it's marketing page (looks like it offers VM's in a more user friendly way with an emphasis on security)
In what way does Meteor allow you to produce quicker or more efficiently than if you went with any standard linux stack?