What Meteor is to me

1

There’s been a lot of discussion lately about why Meteor exists, what it does, what it should be, etc. I wanted to clarify what Meteor means to me: It makes my job easier

Meteor makes building custom web apps much easier and faster. I started messing around with latest Webpack builds with React lately, and I forgot how much of a pain JavaScript development really is. I don’t consider myself a JavaScript “developer” – more of an “implementer”. I can get around with Meteor quite easily, and am quite lost with some of the purist JavaScript stuff.

What I like:

  • Auto-include all files
  • DDP (obviously)
  • Not having to do exports (Globals)
  • EcmaScript in Meteor
  • React support

A lot of the complainers complain about not being able to include files, globals, etc. – which I think are all of the reasons to like it. It’s just easier and quicker to get an app out the door. As I said, I’m not a true JavaScript “programmer”, and Meteor may absolutely fail me if I was. In that situation, just don’t use Meteor, because it’s not for you. You are not their market, and you don’t benefit from the items that many others benefit from.

Where does Meteor fail?

Meteor fails me if there is something I have to jump hoops through in order to get working, and costs me time. Specifically, if it doesn’t speed up my development time or make my life easier. Right now for me, this includes:

  • Process of adding NPM packages
  • Build time
  • No component “hot” reload
  • No code splitting
  • Packages on Atmosphere that don’t work or are no longer maintained
  • Can’t easily use third-party React components

I don’t complain about these because they are cool to have or are the latest and greatest. I complain because each of these specific things makes my life easier as a developer and speeds up my development process. I am aware that MDG is working on all of these items, and I can’t wait to see what they have in store.

I think the core vision of Meteor is super-strong, as as long as they keep their focus on making my life easier as a developer, and speeding up my development process, it’s here to stay. Please don’t change either of these visions as your mission by trying to appease the nay-sayers and becoming more “mainstream”. In my eyes, that is when Meteor is no longer relevant to me, when it’s just like everything else.

6 Likes
2

Great post! Thanks for the clear thoughts around this topic.

I personally think there are ways that Meteor could become more “mainstream” without losing some of the core features around ease of use and development speed. I think there can be a sweet spot there. For example, the use of ES2015 modules will really help here.

3

Thanks! I agree – some others had good thoughts on convention over configuration, and I completely agree. There are probably quite a few areas where this can be applied, while still keeping the configuration to a minimum (opt-in to config).

4

I wholeheartedly agree with the sentiment. Meteor takes care of so much stuff that I just don’t want to deal with. My pain points are shorter though:

  • No SSR
  • No progressive loading

IMO Meteor should work towards SSR the first page and progressively load the rest of the app. This is what pretty much every other framework is working on or already has.

2 Likes
5

You just named all the benefits of using webpack

6

I did. There needs to be an abstraction layer though, and that’s where I see Meteor. Make’s it easier. Way easier.

1 Like
7

I would add no support for Sql databases as fail.