I looked into Meteor and it's amazing how everything clicks together. It's just such a drastic change in complexity and feels like a breath of fresh air.<p>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.<p>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.<p>I'll just keep building Rails APIs with EmberJS clients until then, I do hope it's soon though. I loved working with Meteor.
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.<p>Official React or Angular support isn't a game-changer. They can already be integrated easily with the reactive data providers.
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.<p>Either way, best of luck to them!
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.<p>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.<p>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?<p>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.<p>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?
Has anyone seen DDP used outside of Meteor? <a href="https://github.com/meteor/meteor/blob/devel/packages/ddp/DDP.md" rel="nofollow">https://github.com/meteor/meteor/blob/devel/packages/ddp/DDP...</a>
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.
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.<p>I've also used angular, which I also like, but has a little bit more of a learning curve drawback.<p>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...<p>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 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.<p>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.
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?<p>The complexity of this is why I always end up reaching for hosted WS solutions like pusher or fanout.io.
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?
A few of us have been happily hacking away on SocketStream (<a href="https://socketstream.com/" rel="nofollow">https://socketstream.com/</a>) for quite sometime. It's a smaller, piecemeal framework that borrows more from the community of Node pluggable/playable modules.<p>With this 20M, Meteor just became a heavy-weight—<p>That said, I still like the idea of a more community-drive approach.
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?
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.
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.
It's amazing how many developers willingly giving up their entire tech stack in exchange for a proprietary one.<p>If it was MSFT trying to pull this off, would the reaction on HN be as positive?
<i>sigh</i><p>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.<p>[1] If you think these risks don't exist, you haven't been paying attention. I don't care if <i>you</i> 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).<p>edit:<p>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.<p>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.<p>The non-technical people I know, after slowly learning about how the tech industry really works, have been doing a lot to <i>reduce</i> 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.<p>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.<p>Either that, or djb is right. ( <a href="http://cr.yp.to/talks/2015.05.08/slides-djb-20150508-a4.pdf" rel="nofollow">http://cr.yp.to/talks/2015.05.08/slides-djb-20150508-a4.pdf</a> )