11 ms·

The State of Meteor Part 2: What Happens Next

253 points by wsvincent 11y ago

desireco42 11y ago
It is kind of sad that this wonderful framework, from total awesomeness, came to this situation where I am not sure what will future bring and should I make my projects in Meteor. Meteor started with huge advantage, it is auto reloading, it has data layer that is very simple to use, it syncs across clients. On top of that, you can package mobile apps with it. One thing I really loved is Velocity, testing runner that would display a dot in the corner of the screen, it would run a testsuite, and if it turns red, you can click and learn what test failed. I was hoping it will be more awesomeness, instead, they eliminated Velocity, testing is not clear cut, db layer that needed most attention is not getting enough, whole focus is on frontend. React is awesome and adding it, it really brings a lot to Meteor, but I think Blaze was good enough. Anyhow, now I am Elixir/Phoenix dev, don't feel the same pain I did before, but any positive news from Meteor would be very much welcome.
- dfischer 11y ago
  Phoenix is the only other thing that really appeals to me as something I want to try that is fun. That was the great thing about Meteor, it got a lot of shit done, and it was fun. That's important. What do you do to hook into Elixir? What's your tech-stack for the other side of the back-end? I was looking into phoenix/elxir generating GraphQL but that seems pretty immature and at least a year out to be comparable with Minimongo/ddp.
  - desireco42 11y ago
    I just use Phoenix/Elixir. I can wire it with React, but honestly I am starting to question this. Only if I really need React, I will actually use it. So far I work on simpler stuff, api's and smaller apps.
    - dfischer 11y ago
      Yeah that's the thing though. Meteor made the front end trivial. That's a vital piece to the whole pie. Oh well, I guess we'll see how the next year goes.
stevebmark 11y ago
I predict that Meteor will won't go anywhere in 2016. I know this sounds negative so I'll try to explain. The surface area of Meteor is still too large. Keep in mind this is a venture backed company, people are getting big salaries to work on a framework. Look at what it's led to: in house tools like Blaze which even the creators are already tired of. At best Meteor will be 90% cannibalized and replaced with open source tools (as this blog post is implying), and sit properly in the same place as other CMSes, which inherently don't get that popular. What's worrying about this post in particular is it's not business focused, and the only long term company goal mentioned is "meteor will be a back end solution that makes sense." To what end? Why wouldn't you do that in a non-profit or pure open source model?
- forax 11y ago
  Part of the reason this year has been a bit of a mess is because MDG has been focusing a lot of resources on the profit-generating component of their business: meteor hosting and support. They launched Galaxy (their hosting service) just a couple months ago so it's still too early to say how successful that will be, but it could easily be in their best interests to cannibalize some of their older features if it helps to grow their userbase. For example, not having to spend developer resources on Blaze might enable them to get SQL support out the door sooner. I'm cautiously optimistic for them but wouldn't be too surprised either if they were still struggling next year.
  - joshowens 11y ago
    Not having to spend money on Blaze will make them more competitive as a hosting business. Frankly, when is the last time you saw a billion dollar unicorn hosting business? Or a hosting IPO? I doubt we will see SQL support. We will likely see something with GraphQL instead.
    - jbigelow76 11y ago
      > Frankly, when is the last time you saw a billion dollar unicorn hosting business? Depends on how nitpicky one wants to be differentiating a colo from a managed host, but IBM purchased Softlayer for $2 billion back in 2013.
NhanH 11y ago
Can someone chime in as to whether React won the frontend war? As in the super majority of new project will be developed in React. I'm not that well-versed in the Node ecosystem (I got my news from ... HN). But from little I've seen, I found it hard to believe that React would be able to react the place where jQuery was (is?). Heck, we even have a post staying on the front page today lamenting the inferiority of React.
- desireco42 11y ago
  I think it did, but this is JS we are talking about and tide will turn quickly.
- d0m 11y ago
  One interesting thing about React is how some big names (Amazon, Apple, Netflix, Yahoo) rallied to React instead of creating their own libraries, whereas they all had their own-cooked libraries before. Also, which is more of a personal opinion, but I've tried a lot of frameworks/libraries and React is the first one that really "clicked" with the way I work and design. I don't think it will "replace jQuery", but for modern single web application, I think React is the way to go. Or said differently, "Nobody will get fired for choosing React" ;)
  - yazaddaruvala 11y ago
    I have read blog posts by Yahoo and Netflix. While I believe you, I'm just curious how they are being used by Amazon or Apple. Do you have references about this?
    - TheAceOfHearts 11y ago
      Apple held a ReactJS meetup on December and they showed off a declarative graphing library for React that they'll probably open source some day.
  - ef4 11y ago
    > some big names (Amazon, Apple, Netflix, Yahoo) rallied to React That's a bit of an overstatement. At least three of those four are also shipping major Ember apps and investing heavily in that ecosystem. (The only one I don't know for sure is Amazon.)
d0m 11y ago
I completely agree and I'm excited about this vision for Meteor. The dream would be to have a go-to choice with formidable standards that Just Works. Personally, what I wish existed was a full-stack framework AND dev ops built with the "best" open source libraries. I'm fine with not having my favorite X if it means having a set of well supported, highly performant with lots of documentation and training materials services that work perfectly together. Starting a new project the "right way" is a pain right now. Again, I would gladly trade my favorite libraries/tools for a great full-stack solution (including dev ops, continuous integration, roll-back deployment, scalable servers, etc etc.) Software engineering is still a new field and it's hard to establish "best ways of doing things", but I'm wondering if it'll start converging to "The Proper Way". Similar to how building houses is pretty straightforward. Of course, part of the reason that it's hard to do in software engineering is because technology keep changing so fast.. I.e. Tools from a few years ago will most likely not play well with VR stuff.
- jonesb6 11y ago
  I'd strongly disagree with the idea that we need or even want one ring to rule them all. Remember different frameworks are designed to solve different problems in different ways [1][2]. Anyone who has dug deep enough into a framework or tool-set will be able to write out a very long list of unique quarks, gotchas, caveats, hidden strengths/weaknesses, and what have you. It's those differences that will make one framework more valuable in a given domain then the other, we want that because there are many, many, domains to conquer in software engineering. IMO, innovation stops when we believe we've found "the best way of doing things". I'm all excited to check out Meteor too, but I'm not getting in line at the Apple store, I mean full-stack framework store, on the day of release to be a guinea pig for the "new best thing" at my personal expense (time). [1]: https://en.wikipedia.org/wiki/Ruby_on_Rails https://en.wikipedia.org/wiki/Ruby_on_Rails [2]: https://en.wikipedia.org/wiki/Django_(web_framework) https://en.wikipedia.org/wiki/Django_(web_framework)
  - kevan 11y ago
    What if we replace "best" with "good enough for most common uses"? Most of the roads and bridges we build today aren't pinnacles of innovation, they're just good enough that we don't bother optimizing them much more. With how young the software engineering field is I don't think we'll get to this point in the near future, but part of me looks forward to a day when we have widely accepted standard solutions to common problems that don't go out of style for decades.
deleted 11y ago
[deleted]
tomcam 11y ago
Might have been different if they had chosen to embrace SQL, instead of just putting it on the roadmap and letting it rot.
- jlas 11y ago
  I can't imagine how many enterprise sales they're losing because of lack of SQL support
- glenk 11y ago
  This has been my feelings on meteor as well. It looked neat and I went through some of the tutorials and such, but really had no projects I could use it on. All my current projects interact with various sql database at some point. I realize that isn't as cool as all the nosql stuff, but I kept hoping they would get to it, and then kept getting disappointed. It's a pretty narrow full stack to me if you don't have real support for sql databases. It's been sitting there for 3 years and has about the highest votes of all them. They had a post about experimental postgresql project in august(http://info.meteor.com/blog/an-early-look-at-sql-in-meteor http://info.meteor.com/blog/an-early-look-at-sql-in-meteor), but it's mostly sat there with a few updates since then. It doesn't seem to be much of a priority.
  - siquick 11y ago
    Exactly this..
- dfischer 11y ago
  See, when people see that, they miss the point a bit. The beauty of Mongo is it syngerzies extremely well with a pure javascript approach.
  - SignMeTheHELLUp 11y ago
    Getting fired also "syngerzies" well with a pure javascript approach.
    - 11y ago
joeblau 11y ago
> And Angular is… well, it’s not React. Can someone explain what this statement means in terms of the technical benefits of React over Angular?
- epmatsw 11y ago
  Probably just means that Angular (at least seems to be) losing momentum and marketshare to React. It's hard to go a day without seeing something cool or exciting about React on the front page here, but all you see about Angular is either nothing or articles about the upcoming(?) transition to 2.0.
  - deleted 11y ago
    [deleted]
- sgdesign 11y ago
  I meant it's not so much about the technical merits of Angular and React, as just picking one (React) and sticking with it.
- AlwaysBCoding 11y ago
  My $0.02 React is a rendering engine, it's covers the final piece of your web app (rendering a data structure into DOM). But whatever you do to create the data structure that gets passed to React is up to you. This keeps most of your domain logic outside the context of the React framework, you just use React as a tool to render you final data structures into DOM. So basically the API you need to know for your domain logic is just Javascript, which most people know already and it's really easy to lookup answers to your questions etc... With Angular your domain logic exists inside the context of the framework. i.e. if you ng-repeat something you can't just filter that collection with Javascript you have to use an ng-filter to do it which is a special Angular construct. So the API you have to learn to manipulate data isn't just Javascript it's Angular-specific. And what if you don't know how ng-filter works? Well, you're tied to the Angular docs to figure it out. The Angular docs are of particularly poor quality so this coupling turns into a really serious problem if you're trying to be productive, because you're constantly reading docs to figure out how you do something in Angular. I'm not sure how Angular2 is since I haven't used it, but to me React vs. Angular1 is a no-brainer win for React, since it's much easier to be productive in React + you can target mobile now with React Native. Something I've noticed also, there are basically no developers who have switched from React to Angular and now evangelize Angular, yet there are thousands of people who have switched from Angular to React and now evangelize React. I think that speaks for itself in the sense that anyone who has used both extensively prefers to use React.
apalmer 11y ago
I am amazed by how the article attempts to look forward to what the future will hold with JavaScript frameworks... and yet seems to be completely both dismiss or misunderstand (perhaps willfully) why previous frameworks have succeeded. jQuery did not succeed because it was a 'good enough' competitor to dojo or prototype or mootools or extjs... it succeeded because it went completely the opposite direction. it did not attempt to be a fundamental ui framework like those guys, it didn't try to be full featured, it didn't try to change javascript to look like another language and didn't try to shift the paradigm of the front end development world.
- arnorhs 11y ago
  well said. another important thing to remember is when jQuery came about interfacing with the DOM was really messy across browsers. Ajax queries as well. simplifying those, in my opinion, the killer features of jQuery at the time. Interfacing with the DOM was not even something that dojo, mootools etc were doing at the time. At least that part wasn't as obvious/easy in those frameworks.
  - lolc 11y ago
    The big change I experienced with Jquery is that it operates on sets of elements. It eliminated most guards and loops I'd been accustomed to when dealing with the DOM.
- incepted 11y ago
  jQuery filled a need. It's as simple as that. Its success has nothing to do with looking in the other direction or not redefining Javascript: it solved a problem that a lot of Javascript developers were struggling with. Now what's really fascinating to me now is that while one can safely say jQuery created a revolution in the Javascript world when it came out, it is today widely looked as a smell and avoided as much as possible in favor or frameworks that modify the model instead of the UI. And this quick rise to success and fall to obscurity could very well happen to the successful frameworks we are currently using today (including React).
  - 11y ago
MrBlue 11y ago
Is Blaze vs React really the issue? Try running a Meteor app with >500 concurrent connections.
- sergiotapia 11y ago
  Let's say hypothetically I have 600 concurrent users, what steps can a Meteor dev take to increase performance?
  - vskarine 11y ago
    Most meteor apps are stateless on the server so you can safely scale by adding more servers (and more server to Mongo if that's the bottleneck). This can be easily done with Cluster package (https://github.com/meteorhacks/cluster https://github.com/meteorhacks/cluster). It's so easy you don't even need to configure anything.
    - sergiotapia 11y ago
      I'll think it's easier (maybe more expensive) to just use Galaxy, and scale. Then host your Mongo database on Compose.io that also scales.
  - imslavko 11y ago
    As the sibling comment said, you do the same way you scale anything else: add more servers that replicate the same data. As it becomes to large, shard your publications depending on type. Meteor's livequery works better serving a lot of similar subscriptions, so at some point you can have multiple server types each taking care of one scope.
- all_the_things 11y ago
  Can you elaborate?
ricardobeat 11y ago
This is important because development standards are a winner-takes-all game: once jQuery became the default, it enabled an explosion of plugins and components built on top of it, and every JavaScript widget became a jQuery widget. The exact same thing might very well happen with React. And that’s a very exciting thing for Meteor. Thankfully we know a bit better by now, and build modules with a small surface area that are not directly tied to frameworks or plugin APIs. So no, I'm not so excited about that happening to React.
matthewrudy 11y ago
Meteor's best trick has always been data synchronization. That was the magic trick that sold your client. They proved real-time data synchronization could be simple and seamless, and everyone else had to run to catch up. But that trick is now 4 years old, and nothing else of substance really emerged. As Ember, Angular and React grew, you were never going to want to use their odd looking front end. Their data sync also came with dubious claims to scalability, not the least is their tie to Mongo. That may be fixed now, but the consequence is being tied into Meteor Galaxy. Meteor should have thrown everything away, and become just the data layer. Like Firebase, but open source, and backend / datastore agnostic. They tried to standardise DDP, but it didn't catch on. But what the world needs is a standard like GraphQL, but handling data updates, and with automatic realtime data sync. Thatd be a wonderful legacy for Meteor. But this won't happen, as the company needs to make money from hosting.
- dfischer 11y ago
  GraphQL and Relay may be the answer but it's too young to make that switch now and Meteor is solving that exact problem. Meteor has the momentum and community to take it further. Maybe it actually adopts the GraphQL standard and unifies it into the ultimate dev UX experience.
  - matthewrudy 11y ago
    It might happen, and the next year or so will decide its fate. Exciting!
  - pacnw 11y ago
    Yeah, I went down the Relay/GraphQL rabbit hole for a good 1.5 months last year, but unfortunately there is a tremendous amount of work to set up GraphQL servers to even get your data out to Relay, and it is not real-time at the moment (although the 'community' appears to be work on it. I so wish Meteor would provide a drop-in module for just the DDP, I don't even care if its Mongo, their real-time subscription works.
- huula 11y ago
  Completely agree! Hope Meteor community would seriously consider this.
dham 11y ago
I strongly urge you to take a step back and really look at React community from 30,000 foot view. Please don't get on the hype train without taking a look at other solutions. Vue.js as far as libraries go, and Ember as far as framework go. I promise you, you'll have a better experience.
- ocean3 11y ago
  Vue.js seems like backbone. Last time i checked Ember looked way complicated. What i like about React is the simplicity. Its basically JavaScript with few React functions thrown in. As a view component its very good. I have used it in normal rails app as well.
- rimantas 11y ago
  As an old-school html purists I am off-put by Vue's markup. The same goes for any framework that needs invent their own attributes and tags.
devcheese 11y ago
what major production apps are build with Meteor? This might be the wrong place to ask but I figured it's worth a shot.
- ollerac 11y ago
  https://www.quora.com/Which-startups-use-Meteor-in-production https://www.quora.com/Which-startups-use-Meteor-in-productio...
- codesuela 11y ago
  https://www.meteor.com/case-studies/build-apps-with-meteor https://www.meteor.com/case-studies/build-apps-with-meteor
matthewvincent 11y ago
Seeing the Discover Meteor and Kadira guys embrace React with Meteor is definitely making me want to dive back into the framework after being very hesitant over the past few months. It's great to see ~someone~ with a clear vision for the future.
sergiotapia 11y ago
My thoughts: Meteor got popular enough that the Javascript loons started pecking at it and infesting it with the general lunacy that accompanies NPM and it's ecosystem. MDG adding easy React support was a definite win and I think using Meteor with React is -the- way to write Meteor apps. But they need to start ignoring the crazies out there and focus on their vision.
- jorgecurio 11y ago
  laravel is fine too
EGreg 11y ago
This all boils down to one key fact: Meteor is the only framework that controls the whole stack. After all, the fact that no other company than MDG has even tried to make it happen should be proof enough that it’s not trivial. I did it, over the last 4 years http://qbix.com/platform http://qbix.com/platform Actually our platform aims to be an entire "Wordpress for social networks". We realized that identity, security, roles, permissions, consistency and realtime updates etc. are hard to get right and building a standardized platform will free up developers to focus on what their app does instead of reinventing the wheel, etc. Not only that, but it will allow interoperating and reusability of components across all the sites. And yes, it does routing, pagination, components and more in a way that will give Angular and React a run for their money if you check it out. Also it does a lot more: http://qbix.com/platform/features http://qbix.com/platform/features PS: try loading all this on your smartphone!
- faceyspacey 11y ago
  yours isn't a full stack reactive platform. great work though.
- strongai 11y ago
  This looks fantastic! Please could you write some words aimed at potential recruits to qbix? What to expect, what not to expect. I noticed, in scanning your site quickly (... I think all content should bear the 'scanning user' in mind, but that's another topic) that php is mentioned. What php knowledge is required? What JS knowledge is required? Make it easy for people (I mean really, visitors who are pre-tutorial) to decide if they have the wherewithal for it to be worth them making a modest commitment to take it for a test drive.
  - EGreg 11y ago
    You can put together a site with hardly any PHP knowledge. Just place reusable componenets on pages, or widgets that connect to ready-made backends... but then you don't really need this framework. But if you have some basic PHP knowledge, you'd create more pages, and perhaps some backend actions. As far as the PHP and JS knowledge, see http://qbix.com/platform/guide http://qbix.com/platform/guide The more PHP and JS you know, the more you can do. Unlike React and Angular, though, everything is named in a super-straightforward way, like Q.page and Q.Tool and tool.children() etc. So you just go ahead and build your site and Qbix does a ton of things for you, like dynamically swapping out css/js as you navigate pages, takes care of history and routing, activates and removes tools and their associated events, lets you subscribe to exctly the events you need, and documents conventions you should use to play nice with everything else.
all_the_things 11y ago
I gave it a try a few weeks ago but every other package was unsupported because a new package was being developed rather than following semver, the standard server logging was terrible when I had to debug a frontend dev's memory issue. Seems like the Wordpress of realtime applications. The DDP package is interesting but only helpful to supported DB's as far as I could see. I think choosing GraphQL will just narrow their 'full stack ecosystem' again. Why not provide better low level support for your community to write GraphQL Cypher, SQL and NoSQL themselves. There are some great packages I've seen for this.
jbhatab 11y ago
This is fantastic. This removes efforts to maintain a random front end view layer while legitimizing the numerous react integration attempts. This will save a lot of time moving forward to phase out blaze.
pm24601 11y ago
The problem with Meteor is not the front-end. The problem is that data exists (for the most part) in Relational DBs. This prevents Meteor from being used in any environment that needs to/wants to use a SQL db. This prevents Meteor from being used in any form, for any application that needs to access existing data in a SQL db. React does not prevent Meteor being adopted - not having SQL support is a dealbreaker. If Meteor does not confront and solve this problem nothing else matters. The only thing MDG should be doing in 2016, is SQL DB support.
- dror 11y ago
  It's probably too late. The work they've done with blaze is wasted since react and angular(still) are dominant. The work they've done with MongoDB is wasted since most of the world wants SQL. So what do they really bring to the table. It feels like too little too late.
- mxxx 11y ago
  Agreed. If anybody thinks the real problem with Meteor is that it uses an antiquated templating system they're missing the bigger picture.
shadowmint 11y ago
Why will it be any different this time compared to last time with GWT, Dojo or SproutCore? Server - client binding javascript widget frameworks are nothing new, and they have, historically, failed to be capture broad adoption because they require a very specific backend. If you had an excellent series of react components with data binding done via an open server specification and meteor just happened to be one implementation that backend; people would really dig that! ...but there would be a lot of people who didn't use meteor at all; and just wrote their own server implementation for it. “but wait, if we end up using React, Relay, and GraphQL, what do we even need Meteor for anymore?”. ... This all boils down to one key fact: Meteor is the only framework that controls the whole stack. So what? Who cares? Controlling the whole stack isn't even remotely interesting unless there's some tangible benefit from it. This is by far the weakest and least compelling part of this article. So this is my vision of the future of web development for 2016. React as a common front-end standard, and Meteor starting out as one of many possible back-end choices, but slowly becoming the one that just makes sense. You really need to try harder to explain why Meteor would be a compelling choice for people then. If the front-end component api is well defined and backend agnostic, meteor seems to offer literally no particular benefit over any other backend someone might choose.
holonio 11y ago
I think the "server-aware" components are an incredibly important point. Consider user authentication. Anyone who has written a SPA with Node (e.g. Express) and React on the frontend knows how painful it is to integrate with login services, even with something like Passport.js. The value of having React components that can deal with what happens on the server is pretty huge. Right now, most of the abstractions we build on the server and on the client are pretty disconnected because server and client frameworks operate independently of one another. That means that the abstractions we build often don't really abstract away all that much stuff. Writing an auth system or a feed, etc. every single time you start a new project is a huge pain and something Meteor is in a great position to completely eliminate.
osoti 11y ago
The stars who sizzled the Golden Globes 2015 http://goo.gl/Iz6899 http://goo.gl/Iz6899
pedalpete 11y ago
I just started with Meteor a few weeks ago, and thought it was absolutely amazing as a prototyping tool. I figured I'd be recommending it to anybody doing an MVP. I actually do believe there is a business model there, but it seems they are focused on the high-end with hosting and support starting at $500/month
dfischer 11y ago
I said more in the other thread, but I'll leave another note in this one. What I think Meteor has the most going for them is the ultimate UX experience for the developer. If they really hone in on making it enjoyable, and dare I say fun to work on product... then they've won in my book. Meteor has given me that feeling thus far, and given the new trends in the community I am sure they are moving in the right direction. I've spoken with the guys there and they are carefully reviewing what the best routes are to take that creates the best experience. Meteor is not just a vision, it's a real experience you can tap into right now that benefits a very powerful suite of tools to get up and running. We have an enterprise app built with it and it's going great. Yes, it'll bite you in the ass if you don't learn how things work (pub/sub/mergebox/reactivity) but just dive in a little and you'll see it's just a library composed of other libraries that are well documented and easy to learn. It's all really quite simple really. The beauty and evil word "magic", is how they all play well with each other. React is probably a better choice than Blaze at this point, even for the pure fact that it allows Meteor to not worry about the view and focus on the overall UX experience of the developer above all else.
- tonyonodi 11y ago
  I couldn't agree more, it's a god send not to have to wade through documentation and work around a hundred errors while you set everything up; before you've written any code. The freedom to iterate on new ideas quickly that a NoSQL database gives you is rather nice too (even if that's a terrible reason to choose a performance-critical part of your stack). I'm sure all this magic comes with a penalty further down the line so I'll let you know whether it was worth it when I get there...
khwhahn 11y ago
I'm sure that Angular 2 would be a better choice for a Ecosystem like Meteor. React is very nice, but annoying to find tutorials, get a decent size app going (routing etc) and Angular 2 is more mature (all the good and bad points of NG1 and other js-libs were considered). Next to Google also Microsoft is betting on Angular 2 (TypeScript). This will boost the community greatly. NG1 was slow. NG2 is amazingly fast (webworkers/server side rendering). So for a Meteor Use Case I would pick NG2. If I wanna build a simple Snippet I would use React.
lambdacomplete 11y ago
Dove into react and redux and built a couple of small apps. They are amazing not because they add some "fancy" features but because they train you to think with a different, much cleaner and simpler, mindset. Before your brain "clicks" you feel miserable. After it does you think "why on earth isn't everybody using this??" and any problem is solvable by dispatching actions and building reducers (thank you Redux!). Three days ago I spent a couple of hours on Meteor's simple-todos tutorial, trying to understand how everything was working (that is, at an abstract level). I felt great after finishing it. Two days ago I started building a service we'd like to launch within a couple of months, e-commerce like stuff. I felt miserable. Pushed the first "draft" with a customized sign up and I felt like I had no idea how to proceed. Yesterday I spent 4 more hours, started using packages like autoform, collection2, something for bootstrap, iron-router etc. and I feel FREAKING GREAT. Again my brain clicked and now I implemented ~70% of the features with validation, defensive checks on the server for security, nice-looking popups, good overall UI... I mean, I intended it to be a prototype, maybe mocking some parts but, damn, we basically already have a MVP! In 3 days (effectively ~12 hours)! And now I already know how to implement the rest, it just feels natural now. Like when you have a solid plan and you think it through in your head and you KNOW how to implement each and every step of it. You can hit a wall with Meteor as much as you can with any other framework (I mostly use Django). It's all about reading the docs, looking at what the community is doing and try to adhere to some "guidelines" (if there's no standard way of doing something). I will let you know how it scales when we reach a couple million users (bazinga!).
- codesuela 11y ago
  I don't know if you are aware but there is now an official guide which goes way beyond the scope of the docs. http://guide.meteor.com/ http://guide.meteor.com/
  - lambdacomplete 11y ago
    Yes I'm already reading that. Thanks for the hint!
oliv__ 11y ago
I've been using Meteor for little over a year now and to me, the real selling point for Meteor was the insane speed, productivity, and almost instant gratification that results from that speed: all of a sudden you went from having to configure a million different moving parts to just coding, almost forgetting that you are coding in the process, enjoying yourself, and suddenly seeing your features pop out of nowhere. It's quite magical. For someone like me (I'm more of a designer who can code than the opposite), the reactivity, feedback and interaction with your code make the whole process feel much more "hands on", almost like sculpture, in the sense that you are able to poke things and see them react instantly. And that makes all the difference. Yes, many problems do appear once you dive deeper, but I've never used another tool that brought me closer to my ideas than Meteor. And in the end, that is for me the single biggest achievement here.
neximo4 11y ago
Meteor started off so brilliantly. I wish the team would focus and just make it great. Many people would complain about SQL and what not but the truth is there's a very large number of people who are quite happy with MongoDB and the fast experience building an app. However there are some really big issues that seem to be ignored: 1) It's nice that its backwards compatible but some essential features are missing such as a router. Iron Router is available but it's practically abandoned. You can't even have URL's such as /2 on it. It makes it hard to keep an app for the long run knowing there is a risk of an essential component about to be abandoned. Other similar projects include Meteoric (an Ionic wrapper) 2) I wish they'd focus on making Blaze work. It works. Many people don't like react and just want an App build on V1 to work with V1.5 and V2. The lack of clarity is harmful to the use of Meteor in The Enterprise. 3) The build time. It used to be that Meteor built a project near instantly when a file was changed and hot code changed the page. Now it takes a good 20 or so seconds for a simple line change. It seems over the top. 4) Clarity and focus on direction. They spent ages pushing people to their Npm system, now they're going back. Why not start with node_modules/complete npm support instead of flipping back and forth. The volatile state of affairs with Blaze, Npm and the general structure of an app manifests risk in choosing Meteor for an actual Enteprise grade app. 5) A focus on improving what already works well over adding new features and degrading the performance of existing features. I mentioned the build time, but other parts of Meteor such as Cordova, Blaze, Tracker, Mongo (Meteor uses MongoDb 2.6?!) would certainly help more. I'm not sure what's happened but it seems a lot like the team is losing focus of what people actually like about the project.
- raffomania 11y ago
  I especially agree with 3). I was expecting more people to mention this. Compared with other build systems like wepback or gulp, meteor rebuild times are insane. edit: Just checked out the Meteor Roadmap, and build times are not even mentioned there.
  - neximo4 11y ago
    It used to be. The current implementation is the result of the effort in speeding it up.
ryannevius 11y ago
Only semi-related...but why do you think Mithril is always so easily dismissed? I kind of get it: huge companies are working on and adopting React. But after using Mithril, I just can't figure out why it has failed to catch the attention of more people.
- raffomania 11y ago
  I remember that I found the documentation quite hard to read at the time I was checking it out.
- brlewis 11y ago
  Mithril succeeded in catching my attention because creating a good mobile web experience is important to me. This does not necessarily explain why it has failed to catch the attention of others, but might be a clue.
- deleted 11y ago
  [deleted]
malloryerik 11y ago
Can anyone here compare Meteor with a full Clojure(Script) stack?
oelmekki 11y ago
Mootools is not an ancestor of jQuery, it actually was released after jQuery (by a few days). From what I recall, the success of jQuery was not because it allowed to do more things. It was mainly because developers by then considered javascript as a lower citizen language and wanted to do frontend stuff without having to learn javascript - and jQuery allowed just that. For (the few) javascript lovers, jQuery main advantage was to be a big decorator, not extending any native, which guaranteed there will be no conflict with other libraries when adding jQuery in a page (quite ironic, when you see how all libraries expect jQuery may be present in the page, nowadays).

253 points by wsvincent 11y ago

It is kind of sad that this wonderful framework, from total awesomeness, came to this situation where I am not sure what will future bring and should I make my projects in Meteor. Meteor started with huge advantage, it is auto reloading, it has data layer that is very simple to use, it syncs across clients. On top of that, you can package mobile apps with it. One thing I really loved is Velocity, testing runner that would display a dot in the corner of the screen, it would run a testsuite, and if it turns red, you can click and learn what test failed. I was hoping it will be more awesomeness, instead, they eliminated Velocity, testing is not clear cut, db layer that needed most attention is not getting enough, whole focus is on frontend. React is awesome and adding it, it really brings a lot to Meteor, but I think Blaze was good enough. Anyhow, now I am Elixir/Phoenix dev, don't feel the same pain I did before, but any positive news from Meteor would be very much welcome.

dfischer 11y ago
Phoenix is the only other thing that really appeals to me as something I want to try that is fun. That was the great thing about Meteor, it got a lot of shit done, and it was fun. That's important. What do you do to hook into Elixir? What's your tech-stack for the other side of the back-end? I was looking into phoenix/elxir generating GraphQL but that seems pretty immature and at least a year out to be comparable with Minimongo/ddp.
- desireco42 11y ago
  I just use Phoenix/Elixir. I can wire it with React, but honestly I am starting to question this. Only if I really need React, I will actually use it. So far I work on simpler stuff, api's and smaller apps.
  - dfischer 11y ago
    Yeah that's the thing though. Meteor made the front end trivial. That's a vital piece to the whole pie. Oh well, I guess we'll see how the next year goes.

stevebmark 11y ago

I predict that Meteor will won't go anywhere in 2016. I know this sounds negative so I'll try to explain. The surface area of Meteor is still too large. Keep in mind this is a venture backed company, people are getting big salaries to work on a framework. Look at what it's led to: in house tools like Blaze which even the creators are already tired of. At best Meteor will be 90% cannibalized and replaced with open source tools (as this blog post is implying), and sit properly in the same place as other CMSes, which inherently don't get that popular. What's worrying about this post in particular is it's not business focused, and the only long term company goal mentioned is "meteor will be a back end solution that makes sense." To what end? Why wouldn't you do that in a non-profit or pure open source model?

forax 11y ago
Part of the reason this year has been a bit of a mess is because MDG has been focusing a lot of resources on the profit-generating component of their business: meteor hosting and support. They launched Galaxy (their hosting service) just a couple months ago so it's still too early to say how successful that will be, but it could easily be in their best interests to cannibalize some of their older features if it helps to grow their userbase. For example, not having to spend developer resources on Blaze might enable them to get SQL support out the door sooner. I'm cautiously optimistic for them but wouldn't be too surprised either if they were still struggling next year.
- joshowens 11y ago
  Not having to spend money on Blaze will make them more competitive as a hosting business. Frankly, when is the last time you saw a billion dollar unicorn hosting business? Or a hosting IPO? I doubt we will see SQL support. We will likely see something with GraphQL instead.
  - jbigelow76 11y ago
    > Frankly, when is the last time you saw a billion dollar unicorn hosting business? Depends on how nitpicky one wants to be differentiating a colo from a managed host, but IBM purchased Softlayer for $2 billion back in 2013.

NhanH 11y ago

Can someone chime in as to whether React won the frontend war? As in the super majority of new project will be developed in React. I'm not that well-versed in the Node ecosystem (I got my news from ... HN). But from little I've seen, I found it hard to believe that React would be able to react the place where jQuery was (is?). Heck, we even have a post staying on the front page today lamenting the inferiority of React.

desireco42 11y ago
I think it did, but this is JS we are talking about and tide will turn quickly.
d0m 11y ago
One interesting thing about React is how some big names (Amazon, Apple, Netflix, Yahoo) rallied to React instead of creating their own libraries, whereas they all had their own-cooked libraries before. Also, which is more of a personal opinion, but I've tried a lot of frameworks/libraries and React is the first one that really "clicked" with the way I work and design. I don't think it will "replace jQuery", but for modern single web application, I think React is the way to go. Or said differently, "Nobody will get fired for choosing React" ;)
- yazaddaruvala 11y ago
  I have read blog posts by Yahoo and Netflix. While I believe you, I'm just curious how they are being used by Amazon or Apple. Do you have references about this?
  - TheAceOfHearts 11y ago
    Apple held a ReactJS meetup on December and they showed off a declarative graphing library for React that they'll probably open source some day.
- ef4 11y ago
  > some big names (Amazon, Apple, Netflix, Yahoo) rallied to React That's a bit of an overstatement. At least three of those four are also shipping major Ember apps and investing heavily in that ecosystem. (The only one I don't know for sure is Amazon.)

d0m 11y ago

I completely agree and I'm excited about this vision for Meteor. The dream would be to have a go-to choice with formidable standards that Just Works. Personally, what I wish existed was a full-stack framework AND dev ops built with the "best" open source libraries. I'm fine with not having my favorite X if it means having a set of well supported, highly performant with lots of documentation and training materials services that work perfectly together. Starting a new project the "right way" is a pain right now. Again, I would gladly trade my favorite libraries/tools for a great full-stack solution (including dev ops, continuous integration, roll-back deployment, scalable servers, etc etc.) Software engineering is still a new field and it's hard to establish "best ways of doing things", but I'm wondering if it'll start converging to "The Proper Way". Similar to how building houses is pretty straightforward. Of course, part of the reason that it's hard to do in software engineering is because technology keep changing so fast.. I.e. Tools from a few years ago will most likely not play well with VR stuff.

jonesb6 11y ago
I'd strongly disagree with the idea that we need or even want one ring to rule them all. Remember different frameworks are designed to solve different problems in different ways [1][2]. Anyone who has dug deep enough into a framework or tool-set will be able to write out a very long list of unique quarks, gotchas, caveats, hidden strengths/weaknesses, and what have you. It's those differences that will make one framework more valuable in a given domain then the other, we want that because there are many, many, domains to conquer in software engineering. IMO, innovation stops when we believe we've found "the best way of doing things". I'm all excited to check out Meteor too, but I'm not getting in line at the Apple store, I mean full-stack framework store, on the day of release to be a guinea pig for the "new best thing" at my personal expense (time). [1]: https://en.wikipedia.org/wiki/Ruby_on_Rails https://en.wikipedia.org/wiki/Ruby_on_Rails [2]: https://en.wikipedia.org/wiki/Django_(web_framework) https://en.wikipedia.org/wiki/Django_(web_framework)
- kevan 11y ago
  What if we replace "best" with "good enough for most common uses"? Most of the roads and bridges we build today aren't pinnacles of innovation, they're just good enough that we don't bother optimizing them much more. With how young the software engineering field is I don't think we'll get to this point in the near future, but part of me looks forward to a day when we have widely accepted standard solutions to common problems that don't go out of style for decades.

deleted 11y ago

[deleted]

tomcam 11y ago

Might have been different if they had chosen to embrace SQL, instead of just putting it on the roadmap and letting it rot.

jlas 11y ago
I can't imagine how many enterprise sales they're losing because of lack of SQL support
glenk 11y ago
This has been my feelings on meteor as well. It looked neat and I went through some of the tutorials and such, but really had no projects I could use it on. All my current projects interact with various sql database at some point. I realize that isn't as cool as all the nosql stuff, but I kept hoping they would get to it, and then kept getting disappointed. It's a pretty narrow full stack to me if you don't have real support for sql databases. It's been sitting there for 3 years and has about the highest votes of all them. They had a post about experimental postgresql project in august(http://info.meteor.com/blog/an-early-look-at-sql-in-meteor http://info.meteor.com/blog/an-early-look-at-sql-in-meteor), but it's mostly sat there with a few updates since then. It doesn't seem to be much of a priority.
- siquick 11y ago
  Exactly this..
dfischer 11y ago
See, when people see that, they miss the point a bit. The beauty of Mongo is it syngerzies extremely well with a pure javascript approach.
- SignMeTheHELLUp 11y ago
  Getting fired also "syngerzies" well with a pure javascript approach.
  - 11y ago

joeblau 11y ago

> And Angular is… well, it’s not React. Can someone explain what this statement means in terms of the technical benefits of React over Angular?

epmatsw 11y ago
Probably just means that Angular (at least seems to be) losing momentum and marketshare to React. It's hard to go a day without seeing something cool or exciting about React on the front page here, but all you see about Angular is either nothing or articles about the upcoming(?) transition to 2.0.
- deleted 11y ago
  [deleted]
sgdesign 11y ago
I meant it's not so much about the technical merits of Angular and React, as just picking one (React) and sticking with it.
AlwaysBCoding 11y ago
My $0.02 React is a rendering engine, it's covers the final piece of your web app (rendering a data structure into DOM). But whatever you do to create the data structure that gets passed to React is up to you. This keeps most of your domain logic outside the context of the React framework, you just use React as a tool to render you final data structures into DOM. So basically the API you need to know for your domain logic is just Javascript, which most people know already and it's really easy to lookup answers to your questions etc... With Angular your domain logic exists inside the context of the framework. i.e. if you ng-repeat something you can't just filter that collection with Javascript you have to use an ng-filter to do it which is a special Angular construct. So the API you have to learn to manipulate data isn't just Javascript it's Angular-specific. And what if you don't know how ng-filter works? Well, you're tied to the Angular docs to figure it out. The Angular docs are of particularly poor quality so this coupling turns into a really serious problem if you're trying to be productive, because you're constantly reading docs to figure out how you do something in Angular. I'm not sure how Angular2 is since I haven't used it, but to me React vs. Angular1 is a no-brainer win for React, since it's much easier to be productive in React + you can target mobile now with React Native. Something I've noticed also, there are basically no developers who have switched from React to Angular and now evangelize Angular, yet there are thousands of people who have switched from Angular to React and now evangelize React. I think that speaks for itself in the sense that anyone who has used both extensively prefers to use React.

apalmer 11y ago

I am amazed by how the article attempts to look forward to what the future will hold with JavaScript frameworks... and yet seems to be completely both dismiss or misunderstand (perhaps willfully) why previous frameworks have succeeded. jQuery did not succeed because it was a 'good enough' competitor to dojo or prototype or mootools or extjs... it succeeded because it went completely the opposite direction. it did not attempt to be a fundamental ui framework like those guys, it didn't try to be full featured, it didn't try to change javascript to look like another language and didn't try to shift the paradigm of the front end development world.

arnorhs 11y ago
well said. another important thing to remember is when jQuery came about interfacing with the DOM was really messy across browsers. Ajax queries as well. simplifying those, in my opinion, the killer features of jQuery at the time. Interfacing with the DOM was not even something that dojo, mootools etc were doing at the time. At least that part wasn't as obvious/easy in those frameworks.
- lolc 11y ago
  The big change I experienced with Jquery is that it operates on sets of elements. It eliminated most guards and loops I'd been accustomed to when dealing with the DOM.
incepted 11y ago
jQuery filled a need. It's as simple as that. Its success has nothing to do with looking in the other direction or not redefining Javascript: it solved a problem that a lot of Javascript developers were struggling with. Now what's really fascinating to me now is that while one can safely say jQuery created a revolution in the Javascript world when it came out, it is today widely looked as a smell and avoided as much as possible in favor or frameworks that modify the model instead of the UI. And this quick rise to success and fall to obscurity could very well happen to the successful frameworks we are currently using today (including React).
- 11y ago

MrBlue 11y ago

Is Blaze vs React really the issue? Try running a Meteor app with >500 concurrent connections.

sergiotapia 11y ago
Let's say hypothetically I have 600 concurrent users, what steps can a Meteor dev take to increase performance?
- vskarine 11y ago
  Most meteor apps are stateless on the server so you can safely scale by adding more servers (and more server to Mongo if that's the bottleneck). This can be easily done with Cluster package (https://github.com/meteorhacks/cluster https://github.com/meteorhacks/cluster). It's so easy you don't even need to configure anything.
  - sergiotapia 11y ago
    I'll think it's easier (maybe more expensive) to just use Galaxy, and scale. Then host your Mongo database on Compose.io that also scales.
- imslavko 11y ago
  As the sibling comment said, you do the same way you scale anything else: add more servers that replicate the same data. As it becomes to large, shard your publications depending on type. Meteor's livequery works better serving a lot of similar subscriptions, so at some point you can have multiple server types each taking care of one scope.
all_the_things 11y ago
Can you elaborate?

ricardobeat 11y ago

This is important because development standards are a winner-takes-all game: once jQuery became the default, it enabled an explosion of plugins and components built on top of it, and every JavaScript widget became a jQuery widget. The exact same thing might very well happen with React. And that’s a very exciting thing for Meteor. Thankfully we know a bit better by now, and build modules with a small surface area that are not directly tied to frameworks or plugin APIs. So no, I'm not so excited about that happening to React.

matthewrudy 11y ago

Meteor's best trick has always been data synchronization. That was the magic trick that sold your client. They proved real-time data synchronization could be simple and seamless, and everyone else had to run to catch up. But that trick is now 4 years old, and nothing else of substance really emerged. As Ember, Angular and React grew, you were never going to want to use their odd looking front end. Their data sync also came with dubious claims to scalability, not the least is their tie to Mongo. That may be fixed now, but the consequence is being tied into Meteor Galaxy. Meteor should have thrown everything away, and become just the data layer. Like Firebase, but open source, and backend / datastore agnostic. They tried to standardise DDP, but it didn't catch on. But what the world needs is a standard like GraphQL, but handling data updates, and with automatic realtime data sync. Thatd be a wonderful legacy for Meteor. But this won't happen, as the company needs to make money from hosting.

dfischer 11y ago
GraphQL and Relay may be the answer but it's too young to make that switch now and Meteor is solving that exact problem. Meteor has the momentum and community to take it further. Maybe it actually adopts the GraphQL standard and unifies it into the ultimate dev UX experience.
- matthewrudy 11y ago
  It might happen, and the next year or so will decide its fate. Exciting!
- pacnw 11y ago
  Yeah, I went down the Relay/GraphQL rabbit hole for a good 1.5 months last year, but unfortunately there is a tremendous amount of work to set up GraphQL servers to even get your data out to Relay, and it is not real-time at the moment (although the 'community' appears to be work on it. I so wish Meteor would provide a drop-in module for just the DDP, I don't even care if its Mongo, their real-time subscription works.
huula 11y ago
Completely agree! Hope Meteor community would seriously consider this.

dham 11y ago

I strongly urge you to take a step back and really look at React community from 30,000 foot view. Please don't get on the hype train without taking a look at other solutions. Vue.js as far as libraries go, and Ember as far as framework go. I promise you, you'll have a better experience.

ocean3 11y ago
Vue.js seems like backbone. Last time i checked Ember looked way complicated. What i like about React is the simplicity. Its basically JavaScript with few React functions thrown in. As a view component its very good. I have used it in normal rails app as well.
rimantas 11y ago
As an old-school html purists I am off-put by Vue's markup. The same goes for any framework that needs invent their own attributes and tags.

devcheese 11y ago

what major production apps are build with Meteor? This might be the wrong place to ask but I figured it's worth a shot.

ollerac 11y ago
https://www.quora.com/Which-startups-use-Meteor-in-production https://www.quora.com/Which-startups-use-Meteor-in-productio...
codesuela 11y ago
https://www.meteor.com/case-studies/build-apps-with-meteor https://www.meteor.com/case-studies/build-apps-with-meteor

matthewvincent 11y ago

Seeing the Discover Meteor and Kadira guys embrace React with Meteor is definitely making me want to dive back into the framework after being very hesitant over the past few months. It's great to see ~someone~ with a clear vision for the future.

sergiotapia 11y ago

My thoughts: Meteor got popular enough that the Javascript loons started pecking at it and infesting it with the general lunacy that accompanies NPM and it's ecosystem. MDG adding easy React support was a definite win and I think using Meteor with React is -the- way to write Meteor apps. But they need to start ignoring the crazies out there and focus on their vision.

jorgecurio 11y ago
laravel is fine too

EGreg 11y ago

This all boils down to one key fact: Meteor is the only framework that controls the whole stack. After all, the fact that no other company than MDG has even tried to make it happen should be proof enough that it’s not trivial. I did it, over the last 4 years http://qbix.com/platform http://qbix.com/platform Actually our platform aims to be an entire "Wordpress for social networks". We realized that identity, security, roles, permissions, consistency and realtime updates etc. are hard to get right and building a standardized platform will free up developers to focus on what their app does instead of reinventing the wheel, etc. Not only that, but it will allow interoperating and reusability of components across all the sites. And yes, it does routing, pagination, components and more in a way that will give Angular and React a run for their money if you check it out. Also it does a lot more: http://qbix.com/platform/features http://qbix.com/platform/features PS: try loading all this on your smartphone!

faceyspacey 11y ago
yours isn't a full stack reactive platform. great work though.
strongai 11y ago
This looks fantastic! Please could you write some words aimed at potential recruits to qbix? What to expect, what not to expect. I noticed, in scanning your site quickly (... I think all content should bear the 'scanning user' in mind, but that's another topic) that php is mentioned. What php knowledge is required? What JS knowledge is required? Make it easy for people (I mean really, visitors who are pre-tutorial) to decide if they have the wherewithal for it to be worth them making a modest commitment to take it for a test drive.
- EGreg 11y ago
  You can put together a site with hardly any PHP knowledge. Just place reusable componenets on pages, or widgets that connect to ready-made backends... but then you don't really need this framework. But if you have some basic PHP knowledge, you'd create more pages, and perhaps some backend actions. As far as the PHP and JS knowledge, see http://qbix.com/platform/guide http://qbix.com/platform/guide The more PHP and JS you know, the more you can do. Unlike React and Angular, though, everything is named in a super-straightforward way, like Q.page and Q.Tool and tool.children() etc. So you just go ahead and build your site and Qbix does a ton of things for you, like dynamically swapping out css/js as you navigate pages, takes care of history and routing, activates and removes tools and their associated events, lets you subscribe to exctly the events you need, and documents conventions you should use to play nice with everything else.

all_the_things 11y ago

I gave it a try a few weeks ago but every other package was unsupported because a new package was being developed rather than following semver, the standard server logging was terrible when I had to debug a frontend dev's memory issue. Seems like the Wordpress of realtime applications. The DDP package is interesting but only helpful to supported DB's as far as I could see. I think choosing GraphQL will just narrow their 'full stack ecosystem' again. Why not provide better low level support for your community to write GraphQL Cypher, SQL and NoSQL themselves. There are some great packages I've seen for this.

jbhatab 11y ago

This is fantastic. This removes efforts to maintain a random front end view layer while legitimizing the numerous react integration attempts. This will save a lot of time moving forward to phase out blaze.

pm24601 11y ago

The problem with Meteor is not the front-end. The problem is that data exists (for the most part) in Relational DBs. This prevents Meteor from being used in any environment that needs to/wants to use a SQL db. This prevents Meteor from being used in any form, for any application that needs to access existing data in a SQL db. React does not prevent Meteor being adopted - not having SQL support is a dealbreaker. If Meteor does not confront and solve this problem nothing else matters. The only thing MDG should be doing in 2016, is SQL DB support.

dror 11y ago
It's probably too late. The work they've done with blaze is wasted since react and angular(still) are dominant. The work they've done with MongoDB is wasted since most of the world wants SQL. So what do they really bring to the table. It feels like too little too late.
mxxx 11y ago
Agreed. If anybody thinks the real problem with Meteor is that it uses an antiquated templating system they're missing the bigger picture.

shadowmint 11y ago

Why will it be any different this time compared to last time with GWT, Dojo or SproutCore? Server - client binding javascript widget frameworks are nothing new, and they have, historically, failed to be capture broad adoption because they require a very specific backend. If you had an excellent series of react components with data binding done via an open server specification and meteor just happened to be one implementation that backend; people would really dig that! ...but there would be a lot of people who didn't use meteor at all; and just wrote their own server implementation for it. “but wait, if we end up using React, Relay, and GraphQL, what do we even need Meteor for anymore?”. ... This all boils down to one key fact: Meteor is the only framework that controls the whole stack. So what? Who cares? Controlling the whole stack isn't even remotely interesting unless there's some tangible benefit from it. This is by far the weakest and least compelling part of this article. So this is my vision of the future of web development for 2016. React as a common front-end standard, and Meteor starting out as one of many possible back-end choices, but slowly becoming the one that just makes sense. You really need to try harder to explain why Meteor would be a compelling choice for people then. If the front-end component api is well defined and backend agnostic, meteor seems to offer literally no particular benefit over any other backend someone might choose.

holonio 11y ago

I think the "server-aware" components are an incredibly important point. Consider user authentication. Anyone who has written a SPA with Node (e.g. Express) and React on the frontend knows how painful it is to integrate with login services, even with something like Passport.js. The value of having React components that can deal with what happens on the server is pretty huge. Right now, most of the abstractions we build on the server and on the client are pretty disconnected because server and client frameworks operate independently of one another. That means that the abstractions we build often don't really abstract away all that much stuff. Writing an auth system or a feed, etc. every single time you start a new project is a huge pain and something Meteor is in a great position to completely eliminate.

osoti 11y ago

The stars who sizzled the Golden Globes 2015 http://goo.gl/Iz6899 http://goo.gl/Iz6899

pedalpete 11y ago

I just started with Meteor a few weeks ago, and thought it was absolutely amazing as a prototyping tool. I figured I'd be recommending it to anybody doing an MVP. I actually do believe there is a business model there, but it seems they are focused on the high-end with hosting and support starting at $500/month

dfischer 11y ago

I said more in the other thread, but I'll leave another note in this one. What I think Meteor has the most going for them is the ultimate UX experience for the developer. If they really hone in on making it enjoyable, and dare I say fun to work on product... then they've won in my book. Meteor has given me that feeling thus far, and given the new trends in the community I am sure they are moving in the right direction. I've spoken with the guys there and they are carefully reviewing what the best routes are to take that creates the best experience. Meteor is not just a vision, it's a real experience you can tap into right now that benefits a very powerful suite of tools to get up and running. We have an enterprise app built with it and it's going great. Yes, it'll bite you in the ass if you don't learn how things work (pub/sub/mergebox/reactivity) but just dive in a little and you'll see it's just a library composed of other libraries that are well documented and easy to learn. It's all really quite simple really. The beauty and evil word "magic", is how they all play well with each other. React is probably a better choice than Blaze at this point, even for the pure fact that it allows Meteor to not worry about the view and focus on the overall UX experience of the developer above all else.

tonyonodi 11y ago
I couldn't agree more, it's a god send not to have to wade through documentation and work around a hundred errors while you set everything up; before you've written any code. The freedom to iterate on new ideas quickly that a NoSQL database gives you is rather nice too (even if that's a terrible reason to choose a performance-critical part of your stack). I'm sure all this magic comes with a penalty further down the line so I'll let you know whether it was worth it when I get there...

khwhahn 11y ago

I'm sure that Angular 2 would be a better choice for a Ecosystem like Meteor. React is very nice, but annoying to find tutorials, get a decent size app going (routing etc) and Angular 2 is more mature (all the good and bad points of NG1 and other js-libs were considered). Next to Google also Microsoft is betting on Angular 2 (TypeScript). This will boost the community greatly. NG1 was slow. NG2 is amazingly fast (webworkers/server side rendering). So for a Meteor Use Case I would pick NG2. If I wanna build a simple Snippet I would use React.

lambdacomplete 11y ago

Dove into react and redux and built a couple of small apps. They are amazing not because they add some "fancy" features but because they train you to think with a different, much cleaner and simpler, mindset. Before your brain "clicks" you feel miserable. After it does you think "why on earth isn't everybody using this??" and any problem is solvable by dispatching actions and building reducers (thank you Redux!). Three days ago I spent a couple of hours on Meteor's simple-todos tutorial, trying to understand how everything was working (that is, at an abstract level). I felt great after finishing it. Two days ago I started building a service we'd like to launch within a couple of months, e-commerce like stuff. I felt miserable. Pushed the first "draft" with a customized sign up and I felt like I had no idea how to proceed. Yesterday I spent 4 more hours, started using packages like autoform, collection2, something for bootstrap, iron-router etc. and I feel FREAKING GREAT. Again my brain clicked and now I implemented ~70% of the features with validation, defensive checks on the server for security, nice-looking popups, good overall UI... I mean, I intended it to be a prototype, maybe mocking some parts but, damn, we basically already have a MVP! In 3 days (effectively ~12 hours)! And now I already know how to implement the rest, it just feels natural now. Like when you have a solid plan and you think it through in your head and you KNOW how to implement each and every step of it. You can hit a wall with Meteor as much as you can with any other framework (I mostly use Django). It's all about reading the docs, looking at what the community is doing and try to adhere to some "guidelines" (if there's no standard way of doing something). I will let you know how it scales when we reach a couple million users (bazinga!).

codesuela 11y ago
I don't know if you are aware but there is now an official guide which goes way beyond the scope of the docs. http://guide.meteor.com/ http://guide.meteor.com/
- lambdacomplete 11y ago
  Yes I'm already reading that. Thanks for the hint!

oliv__ 11y ago

I've been using Meteor for little over a year now and to me, the real selling point for Meteor was the insane speed, productivity, and almost instant gratification that results from that speed: all of a sudden you went from having to configure a million different moving parts to just coding, almost forgetting that you are coding in the process, enjoying yourself, and suddenly seeing your features pop out of nowhere. It's quite magical. For someone like me (I'm more of a designer who can code than the opposite), the reactivity, feedback and interaction with your code make the whole process feel much more "hands on", almost like sculpture, in the sense that you are able to poke things and see them react instantly. And that makes all the difference. Yes, many problems do appear once you dive deeper, but I've never used another tool that brought me closer to my ideas than Meteor. And in the end, that is for me the single biggest achievement here.

neximo4 11y ago

Meteor started off so brilliantly. I wish the team would focus and just make it great. Many people would complain about SQL and what not but the truth is there's a very large number of people who are quite happy with MongoDB and the fast experience building an app. However there are some really big issues that seem to be ignored: 1) It's nice that its backwards compatible but some essential features are missing such as a router. Iron Router is available but it's practically abandoned. You can't even have URL's such as /2 on it. It makes it hard to keep an app for the long run knowing there is a risk of an essential component about to be abandoned. Other similar projects include Meteoric (an Ionic wrapper) 2) I wish they'd focus on making Blaze work. It works. Many people don't like react and just want an App build on V1 to work with V1.5 and V2. The lack of clarity is harmful to the use of Meteor in The Enterprise. 3) The build time. It used to be that Meteor built a project near instantly when a file was changed and hot code changed the page. Now it takes a good 20 or so seconds for a simple line change. It seems over the top. 4) Clarity and focus on direction. They spent ages pushing people to their Npm system, now they're going back. Why not start with node_modules/complete npm support instead of flipping back and forth. The volatile state of affairs with Blaze, Npm and the general structure of an app manifests risk in choosing Meteor for an actual Enteprise grade app. 5) A focus on improving what already works well over adding new features and degrading the performance of existing features. I mentioned the build time, but other parts of Meteor such as Cordova, Blaze, Tracker, Mongo (Meteor uses MongoDb 2.6?!) would certainly help more. I'm not sure what's happened but it seems a lot like the team is losing focus of what people actually like about the project.

raffomania 11y ago
I especially agree with 3). I was expecting more people to mention this. Compared with other build systems like wepback or gulp, meteor rebuild times are insane. edit: Just checked out the Meteor Roadmap, and build times are not even mentioned there.
- neximo4 11y ago
  It used to be. The current implementation is the result of the effort in speeding it up.

ryannevius 11y ago

Only semi-related...but why do you think Mithril is always so easily dismissed? I kind of get it: huge companies are working on and adopting React. But after using Mithril, I just can't figure out why it has failed to catch the attention of more people.

raffomania 11y ago
I remember that I found the documentation quite hard to read at the time I was checking it out.
brlewis 11y ago
Mithril succeeded in catching my attention because creating a good mobile web experience is important to me. This does not necessarily explain why it has failed to catch the attention of others, but might be a clue.
deleted 11y ago
[deleted]

malloryerik 11y ago

Can anyone here compare Meteor with a full Clojure(Script) stack?

oelmekki 11y ago

Mootools is not an ancestor of jQuery, it actually was released after jQuery (by a few days). From what I recall, the success of jQuery was not because it allowed to do more things. It was mainly because developers by then considered javascript as a lower citizen language and wanted to do frontend stuff without having to learn javascript - and jQuery allowed just that. For (the few) javascript lovers, jQuery main advantage was to be a big decorator, not extending any native, which guaranteed there will be no conflict with other libraries when adding jQuery in a page (quite ironic, when you see how all libraries expect jQuery may be present in the page, nowadays).