The future of Meteor

core
41

There are some really great responses here. I guess i’ll chip into the conversation.

First off, I’m a big fan of the platform and don’t plan on straying away from it. There is room for improvement though.

Meteor has done a great job (and is still doing a great job) of innovating. If you notice things like Facebook’s Relay… it’s basically the same architecture as the Meteor platform (which in a high level view, hasn’t really changed). I don’t see the innovation stopping anytime soon, but I do see some issues that should be addressed.

Pull Requests & Community Contributions

I feel as though there isn’t enough emphasis put onto community-based contributions to Meteor core. Granted, MDG probably would like to do things their way, but there are people out there in the community that are trying to help build the platform and fix issues, but are not getting merged in or looked at often enough. There are over 80 PRs open and that’s too much in my opinion. This was an issue that Node.js had initially and as it grew with more and more pull requests, that spawned the divergence of it with io.js. I do not want that for Meteor.

This also brings up the concern of release cycles. Granted, I see why Meteor 1.2 is taking awhile especially with the development of Galaxy going alongside it. But, I would like to see more often releases. If releases occur more often, it allows for the people from the community that are contributing to core to potentially get faster feedback and motivate them to do more. And going back to the open PR matter, having those PRs responded to and merged in as quickly as possible can be a moral boost for those making the PRs and motivate them more.

Also, the community as a whole (including myself) should try to help improve the platform and packages more and not just wrapper packages for other libraries. Waiting on MDG isn’t always the best solution. There are various community packages that have created features that allow MDG to focus on more core components.

Question for MDG regarding this:

  • What is causing some of these PRs to be open for months and some for more than a year (may not be relevant anymore, but still)? Is it due to a lack of resources in-house?

Meteor in Enterprise

What i’ve come to realize is that when it comes to an enterprise solution, there is no single stack that can really solve ALL problems at a large organization. Meteor fits in very well with other pieces of technology and I would say that when it comes to other tech that isn’t officially integrated or packages up nicely like a messaging queue, it is probably the same amount or less work to get that integrated with Meteor as it would be with just about any other stack.

The single biggest piece of technology that I see large enterprises integrating quickly would be DDP. There should definitely be more emphasis put on it since there are more and more real-time applications developing with WebSockets. DDP is awesome and even when I have talked to people in larger companies, that was by far the easiest thing to sell them on (not sure if they have used it yet). Which could easily be the first step to fully adopting Meteor as a portion of their entire tech stack.

I would love to see Meteor get adopted more in large companies, but there has to be one that needs to adopt it first and spread the word and it should get others to jump on. Maybe MDG could partner up with someone to get this ball rolling? Not sure what that would entail, but just throwing out a suggestion.

MDG Community Involvement

They are doing a great job of helping organize meetups, talks, and of course, the devshops. Keep that up and going. But, what I would like to see is some sort of large Meteor conference. All newer and big technology grows by a large factor after conferences. I think Meteor is mature enough at this point to host a conference for it. There are frameworks that held conferences at an “early age” like EmberJS.

For things like Galaxy where the development behind it is not open source, I think it would be good to show a little more transparency. While Galaxy has been in development, there wasn’t too much posted about it compared to how long it has been under development and even little tweets here and there would be big to get people on the tip of their toes for the public release. It would probably help with marketing.

Also, can we please be able to contribute to Atmosphere? Even if only a portion of it is open source, I think that would be awesome.

Final Thoughts

I see a bright future for Meteor. It is BY FAR my favorite platform to develop in and I get things done much much faster in it than anything else. There may be bumps along the way, but together as a community, we can make it great.

9 Likes
42

Agree. My Meteor stack looks the same now.

43

Short answer: dependency management

Meteor manages NPM’s dependency shortcomings using mechanisms like the shrink wrap, and also does some magic around making sure the packages work across platforms.

NPM is not excluded, it’s just used as a package repository and Meteor acts as the dependency manager using things like the constraint resolver.

I do understand your viewpoint, I’m just not sure it’s the best approach for the goal of being the JS app framework. Over time i can only expect Meteor to become more loosely coupled and configurable.

1 Like
44

I think Meteor has a very good package Manager. I know MDG has invested a lot to make a such a good package manager. It’s far more effective than NPM is few ways.

  1. Single Version Always - Must for client side apps
  2. Strict Semvar Focus - All(or most) the packages are based on semvar. It’s a rule.
  3. Single package has both client and server parts - This is because of the beauty of Meteor

By all of these, I think Meteor always wanted to build it’s on package manager (and a hosted solution) they’ve control. I think that’s another good case for a separate package manager. It has a great value.

But we need to have proper access to NPM and we’ve it. In the later version, it’ll get better.

2 Likes
45

Why do you think so?

46

I don’t really understand all this hype on React. ERb in the Rails world is not that different from Blaze, and Blaze has reactivity on its side. React is good but only in cases when you need to encapsulate specific components. Blaze is much more easy to learn and use and it’s perfect for 80% of you application need.

Meteor architecture in general is a step ahead in terms of clarity. Did you take a look at Rails Action Cable? it’s really complicated compared to meteor WebSocket encapsulation.

But on its side Rails had applications like Twitter and Github since the beginning. That’s the point.

A second advantage that Rails had was Jason and DHH always onstage making storytelling of 37signals. The first success case adopting Rails was Basecamp, and that helped a lot. Being a platform only company is much more complicated, but it’s ok if your target customer is the big enterprise. Is that the case for Meteor? Maybe not, the framework is not ready for the enterprise. So, in summary, the only viable target customer for Meteor right now is startups and SMB. And that’s why evangelism and awesome documentation are foundamental. In the enterprise market case openness and support are key factors. Those 2 paths have completely different go to market strategy.

3 Likes
47

How is prevent from using atmosphere packages a good thing??

48

@massimosgrelli, personally I choose React because of server-side rendering feature. It makes websites really fast. Also React is more solid and mature and forces you to write straightforward logic for UI. I see Blaze as a talented teenager and React as a mature person who have seen a lot and have got more life experience.

@arunoda, you quoted the wrong person) and you convinced me that special package manager is not a bad idea. What we need is a smoother integration with npm like: “add package.json and then use via import” (which is achievable now but with hacks). Also I think, that Meteor packages have to stop polluting global namespace.

49

On topic of meteor packages: I’m firmly in favour of dumping them and using plain old NPM. Why? Maintenance.

Example: I’d like to use moment-timezone in my project. Packages on atmosphere wrap version 0.2.1, over a year old now. And depend on mrt:moment, an abandoned package.

People need something form NPM, and build a Meteor package. Maybe keep it up to date for a bit. That particular project ends, along with their necessity for that package, and that’s that. Important update comes out? A security vulnerability gets patched? Well, I hope you like re-writing parts of your app to use another package. Meteor is relatively tiny compared to greater node / js ecosystem, and just a small amount of libraries maintain official meteor packages (shout out to momentjs:moment for doing that). And that greater ecosystem has settled on NPM - I think we as developers using meteor would benefit greatly from being able to just use the standard.

It’s not even a meteor-specific problem. Bulk of my web development experience comes from Rails land, and the same problem was encountered there. Front-end javascript libraries would get re-packaged by third parties into ruby gems, maintained for a bit, then abandoned. Heck, I’m guilty of that myself. The problem spawned projects like https://rails-assets.org/ that automatically re-package canonical sources into ruby gems, and ways to bridge Rails asset management with that of NPM (https://github.com/browserify-rails/browserify-rails).

It’s fine for most of the small projects, where you have one feature to implement, one developer working on it, done in under a month and forget about both the project and the client. But once you start working with more people, on bigger projects and have to actually maintain the code you wrote… the same wonderful tools that allow a complete newbie crank out one TodoMVC app after another become a liability.

Yes, NPM isn’t perfect. But it has popularity on its side. I’d like to see MDG adapt NPM and work with the maintainers thereof to make it better, rather than strike out and build their own walled garden.

4 Likes
50

Why don’t you load moment-timezone in your meteor project using NPM? No one’s stopping you from doing that.

4 Likes
51

How does CouchDB do replication and communication between multiple databases, including the in-browser PouchDB - without DDP nor WebSockets and sticky sessions?

52

I do that. Via meteorhacks:npm for server, and cosmos:browserify for client. I’d like there to be less hoops to jump through to get the same effect. Like a package.json in project root, and a require function that does node.js require serverside, and browserify / webpack / whatever is best based approach on the client.

1 Like
53

Because 80% of the package on Atmosphere has been focused on reinventing the wheel for Blaze. By using React, you can take advantage of all the React community (it’s like being open to the world instead of never leaving your country, but still having my awesome canadian health-care when I need it). All you really need are Meteor packages/features that are really useful like DDP, optimistic updates, account management… Meteor can finally focus on what it is really useful for.

And in all honesty if you REALLY need a Blaze template, you don’t need a React version. You can use the BlazeToReact package. But let’s be honest, once you have enough experience with React, Blaze stinks SERIOUSLY. Saying it is easier than React is pure bullshit. You still need to learn it and Meteor doesn’t need to make you learn something nobody else is using.

2 Likes
54

Oh! didn’t notice that.

Anyway, I think that’s the plan after 1.2

55

Well, Meteor is on the right direction then (in my vision of “right”)

56

I don’t know what projects you guys are programming, but I like the “easy way” of using Meteor. Create a project - install all plugins you need - deploy on multiple servers with having a working cluster. If needed, I can simply write a mobile app in Meteor and connect it via DDP to my main Meteor application. So I can reach all user devices with one framework and have an easy maintainable code.

At this moment I would appreciate it if MDG could more focus on mobile development, because using Cordova at this time is a very bad experience (f.e. bugs like having no access to the file system of a device).

Just a question by the way: What are the big advantages of ReactJS, compared to Blaze? I’m just wondering because everyone hypes React. Is there only a speed issue or is there any “real case scenario” where Blaze wouldn’t work at?

1 Like
57

Agreed. After 5 minutes with React, it’s easier than Blaze, and includes a lot more real-life code/tutorials/code samples. The biggest downfall of atmosphere for me right now is that most packages work seamlessly with blaze, but not with angular/react. And meteorhacks/npm doesn’t seem to be an elegant solution for implementing npm packages into meteor – I think we need official npm support for this, so just as now we can choose blaze/angular/react, we can also choose between atmosphere/npm.

58

Meteor has a monolithic history & OOP purists aren’t using JavaScript.

59

You and I have very different ideas of the ‘Beginning of Rails’ :slight_smile: As a guy with a Github user id of 101, I can assure it hasn’t been there since the start.

2 Likes
60

I mean just few years later:

  • Rails was released in Aug 2004
  • Twitter in 2006
  • Crunchbase 2007
  • Github in 2008 (they started coding in Oct 2007) and in 2008 they where onstage at the Railsconf in Portland - I was there and I have their “fork you” t-shirt :smile:
  • Shopify in 2008

They seem a lot to me.