The future of Meteor

core
21

There are two separate things being discussed here, as @deanius says, “Technology” and “Governance” (AKA MDG’s relationship to the community).

Technology

The original post was, to paraphrase, “now that more solutions exist for some of the problems that Meteor solves, do we still need Meteor?”.

I like @joshowens’ answer to that one:

This is exactly why I use Meteor, and it’s no less true than it was 2 years ago. MDG has described their goal as being to package the best JS technologies together in a way that makes it easy to use for developers, and this will continue to add value for as long as they continue to do a good job with it.

I want to build apps as quickly as possible. I also like to explore new tools and I won’t be satisfied if I’m not using the best tools, but at the end of the day I send invoices to clients and more than ever in my career I see the value of building good things quickly. Does webpack help the average Meteor developer here? I want more than a hammer in my toolbox, but I don’t want to have to build the whole workshop myself. This is the value that Ubuntu provides over compiling your own Linux kernel and gnu tools.

I think MDG is way ahead of the curve on making a cohesive package of the best JS tools, and the proof is that most Meteor developers will be using (most of) ES2015 before the end of this year. Compare that to the average.

If I thought webpack provided some huge benefit I’d be figuring out what it would take to refactor Meteor to use it, and either submit a PR or organize a community project to do so if it’s too big for me.

Governance

The second discussion is about the Meteor community, and whether MDG is “listening to the community". One of the things that MDG has done better than any other open-source project that I’ve ever seen is organize community. Sure it took a while to move to Discourse, but here we are. :slight_smile:

They brought us all together, but now that we’re here they can’t please all of us all the time. They can’t maintain clear focus and also take everyone’s input (and PRs), even if they had the time. But also you can’t rule an open-source project with an iron fist and MDG knows that. I hope they continue to value the early and largest supporters like @arunoda / Kadira etc.

But most importantly, Meteor is an open source project, and that means you can do what you want with it. The fork discussion is inevitable in any large open-source project, and isn’t necessarily a bad thing. It helped Node and Rails too (OK Merb wasn’t a technical fork, but it was a division of the community that came back together for the benefit of all).

Don’t sit back and complain about the direction of the boat. Help steer.

14 Likes
22

To sum it up I’d say:

  1. If you’re not sure if Meteor adds value or is better than something else then go ahead and put all your favorite components together yourself. If you enjoy that then you don’t need Meteor.
  2. If you’re a passionate community member then great! Don’t forget this is an open source source project and an open community. Keep showing up in places where people get excited and actually build things like http://meteorspace.camp/ (I’ll see you there) and this forum. :smile:
3 Likes
23

I love Meteor. I love the community. But from day one with using Meteor I felt segregated from the rest of the dev world (not completely but enough that it felt like I was in a cult at times LOL). The stack was so complete and made me think I did not need anything more. That was the good part of it… that was the bad part of it too. Now we are closer/obtained multiple databases, multiple front ends, multiple hosts that fully support it… Meteor is becoming the platform I wanted :smile: .

One thing I keep reminding myself is how ambitious the Meteor project is… and I like that! Who comes out of the gate with a whole platform… MDG does :clap: . That takes some guts to do. Now that the community is maturing it inevitably wants to pull Meteor into all sorts of directions, to fit their needs, which are different from my needs probably.

That is where it gets interesting… remember Meteor is very ambitious. In a lot of ways it is “everything you need”. So how does MDG and the Community work together to grow this “everything” platform? Since it does so much it needs a guiding hand to make sure it does not become a massive pile.

On one hand we can break Meteor up into smaller and small tradable pieces, each very independent of each other. But with that we could lose the other hand… Meteor’s “everything” and “ease”, which is their USP (unique selling proposition) of the platform. With out a USP a for-profit company is doomed. Would MDG even need to exist if everything was a bunch of small packages put together using NPM and a independent build tool? I for one want MDG to stay, but also want to have all the freedoms the rest of the web dev community enjoys… so here I lay and wait with a slice of pizza in hand… excited for what is to come.

6 Likes
24

Definitely. This is what brought me to Meteor in the first place.

New stuff like React and Angular are great, but they’re not a great starting point for the average developer you refer to. In order to understand those tools (not just how to use them, but their significance) you have to have a fair amount of development experience. Folks at MDG and in this forum may be at that level, but most are not.

It seems shortsighted to cast off developers at this beginner level just because there are newer tools to play with. Instead, that crowd should be embraced and Meteor should be their starting point. I’m not suggesting that tools like React and Angular shouldn’t be supported, but perhaps tools like Blaze should be put on a higher pedestal for what they can help the less-experienced to accomplish. It’s quite beautiful in itself and it’s a shame to see something like Blaze being pushed aside instead of improved/expanded/promoted.

8 Likes
25

Exactly! The lack of conversation around this soon-to-be issue is alarming.

2 Likes
26

I agree. It’s getting hard to write packages that support multiple routers and multiple frameworks. I’m a big fan of being opinionated and sticking with a single stack. Rails is one of the most successful open source projects of all time and it couldn’t have been what it was without being opinionated and alienating a lot of people for whom it wasn’t the right fit.

People who wanted more freedom went elsewhere, and those that remained had a stronger community and were also more easily able to extend the framework and push it forward faster because it was one single stack.

7 Likes
27

Every time I hear reference to MDG money has raised as a proof of the viability of their technology I cringe a bit.

Rails succeeded b/c it was purpose-built to solve real problems for its developer(s) in an app the world could kick the tires on. Then those solutions were adopted and adapted by other developers, who could move forward secure in the knowledge that at least they were not tilting at windmills by choosing this newfangled framework.

I think it’s a considerable problem that Meteor lacks a showcase app. The closest thing might be Telescope, the best-known example of which is crater.io, which as I write this won’t even load. (And when it does load, it looks and performs like crap if you’re on a mobile device.)

Kadira is of course another example and a very different one, but it’s a bit more meta as it’s an app for Meteor apps. But now that I mention it @arunoda is doing way more to follow the Rails example than MDG. Kadira builds things in support of their production apps, shares them with the community, and that has a lot to do with why they get widely adopted.

9 Likes
28

I think this is a legitimate concerns but dead wrong. After building a pretty large application with Meteor / React, literally 90% of my code is uniquely React. I only have a few Meteor packages (mainly the ReactMeteorData mixin) but most of my stuff comes from the React community. I don’t need all the packages that are designed for Blaze because other stuff has been designed to work better with React. I am guessing Angular is similar.

Giving flexibility to what the user want to use is not a bad thing as long as their is a default simple way to do things. I personally love Meteor but I am absolutely disgusted by two things: Blaze (urg) and the build system (hi global variables and uncontrolled file order).

The first has been fixed by giving us the choice between Blaze, React and Angular. It is a good thing and it makes most of the package on Atmosphere useless if you are not using Blaze. The second problem has not been solved yet. I’ve started experimenting on using Webpack as my build system and droping it into Meteor (it works great btw, hot reload would not be possible otherwise).

I think Meteor should stick to the isobuild but give you the choice to custimize your own build with webpack, grunt or gulp. In a large application, everyone has their own custom build need. I am looking into how we can incorporate that into Meteor and the isobuild but there is a lot of work to do.

1 Like
29

Rails succeeded b/c it was purpose-built to solve real problems for its developer(s) in an app the world could kick the tires on.

No. It succeeded because some smart people built some awesome stuff with it - and a Ruby community that was extremely active and stood out (why’s poignant guide, Railcasts from Ryan Bates). Rails made Ruby more popular. The documentation became more awesome after the merge with Merb (which had big advantages in routing) and the framework became more component based. Same thing is happening now with Meteor (Crater.io, Discover Meteor, Starrynight, Flow-Router, Kadira, SimpleSchema, React and Blaze). Meteor doesn’t need a scaffolding RAD demonstration. If you can’t see the win in DDP, latency compensation and the stack - you haven’t been hurting too much.

New stuff like React and Angular are great, but they’re not a great starting point for the average developer…

Average developers always have a steep learning curve when learning new things. That is what gaining experience is all about. It’s hard and it takes a lot of boars and dungeons - hence the manual of World of Warcraft.

I love Meteor. I love the community. But from day one with using Meteor I felt segregated from the rest of the dev world

Imagine how guys devoting their life in Python must feel. Good frameworks are like good friends. Some are your best friends, some just bring the beer or like your holiday picture.

Everything is geared towards making a todo app with as little code as possible, not how to make a maintainable app.

Meteor is a framework.

Meteor doesn’t design an enterprise solution.
Meteor doesn’t manage your project and do scrum meetings (however, you can build an excellent scrum tool with it) Meteor doesn’t control versions or manage them
Meteor is not the little paperclip from Word '97. It doesn’t give magical answers (actually, the paperclip didn’t either)
Meteor isn’t an entire infrastructure that magically pops out a box. It’s a stack, that has all that is needed nicely contained.

What I’m really frightened is to see the Meteor community split.

If diversity is such a bad thing, we would never get out of the middle ages. The basics of A/B testing eventually Darwinizes. Words like deprecated are there for a reason. Change is inevitable - thus says the (Agile) Lord.

We’ll have package that will work with sql+react+flow, some other with mongo+angular+iron, and so on.

Isn’t it great that inside .meteor there is this fancy file called packages? It is like the designers intended to be flexible! If you want less change, there is… errr… heh, all web frameworks evolve, don’t they?

I’ll just be honest, I write about the things that I use. Coffeescript is pretty much dead and I see no reason for it to hang around with ES2015 being out now with easy things like Babel to help get it working everywhere now.

I hate you @joshowens. Partly because you’re right. Partly because I agree. And the rest is because I’ve some .litcoffee and fancy indents.

I’ve yet have to see a tutorial that combines let’s say jade, coffeescript, blaze/flow components, collection2/astronomy + whatever you can think of, to show people how it really looks like and what’s possible when all of these is mixed together.

On demand.

$ meteor create jcbfs-tutorial
$ cd jcbfs-tutorial
$ meteor add coffeescript kadira:flow-router mquandalle:jade aldeed:simple-schema
$ rm *.js
$ touch helloworld.coffee; touch helloworld.jade; touch routes.coffee
$ mkdir -p lib/collections ; touch lib/collections/myschema.coffee
$ # now read the full api documentation from begin to end
$ # read the first page on the blaze home page
$ # learn a bit coffeescript (set tab on two spaces)
$ # do some jade
$ # check github on flow-router and simple-schema (two minutes)
$ # think of an incredible app to make
$ # download webstorm or Atom (if you are really cool like me)
$ meteor remove autopublish insecure
$ meteor

The deeper that I get into anything the more I end up not liking and finding huge faults with open source projects which are primarily backed by for-profit companies …-snip-… with which many people who should not be coding got into coding.

I have made ‘solutions’ with commercial software worth millions and discovered (and probably made) things that are criteria enough to burn in hell for eternity. As we learn from Sir Paul McCartney - live and let die. The idea of open source is copyleft - the freedom to improve. If Nintendo did that, we would’ve had Kaizo Mario videos long ago.

Let’s meditate.

12 Likes
30

Here are my 2 Liras.

Just like any other startup, the MDG are a startup. Whilst I haven’t seen their exact vision statement, this section of Geoff’s recent talk says it all to me:

@38:39

"We are trying to build a complete Javascript application platform focussed entirely around developer experience".

Does Meteor achieve the above statement? Yes - that’s probably why most of us are here, because we like the experience the Meteor gives us. Have they made the best choices throughout the journey? Nope! Will they make the right choices going forward? Not always.

As the founder of 4 startups (2 failures, 1 success and 1 still going), I understand that a startup is “a human institution designed to create a new product or service under conditions of extreme uncertainty”. It’s very challenging to detect the right signals from the market, and to decipher which signal matters the most to respond to. With the luxury of 20/20 hindsight vision, it’s easy for us to look back and say “this should have been done this way” and “that was a mistake”. We will all have opinions about how they should do it.

The decision to use npm vs packages (which wrap npm) means that when you add a Meteor package, it will fit right into your Meteor app (Assuming the package is written well!). If you are to just to use a generic npm package, it does not contain the extra parts to let Meteor know which files to copy where etc. I personally think Meteor packages are a great idea, just like Ruby Gems and like .Net NuGet. There is definitely room for improvement here, like being able to just use npm packages in the app (currently possible with meteorhacks npm package).

Webpack is a great new technology. With some work, Meteor can surely use it instead of the new build plugin architecture (which I’m not at all a fan of, for the record). Will this improve the developer experience at the app coding level? I don’t think so. When I’m coding my app, I’m focused on my functionality and not the bundling aspect. However, when I’m doing some complex custom deployments, my answer changes significantly, and as a Velocity core dev, my answer changes even more! So I second @benoitt’s point that isobuild should stay but it needs a LOT of attention.

Before I discovered Meteor, I did something similar to what you’re suggesting. I used Express + Socket.io + Backbone + Handlebars + jQuery + passport + nameless other packages and then I found myself wiring data binding, configuring security and countless other things. The picture below is the best description of my experience:

The “small details” are what differentiate Meteor and make it a complete application framework which has that nice experience. Using Meteor packages makes sure your apps can integrate nicely within Meteor. The isobuild is intrinsic to making this happen.

Personally these questions don’t bother me, what does bother me is that the MDG is not working as closely with the community as they should be.

There is a strong community that works extremely well together and kudos to the MDG for helping that happen, but we are lacking direct involvement from the MDG. This was a little better in the early days but has declined massively recently.

Also, the MDG are very illusive, particularly around the following red-hot topics:

  • Routing
  • Testing
  • Galaxy

Meteor is open-source project that doesn’t really have trade secrets - every line of code committed every day is publicly visible. There is even a public hackpad from which some design decisions are made. Whilst I understand that a good amount of discretion is necessary, I think there’s massive lack of openness.

As someone building a startup with Meteor and as a Velocity team member, the lack of openness and lack of direct community involvement are what bother me the most.

Still, I love Meteor. Yay Meteor!

24 Likes
31

Did Rails dictate which database must be used? Being opinionated is fine for just about everything except the database and especially when the database of choice is claimed by some to be losing data.

32

Sure. It dictated SQL, by virtue of it’s ActiveRecord driver; and was/is pretty much a non-starter for those folks needing a document-oriented database. And the database they chose (SQL) is considered by many to not cluster or horizontally scale well. CAP theorem, and all that.

Meteor started as a NoSQL stack, and wound up being more performant in many areas. People can want their cake and to eat it to; but at the end of the day, being opinionated about the database is a perfectly valid stance. Many of us are perfectly happy with Mongo.

8 Likes
33

My only contribution here that improves the conversation and is kind and constructive is and thought is…

Those Microsoft TypeScript guys seem really really smart now, don’t they… :wink:

This e.g. Meteor is like doing something/anything ambitious - rover to Mars, clean sheet F1 race car, Bernie Sanders mailing address updated to White House, every aspect can’t be overlooked for the greater holistic performance and experience benefits that can be gained from every bit of the whole system. And 1 dev in their underwear vs. 100 devs distributed around working on same ENTERPRISE-GRADE applications (in their respective underwears) and having a truly maintainable app on a legendary platform will be a huge achievement.

Down with .net, Down with .java

LONG LIVE METEOR.

3 Likes
34

Rails did not exactly rewrite the history of the enterprise regardless of how big it got either. Meteor can.

My clients and businesses I am engaged with are actually drawn in by the promise of NOSQL - and I as a developer that needs as much guidance (opinionated approach) as possible to attain what a @joshowens can achieve in time savings, for me is because I need to be kept inside some guard rails (phun intended).

Ultimately, BECAUSE of the Enterprise (capital E) focus - there will have to be OTB db support and flexibility, but SAP or Oracle do care about NOSQL as much as anyone, and Meteor will play nice with SQL ultimately. I pray it opinionates just exactly I can shovel in old SQL calls, and that is the END OF LIFE for me and SQL. It could easily just be driver connectors, it should not be sucking resource cycles to figure out though, as it will only matter in a very legacy manner.

In memory everything will (has) change (d) everything, and ideas of even “relational” being the hallmark or bellweather for the Enterprise is hardly a thing to be concerned with in the new new new next future state of BI (for example) in the Enterprise. In memory Hana is etc.

There was a ton of relational data in the Enterprise, in ERPs that did not need to be - it just was what was the thing, and there in place, and the place to shove a bunch of data that never benefited from structure or not.

Document based is not going away, and the more opinionated Meteor can be about it all – the greater the performance gains to be achieved.

Viva NOSQL Meteor.

1 Like
35

I find that quite intriguing and a good thing to know, especially because you and others are using it in one of the most sensitive record keeping areas. While you and your community are saying that it’s good enough, there is that other discussion where someone is pulling it out of his development stack. Hopefully it’s not a case of “fine if you are using it to track my health but do not dare use it to track my money”.? :wink:

1 Like
36

I think MDG should consider an “application framework” including visual components, like the one here, which I used before.
There its enough to create a single class, to have a running application.
A class represents a database table, a property is a field.
Everything else is created by the app including menu, form, grid, and user access rights.
So create a class->run app->change visual appearance of the form/grid at runtime using drag/drop, create reports with reportdesigner or edit user rights in admin panel.

1 Like
37

You asked a serious question. There are iron, flow, and react routers. Each has its own packages to work.

About Blaze and React I believe that both can be merged into one.because React components can be integrated into Blaze template smoothly. Since Blaze is not suitable for large app programming react can be an assistance.

1 Like
38

Well put, Sam! You really have a great response.

3 Likes
39

Good points, Sam. But there are some things I disagree:

Why don’t you think of NPM as a great idea? Meteor in JavaScript world is like Ruby on Rails in Ruby world. Ruby has Gems. JavaScript has NPM.

[quote=“sam, post:30, topic:9762”]The decision to use npm vs packages (which wrap npm) means that when you add a Meteor package, it will fit right into your Meteor app
[/quote]

NPM packages are not supposed to be generic. Think of NPM as a place where all JavaScript stuff lives. You can write NPM package which will work only for Meteor and only Meteor developers will use it. There is nothing wrong about this approach. People already do things this way. There are NPM packages which are ExpressJS-specific. There are NPM packages which are React-specific. There could be packages which are Meteor-specific.

It would be just easier to have all JS-packages in one place.

Meteor installation could look like this:

npm init
npm install meteor-cli meteor-server meteor-blaze meteor-webpack meteor-mongo meteor-accounts kadira-flow-router check

Or if you are a newbie you can:

npm init
npm install meteor-quick-start

Which will install all default packages and default webpack config.

8 Likes
40

I must be considered as a person who is not pretty happy with Meteor. But instead I’m very am.

I like the way Meteor radically simplifies development. Install meteor => add some files => website is ready. No mandatory configuration. Just easy-to-use API and some rules about file load order. Need coffeescript? meteor add coffeescript. Need routing? meteor add <some-route-package>. It’s so easy!

I liked this simplicity for the first time. But as I write more complex applications, the more control I would like to have.

Now I use this stack of technologies:

Meteor + Webpack + ES6 modules + React + some meteor packages + some npm packages

It’s a pretty complex for newbies, but it keeps my code more clean and straightforward.

Seems like all I need from Meteor now is a meteor-server + reactive Mongo + accounts system.

Meteor is very great for quick start and newbies, but it becomes hard when you write big applications and integrate non-meteor-specific technologies (like webpack, es6 modules, etc.). All present solutions (npm integration, webpack as a build tool, hot-code-pushes for react) are a little bit hacky.

For now I see that there is meteor-world and all-rest-javascript-world. I just want meteor to be the part of that all-rest-javascript-world.

8 Likes