Takeaways from the first ever Meteor Space Camp unconference.

Meteor’s first unconference took place this last weekend. Tucked back in a cabin nestled atop the Smoky Mountains, 50 Javascript developers met to talk about community, share thoughts on technology, and eat just ridiculous portions of food. Katie Reed, a developer at Namely, wrote a great summary of the event.

Here are my key takeaways from Space Camp.

The Meteor Build tool leaves a lot of be desired.

My sad place used to be when I was working on a app and making changes to a .jsx file (because React) and waiting upwards of 10 seconds for Meteor to rebuild. 10 Seconds! My sentiments were shared this past weekend, and it was good to know that my sad place was populated by friends.

“But hope is not lost!” I shouted atop the a dinner table as I raised my dinner fork defiantely above my head, surrounded by cheers of praise from my fellow meteorites. “We can use webpack!”.

The crowd roared. At least that’s how I remember it.

Seriously though, thanks to this awesome project started by Andy Edwards, I’ve been using webpack with Meteor and bypassing Meteor’s built-in build tool for a variety of reasons. I demonstrated my implementation of it at Space Camp, and hand’s down the most talked about part of the presentation was when I demoed webpack’s Hot Module Replacement. HMR works to drastically decrease the amount of time it takes for DOM updates to render, and it does so without a page refresh (which means it saves your state!). If you, too, have felt this pain, feel free to read about how Hot Module Replacement works.

Sad place: population zero.

Of course, there are issues with Meteor’s build tool, and other benefits of using webpack. Just recently David Greenspan of MDG recently wrote his thoughts about how Meteor could take advantage of webpack or a webpack-like build. It’s nice to see that MDG is considering this; however it’s nicer to see the community get out in front and make some awesome strides.

A lot of developers are switching from Blaze to React

Disclaimer: I’m heavily biased towards React.

I started my webpack presentation off by asking the crowd if they had used or are currently using React in development. About 40–50% of the people raised their hands. That’s pretty incredible considering official React support for Meteor only recently became available.

I don’t want to start a Blaze pile-on here. I do want to share what I feel like was a pretty strong sentiment this past weekend: people are abandoning Blaze.

The reasons I’ve heard are many and are generally what you hear when you ask anybody about why they have switched to React. React gives you stateful components. It’s more performant. It abstracts better.

The main takeaway here is that, generally, people are uncertain about Blaze’s future. MDG will undoubtedly continue to make Blaze better. One question is: should they even try?

Mongo is nice, but we want options

We know that SQL support is on Meteor’s roadmap, but what about more exciting databases like Neo4j? In his talk last weekend, Chet Corcos blew everyone’s mind when he found a way to implement Neo4j in his meteor app using a package he wrote called anydb. It’s amazing work, no doubt, but, as he explained, it violates one of Meteor’s 7 core principles: Database Everywhere.

A regular Meteor app has mini-mongo on the client and it works great for things like live-queries and such. The problem with graph databases like Neo4j is that you need to know the entire data set at the time of the query, and that implementation is impossible to do inside of a minidatabase. This is a really good explanation of the problem, written by Chet himself.

The beautiful thing here is that the community has found an answer. The problems is that the answer breaks the fundamental principles of Meteor. So, does MDG amend its principles? Is the community left to figure this stuff out by ourselves? How opinionated should Meteor be?

Personally, I rather enjoy seeing the community answer these problems. Which leads me to my last takeaway.

The Community is just as important as the thing it’s built upon

This isn’t exactly a revelation. In fact, it's pretty obvious. Communities are fundamentally important…to everything. I would have long since given up on Meteor if it wasn’t for the awesome community of developers.

Which is why, after spending time with some very committed members of the community, I’m a bit uncertain as to the future of Meteor. A good portion of Space Camp was spent talking about how MDG should improve their involvement in the community. It’s no secret that pull requests languish without response. Why? We discussed community driven solutions to this issue that we could only hypothesize about, because we don’t even know the real reasons why pull requests languish in the first place.

On one hand, it's great that the community is willing to help MDG solve these issues. On the other, it's incredibly frustrating to not know what is causing these issues in the first place.

If there is one thing that was made absolutely clear after my time at Space Camp, it’s that MDG has an incredibly passionate community willing to put in the time to make Meteor better.

The question that remains is: why aren’t they utilizing us better?