The State of Meteor Part 1: What Went Wrong

The big mistake was trying to provide anything beyond Minimongo on the client side. People are very picky about what front-end frameworks they use on the front end, and typically people who have strong opinions about that are less opinionated about what they use on the back end. I&#x27;m firmly in that camp, for instance. I&#x27;ve been a huge fan of Firebase for a while because it frees me from the tedium of having to create another REST application just to talk to a database. If Meteor had, from the beginning, focused on simply being a kick-ass open-source alternative to Firebase they would be killing it right now.<p>It was a monumental task to try to create something that would please both front-end and back-end web engineers. Another issue with Meteor is that it was envisioned, not extracted. [1] From Rail&#x27;s creator, DHH: &quot;First, Rails is not my job. I don&#x27;t want it to be my job. The best frameworks are in my opinion extracted, not envisioned. And the best way to extract is first to actually do.&quot;<p>Meteor was the goal, not an actual, real-world application. Often when this is the case the software ends up solving a bunch of problems that seem logical to solve, but in practice are not actually practical (another framework like this that comes to mind is the notorious famo.us project). Compare this to Rails and React which were forged in the crucible of real, day-to-day development and problem solving.<p>[1] - <a href="http:&#x2F;&#x2F;david.heinemeierhansson.com&#x2F;posts&#x2F;6-why-theres-no-rails-inc" rel="nofollow">http:&#x2F;&#x2F;david.heinemeierhansson.com&#x2F;posts&#x2F;6-why-theres-no-rai...</a>

The startup I&#x27;m with right now just finished a meteor&#x2F;react project that I led. This article really touched on our major pain-point with the learning cliff that you hit after a certain point. We used FlowRouter since it has React support, but managing subscriptions correctly (let alone caching them) took <i>way</i> more time than we had anticipated. It wasn&#x27;t until near the end of the project that we realized none of us actually had a total mastery of what was going on under the hood in meteor, which was a terrifying realization. All things considered, though, I think our biggest mistake was biting off more than we could chew in using React and Meteor, when we had never made an app using either before. On the other hand, blaze is pretty rough...

This article does a disservice to Meteor. The article feels drama filled and says many things are broken when they are not.<p>&quot;Blaze is threatened by React&quot;. You can use React or you can use Blaze. If React becomes so popular that Blaze is not longer used, that&#x27;s OK... nothing to be threatened about. It&#x27;s nice that Meteor can move with a trend.<p>&quot;Tracker and Minimongo might eventually disappear as well&quot;. Tracker and Minimongo aren&#x27;t giant stick bugs near Australia that need to be preserved. It&#x27;s ok if they are replaced. They are internal tools for Meteor provide its &quot;reactivity&quot;. I doubt reactivity is going away.<p>Other non-scary things: Routing is solved by community packages. Pagination, forms... really? Server-side rendering has the &quot;spiderable&quot; package, but the SEO &#x2F; server-side rendering problem isn&#x27;t unique to Meteor.<p>The database issue is valid. Meteor uses MongoDB. But, you shouldn&#x27;t go down the Meteor road and try to shoe-horn a relational DB into non-relational DB, then say WTF. You knew from the beginning that non-relational DBs have their own set of problems. My limited understanding is that MongoDB was picked because it was the easiest way to get the reactivity that the MDG was looking for. Meteor road maps says SQL support is on its way.<p>I don&#x27;t know where the OP is going with this. Maybe this is the part 1 of the late night TV commercial where they list all of our problems (think Slap Chop), then in Part 2 he&#x27;ll solve all of our Meteor problems if we buy the next book he writes.

I&#x27;m currently using Meteor to teach a college-level course on Web Development for beginners.<p><a href="https:&#x2F;&#x2F;csci16.hellometeor.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;csci16.hellometeor.com&#x2F;</a><p>It&#x27;s incredible how accessible Meteor is for this purpose:<p>* One line complete local setup<p>* One line deployment (to Meteor servers, but still)<p>* Javascript only (no need to learn Python, Ruby, etc in addition)<p>* Out of the box User Accounts<p>* Simple templating engine with Blaze<p>I can think of no other framework&#x2F;language combo where true beginners can deploy a live, database-driven website in a couple of hours. I really wish Meteor could focus more on this aspect: becoming THE entry-level framework for learning web development.<p>However Meteor&#x27;s business model is around hosting, so it&#x27;s inevitable they move further and further towards the needs of professional, rather than entry-level, developers. And this takes them further into the areas outlined in this article where they are currently weak.

The thing which prevented me to use meteor for big projects is it looks really monolithic from the outside.<p>What happens if suddenly I want to rewrite part of the back-end or part of the front-end with something else for various reasons ? What happens if I want to switch from MongoDb to RethinkDb or Postgres for some reason ? It&#x27;s good to have default choices but it looks from the outside that the default choices with meteor are pretty fixed.<p>But maybe I&#x27;m wrong, that&#x27;s just how it looks like from the outside.

&gt; Meteor has yet to establish itself as a mainstream development technology on the same level as Rails or even vanilla Node.js... almost four years after Meteor first launched, I have to admit I thought the framework would be more widespread by now. So what happened?<p>A more general answer, I feel like the web programming world doesn&#x27;t really need new frameworks, does it? Rails or Django got mainstream adoption because there was a need at the time, likewise with frontend JS frameworks (which seems to be consolidating around just 2 - React and Angular), and likewise with Node as filling a need for easy async. I&#x27;m not that knowledgeable on Meteor [1], however I think by default it&#x27;s reasonable to expect no new frameworks to have mainstream adoption without a major change to the web.<p>[1] I don&#x27;t know if Meteor&#x27;s x-platform appeal is enough to convert users from other x-platform, native and&#x2F;or hybrid solutions (Ionic, Titanium, RubyMotion, etc.).

Personally, the one thing I don&#x27;t like about Meteor is that it insist on using MongoDb. That along makes me NOT want to use it, despite other cool features.

I was never able to get on board with Meteor because of the Mongo dependency. Not to get too far off topic, but Mongo is guaranteed to lose data under certain well-defined conditions.<p>I completely fail to understand why some developers seem to be allergic to learning about data structures and the means of query-ing them. It&#x27;s not really that hard. If you can JS, you can SQL.

&gt; Once a new Meteor user starts to go beyond the basics and look into things like routing, pagination, subscription caching &amp; management, server-side rendering, or database joins, they realize that the difficulty curve quickly ramps up.<p>Routing? Really? I am not an expert but I think if routing, of all things, is hard in to do in your web framework, you most likely have a problem. That&#x27;s requirement zero!

Give me a box of boards and nails any day. All my ikea furniture is rickety and much of it is starting to look dated.<p>I just spent a good amount of time over the last few months building a prototype for an application in Meteor and it has been a joy.<p>Out of the box I got happy, grokable app&#x2F;server communication, I got sane user account tools and I got a build process that works well enough that I haven&#x27;t thought about it at all. I almost never need to look at documentation, I just build features. I&#x27;ve only needed a few community packages, and the ones I have used have been working pretty well for me.<p>I feel like I&#x27;ve been living the dream. So much ceremony and overhead just melted away.<p>I&#x27;d be curious to hear what kind of issues people have hit with blaze&#x2F;meteor package management&#x2F;etc that make them want to swap in react&#x2F;npm&#x2F;etc. (I spent the better part of 2015 with react&#x2F;flux and it would take a lot to get me to switch back).

I like Meteor and am using it for my current project, but I architected it in a way to stay away from their pub&#x2F;sub model where you publish partial data sets to the client. I believe this only has utility where you have a feed of data that you want to filter or sort on a lot of different attributes.<p>Instead, I just utilize `Meteor.Methods` for all client&#x2F;server interaction. I actually think it&#x27;s pretty nice because you define the method on the client as a &quot;stub&quot; that gets called as it waits on the server response. I think the tutorials and guides focus too heavily on their fancy client&#x2F;server mongo magic.<p>Though something that is a bit frustrating reading this is that I left React. I found it overly-complicated for my product and preferred architecting everything in terms of templates. Blaze is threatened by React? How? I like React, but I can&#x27;t exactly get behind writing HTML components in javascript because whoa man, a diff engine &amp; &quot;look ma! I&#x27;m being functional!&quot; I realize the benefits of uni-directional flow, but all it really did was add a lot more conceptual weight to a pretty simple interface.<p>So I said, this is pointless let&#x27;s just simplify things with Meteor + Blaze. Now Meteor says, it&#x27;s &quot;threatened&quot; by React?

Meteor has been perfect for the single page web apps I&#x27;ve been making as side projects. I don&#x27;t know any other frameworks where I could have completed an encrypted chat application as fast and painless as I did with meteor.<p>All the things mentioned as &quot;going beyond basics&quot; seem like things that meteor was never designed for and that we have other tools to handle.<p>I really feel like the problem is with the people behind meteor trying to make it THE framework, instead of just being a framework that excels at a single purpose.

I loved meteor. Was committed to it for 6&#x2F;7 months while still learning JS (and working on ember and rails projects with others). I knew it was a risky decision, but it seemed like a good choice for making it as a one-man dev agency. For me, there&#x27;s no stack selection problem, for me, the main problem is the co$t of launching a working demo-app or a prototype. The only thing i wanted was a simpler&#x2F;cheaper way of deploying apps. I knew there was something coming, since the beginning i heard about galaxy, an MDG developed deploying solution, which i thought was the solution for all my problems. But then, then came the galaxy launch and its price ($495&#x2F;mo). At that price I felt betrayed, misrepresented. (still waiting for the individual price several months after)<p>The big problem i see with meteor for the future, is that MDG has&#x2F;will have to answer to its shareholders rather than its community.

As long as there is no direct PostgreSQL support, Meteor is no viable option anyways.

There does not seem a day to go by without a NodeJS-based framework&#x2F;library get the heat from the community ever since December 2015.<p>It appears that 2016 is the year when the hype from NodeJS died down and vendors&#x2F;OSS-community must now deal with the hard, un-glamorous, work to clean up, maintain, prepare roadmap, and so on. Which is good!<p>Or it could also be the year where people realized that the use-case for NodeJS is fairly very very specific&#x2F;niche (unless if they love JS so much that they&#x27;re willing to absorb the pain using NodeJS + its ecosystem).<p>SailJS vs TrailJS, ExpressJS is dying, NodeJS vs io.js, StrongLoop+IBM fiasco (and SL reputation), now MeteorJS!. I had high hopes that MeteorJS can be one of the premier NodeJS frameworks (Rod Johnson, who created Spring Framework, invested in the company. I hope they listen to him...).<p>I love to see competition in NodeJS ecosystem and hopefully sooner than later, a few solid options emerged because right now, everything is not a good option except barebone NodeJS and roll-your-own-framework.

Anything that implies the lock-up unless everything is rewritten completely is not a viable choice for me.<p>I&#x27;m wary of anything (especially JavaScript as trends change there faster than one can read the articles) no matter how praised it is. Sometimes things just do break in the most bizarre manner when you already have everything set up. If components are modular enough, you can swap them, or at least patch a completely new piece over the old one, to handle the problematic cases.<p>When I once had to replace a very old legacy system (non-web, but it still holds) I&#x27;ve just slapped a dummy do-nothing proxy-like system in the front and gradually did stuff piece-by-piece. Then threw out the old garbage when it wasn&#x27;t doing anything anymore.<p>But from what little I understood about Meteor from the tutorials and examples, there&#x27;s one single giant system, that you either use or don&#x27;t. This means, if one hits some bug or - worse - architectural limitation, they&#x27;re going to have really tough time.

When I saw MongoDB, Meteor got put on a &quot;check back some day&quot; list. Phoenix is way more interesting: it&#x27;s built on some very solid foundations.

The challenges discussed by the OP apply to <i>any</i> large-scale complex project and are not limited to developing in Meteor. True, some are specific to Meteor (besides the challenges that go with all NoSQL architectures), as is the case with any tech stack. IMO it’s quite unfair to obsess about the cons only (especially if they are the kind of “problems” <i>you</i> can’t tackle), and to take the pros for granted.<p>Routing in Meteor, for one, is trivial (esp. with Flow Router). Subscription management and caching are solvable problems too (esp. if you refrain from doing subscriptions during routing, but instead declare your dependencies where you are really are dependent on your data: in the UI components).<p>What’s the problem with using NPM packages inside Meteor, exactly? The fact that you must write a single additional line in a package? Well, if you’re not used to organize your code in re-usable Meteor packages, then, I guess, it’s more <i>your</i> problem, than it is a problem with Meteor.<p>Meteor does not scale well? How is that? Any Meteor app can scale, as can every application that has been set up with a well engineered architecture: implement you logic in micro-services and your Meteor app will scale smoothly, horizontally, until your <i>database</i> (and not your app layer, that is!) becomes the bottleneck.<p>Most of the comments here, seem to emanate from me the degree of freedom that comes with Meteor (platform vs. framework). If you can’t architect, then, obviously, Meteor won’t save your day and do your engineering for you.<p>I put up some slides with Meteor best-practices for building large-scale apps: <a href="http:&#x2F;&#x2F;meteor.redandivory.com&#x2F;" rel="nofollow">http:&#x2F;&#x2F;meteor.redandivory.com&#x2F;</a> The presentation is almost two years old, but most of the guidelines still hold.<p>tl;dr — It’s not the framework’s job to do your architecting. Don’t blame the tool if you don’t read the manual.

I built an app with Meteor right around when 1.0 was released. The absolute worst part for me was attempting to shim what should have been a relational database design into the default NOSQL mongoDb (you pretty much had no choice).

I tried out Meteor this past spring. I started with a simple Trello clone, which I got working in a couple hours, including learning time. It was good enough at that point that my brother started using it at work. I was pretty impressed.<p>So I got to work on some more advanced features I&#x27;d been thinking about. And at some point, Meteor started throwing an error from somewhere in its innards, and for the life of me I couldn&#x27;t figure it out. Some kind of problem mapping data to UI, I don&#x27;t remember the exact message.<p>I decided I needed to know the guts of Meteor to be able to debug problems like this, and put the whole project aside to wait for the <i>Meteor in Action</i> book. But now I&#x27;m onto other things.

Seems like a good analysis of Meteor&#x27;s shortcomings.<p>I did some research on related areas a few months ago. My ideal stack at the moment would involve:<p>* redux or cerebral with immutable model<p>* react<p>* css modules<p>* webpack<p>* a realtime-enabled version of falcor, which doesn&#x27;t exist yet.<p>The last bit is still the missing piece for realtime, as far as i&#x27;m aware. Neither GraphQL not Falcor seem to been designed with realtime model updates (via websocket) in mind.

Honestly, I used meteor and tried pretty hard, I went to their hackathons, etc...<p>I just don&#x27;t think it&#x27;s as good as the other options technically (does not scale well as a server, which is a problem for most applications).<p>More importantly, as a developer, I do not believe VC money should be bringing opinions to the open source community (which is what this is) is a bad idea. The whole point of open source projects is to have natural selection happen. Meteor having VC money allows them to get it wrong but still market it etc... Which just seems like a poor idea.

I did a little project with meteor in its early (pre 0.5) days. At some point internal errors I could not understand started cropping up. Nobody in the community at the time could help. In the end I wrote the app in go and angular. The idea of meteor seemed nice at the time but in practice it wasn&#x27;t fun. The all in approach means you should also understand what goes on under the hood because when the engine fails and nobody knows why, you are stuck.

This article is really great. Yes, Meteor is still one of my favorite platforms, but every library &#x2F; framework &#x2F; platform always comes with its pain points. I have had a great experience with it so far and I have to admit, I did get to a point recently where I was having trouble recommending it to other people and companies due to the various points stated in the post.<p>But, having said that, there is still a very bright future ahead for Meteor. The people at Meteor Development Group have identified these pain points and have plans to improve some of it. There are various tasks that they are working on now that will change Meteor a bit, but also make it a better platform (in my opinion). Things such as better NPM &#x2F; module support, support for multiple different types of databases, faster build times, better testing support, etc.<p>The platform has been around for awhile and I still think that it can reach the goal of being the go-to JS platform for building cross-platform applications.

The major benefit of Meteor (at least for me) always was its quick bootstrap. So you want start coding or work on a mock-up? Just <i>meteor create myapp</i> and start. No boilerplate. No script and style tags. Heck, add bootstrap with a single line of command and you start with fine-grained classes! Sure you might need a database... don&#x27;t worry! No need for schema, modeling, whatever, the server is already there and so the database.<p>Eventually you might want to scale and then, as in any library&#x2F;framework&#x2F;platform things will get a little more complicated. I don&#x27;t see it as a problem, really.<p>Meteor always was opinionated and maybe some opinions were unpopular from the beginning (MongoDB, for example). But when you start adding multiciplity (React&#x2F;Blaze&#x2F;Angular for the frontend, Iron Router&#x2F;Flow Router&#x2F;React Router for routing, Meteor Package System&#x2F;NPM...) you can lose the track. I&#x27;m afraid this is happening now.

&#x27;All happy families are alike; each unhappy family is unhappy in its own way.&#x27; -Tolstoy<p>It seems that many people are unhappy with Meteor in its own way. It takes 375 factors to make a &#x27;Rails&#x27; and Meteor has 370 for each person, but each person is missing a different five.

As a newcomer to Javascript frameworks I totally love Meteor JS. I come from Java backend programming and My Job&#x2F;Client always worked on proven not so recent frameworks like Spring etc. I always wanted to learn the Javascript frameworks but the vast options there are made it very difficult. Too many JS frameworks, Too many choices. I started learning Angular and they decided to do a makeover which requires learning from start. Even React isn&#x27;t something quick to master.<p>But Meteor, it just made my move into Javascript webapps so easier. I&#x27;m seeing results instead of that paralysis of am I learning the right framework. I&#x27;m also almost 80% done with my niche Classified ads site.<p>Meteor JS is best thing I picked up In 2015.

So, Meteor is going to turn into what SocketStream was, five years ago, before it was completely eclipsed by Meteor&#x27;s marketing steamroller.

Meteor is easily the most productive webstack I&#x27;ve ever tried (couple of years ago) including learning, app setup, configuration etc vs some of other popular choices. I hope at least some of that carries over to what ever is coming out next.

We used meteor at my last company. By far and away the biggest issue was being stuck with Mongo. NoSQL databases have their place. But they are not a universal solution to everything (or even most things).<p>Relational DBs exist for a reason.<p>Being stuck with Mongo is the major reason why I wouldn&#x27;t use meteor again.<p>The other stuff was minor and had solutions. We also built an open source library that wrapped up collections well.<p><a href="https:&#x2F;&#x2F;atmospherejs.com&#x2F;patmoore&#x2F;meteor-collection-management" rel="nofollow">https:&#x2F;&#x2F;atmospherejs.com&#x2F;patmoore&#x2F;meteor-collection-manageme...</a>

The reason I picked firebase over meteor was ember support. Ember and ember data on top of meteor would be a killer combo for me.

This is a little worrying; after much research I&#x27;m starting a new project for a startup using the meteor stack.

So, full disclosure: I recently co-authored a book on Meteor which comes out in a few months[1]. I don&#x27;t think Meteor is a cure-all panacea or that it&#x27;s the Best Framework Ever®. I&#x27;ve come to Meteor with a fair bit of experience (Play 1.0&#x2F;2.0, Sails.js, Flask, etc.) and a fair bit of skepticism. However, I really don&#x27;t think much went wrong with Meteor. In fact, it treads some of the same ground as its predecessors. As far as OP&#x27;s article is concerned, I have some very specific squabbles with it:<p>&gt; This creates a bigger barrier to entry compared to front-end frameworks like React and Angular, or server languages like Go or Elixir.<p>Okay, Meteor has an arguably bigger barrier to entry than React or Angular (maybe), but definitely 100% <i>not</i> Go or Elixir. I think this is just disingenuous.<p>&gt; I believe some of Meteor’s early choices may have ended up handicapping it. For example, Meteor’s focus on real-time applications makes them a lot easier to build compared to any other platform out there. But it does also come at the cost of hidden complexity, and potential performance problems down the road.<p>This is the #1 problem of every framework, ever. Mr. Greif is not saying much, if anything at all.<p>&gt; Once a new Meteor user starts to go beyond the basics and look into things like routing, pagination, subscription caching &amp; management, server-side rendering, or database joins, they realize that the difficulty curve quickly ramps up.<p>Here, he&#x27;s conflating things that are easy (routing and pagination) with things that are hard (subscription caching), so it&#x27;s hard to see exactly what the criticism is here. Not to mention that Iron Router are pretty mature. I haven&#x27;t run into a routing issue yet that it couldn&#x27;t solve. As far as joins and caching, etc., these are definitely difficult things. I don&#x27;t think <i>any</i> framework out there completely (and in the general case) solves these out-of-the-box. Maybe someone could introduce me to one.<p>&gt; The result of all this is that Meteor has ended up in an awkward place.<p>I think it just ended up where almost all other frameworks end up: useful, but not completely generalized. In fact, I think striving for a very high degree generality might be a mistake, lest we want to end up with something like Hibernate.<p>[1] <a href="http:&#x2F;&#x2F;www.amazon.com&#x2F;Introducing-Meteor-Josh-Robinson&#x2F;dp&#x2F;1430268360" rel="nofollow">http:&#x2F;&#x2F;www.amazon.com&#x2F;Introducing-Meteor-Josh-Robinson&#x2F;dp&#x2F;14...</a>

In my experience, the best part of Meteor is its tightly couple stack so that I can developer very smoothly. But the worst part is also its tightly couple stack when my web&#x2F;app grows. Really hope that it would be easier to decouple some important package like tracker or minimongo

Lots of fear mongering here and as you&#x27;ll notice, a lot of voice from inexperience with meteor itself.<p>We bet on Meteor and it&#x27;s doing phenomenal. The development experience is great. I haven&#x27;t been this happy and impressed since rails .9 ripping me a new case of programming love.<p>Look, meteor has it&#x27;s downfalls but so does any stack. There&#x27;s nothing working against you, it&#x27;s all just code. There&#x27;s no magic. You don&#x27;t understand subscriptions, merge box, and how to handle joins? Level up a little bit. It&#x27;s not a hard thing to figure out. Open source code makes it easy to dig in.<p>Yes, mongo is looked at in bad light, it&#x27;s also incredibly powerful when used right. The trick is to not be oblivious to the tools you use and work around it when it matters.<p>The most important thing for a product, startup, and company is the ability to make the right calls and grow at the right time and then be able to handle and accommodate problematic areas when you need to.<p>Does meteor scale? Yes. Does it have a theoretical limit? Yes. The trick there is to be cognizant of the limit and plan around it when you are approaching.<p>It&#x27;s all just JavaScript at the end of the day.<p>Oh you want to scale out your processing? Easy. Fan out some back end nodes in whatever language you want. Pull from mongo, do your crunching, and then feed it back in. Then meteor will sync it to all clients. This is pretty powerful. You can completely swap out and fan pieces out with meteor.<p>We have a massive app in meteor. It&#x27;s also architected to be modular if we have to break it up.<p>The isomorphic nature of the code base has created pleasant APIs on both the front end and back end and has drastically simplified a real time app experience. Meteor sets a new standard for web applications and demands new perspectives. When you embrace it you get an ecosystem that is quite revolutionary to work with. Everything from the web-app, latency compensation, pub&#x2F;sub, down to Cordova builds.<p>Overall, we are very happy. Yes things can be better, and we are looking forward to seeing meteor evolve.<p>Meteor shouldn&#x27;t focus on supporting new view frameworks like blaze vs react. Just focus on adopting the tools out there and making it better. That&#x27;s why meteor doesn&#x27;t need blaze. Meteor doesn&#x27;t need a router. Meteor should pick the best open source versions of that in the Js community and make it easy to work with inline with the &quot;vision&quot;. Meteor should focus on the developer UX. This is their power. An opinionated framework that removes the stress of configuration and has tools that fit really well together to allow an individual, team, and company to focus on building what matters: features.<p>The vision is grand and I believe it in and I&#x27;m also not worried about scale. People said the same shit about rails, and x, y, z. Scale is a good problem to have and when you have that problem you&#x27;ll figure out what you have to do.<p>If anyone has any questions about meteor architecture feel free to ping me.<p>---

Another place I&#x27;d love to see Meteor move towards the (future) standards would be an eventual replacement of Fibers with async&#x2F;await throughout, which to me is more explicit and intuitive.

I think the problem with Meteor is that it&#x27;s not meaty enough...<p><a href="https:&#x2F;&#x2F;github.com&#x2F;mattkrick&#x2F;meatier" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;mattkrick&#x2F;meatier</a>

&quot;Project Foo: The Greatest Thing Ever&quot;. What is that? I should look into that.<p>A year or two later. &quot;Project Foo: Total Crap&quot;. Glad I didn&#x27;t look into that.

&gt; The recent Blaze&#x2F;React debate<p>Can someone point to the backstory here?

I was turned off to Meteor when one of the initial releases was touting being able to use the browser console as a Mongo shell. Never took it seriously since.

I can sympathize greatly. I played around a bit creating an isomorphic &quot;framework for frameworks&quot; to explore some techniques I didn&#x27;t get to use in my day-to-day. There is a constant tension between leaky abstractions and expressing functionality meant to run in very different environments that I personally am taking years to fully grok [0]. Of course, unlike the meteor folks, I&#x27;m doing it for fun, so there is no pressure to make any money doing it on my end.<p>[0] for instance, I made it trivial to invoke client functions asynchronously from server code using normal call syntax. Now how to deal with timeouts? The syntax doesn&#x27;t permit much without leaking, destroying the original point.

Meteor is great and Im optimistic what 1.3 will bring with better NPM support.

I&#x27;m sorry, but how are you in a lead position but somehow didn&#x27;t understand a timeless principle of software development?