The State Of Meteor Part 2: What Happens Next

sacha · January 21, 2016, 12:34am

Part 2 of my article exploring the current state of Meteor is out:

https://www.discovermeteor.com/blog/the-state-of-meteor-part-2-what-happens-next/

(In case you missed part, here it is)

capensisma · January 21, 2016, 12:36am

First
Awesome Article even if I still didn’t read it hahaha

PS: The Rise of React feels like some Star Wars stuff here

sashko · January 21, 2016, 2:12am

I think this is pretty much on point! However, I think there is a value to keeping view rendering tech at arms’ reach, because that seems to be the place where people want to switch frameworks every year. Perhaps Angular 2 will be the next big thing in 1-2 years, and we need to leave the door open.

I think the way to do that is to avoid buying in 100% to the “react way” - IMO you should be writing a Meteor app that uses React for the view, not a React app that has just enough Meteor glue code to avoid JavaScript fatigue. This will let you rewrite your UI in whatever the most popular view framework is in 2 years, which can easily be something else than React. I don’t think it will be possible for us to say “no, you don’t want to use the thing everyone else is using” in that situation.

Of course, some of the “React stack” is great even if you’re not using React. Perhaps Redux or GraphQL is just as useful in Vue.js, Angular, and Blaze, in which case we should recommend it independently of React.

Of course, we need to make sure the components are modular enough that, if you want to, you can buy into all of the hottest functional state atom stuff you want without having to throw away 90% of Meteor to do it. Or, if you just want a small part of the Meteor hotness, you can just import it into your regular Node app. But that’s just good software engineering!

Unfortunately, I don’t think this post will draw as much attention as part 1, but that’s life I guess.

niallobrien · January 21, 2016, 2:25am

Couldn’t agree more, great reply.

capensisma · January 21, 2016, 2:35am

For me 2 years of support is Enough I just don’t want something to be deprecated within 6 or 12 month of work, So React here we go

wonderjunky · January 21, 2016, 3:12am

God I hope not. I went through a couple simple React “todo” app tutorials and wow, what a convoluted mess.

sacha · January 21, 2016, 3:35am

I guess it did draw some attention after all

sacha · January 21, 2016, 3:38am

Here’s how I see the situation. By “leaving the door open”, you’re satisfying the needs of people who like Blaze, people who like React, and people who like Angular.

However, at the same time you’re alienating a fourth segment: people who don’t care what front-end framework they use, as long as it’s straightforward and well-supported.

By deliberately picking React and “closing the door”, you’re making this fourth segment happy, and you’re also making the React people happy. And since I think there’s more React people than Blaze and Angular people (or there will be soon), it’s the option that makes the most sense to me.

charliecl · January 21, 2016, 3:51am

If meteor is working along this path it will become

npm install react-meteor

and will be totally disappeared from platform list.

idmontie · January 21, 2016, 3:55am

Favorite quote:

The Meteor community has been spoiled with full-stack components like Autoform, UserAccounts, or Tabular for years.

It’s those amazing full stack components that got Meteor to where it is today. The best part about using Meteor is that I can just stick the Twitter auth package in there, mess with the login button a little, and I’m good to go. I don’t care about the oauth handshake, or when to show the button, or anything like that.

It’s one of the most “magical” parts of Meteor.

marbemac · January 21, 2016, 4:03am

To sashko’s point, the 4th segment + React might be the largest pool right now, but who knows what the view layer landscape will look like in 12-24 months. I sure don’t! That said, I absolutely love React right now, and love all of the progress in this area.

sacha · January 21, 2016, 4:05am

I asked Dan Abramov about this, i think he had a good answer:

faceyspacey · January 21, 2016, 4:23am

Ur killing it on Hacker News right now!!!

It’s good to see Meteor on top, if even just for an evening. We hardly get the attention we deserve.

The top response to your Hacker News thread is basically doubting Meteor, saying:

“At best Meteor will be 90% cannibalized and replaced with open source tool.”

But the truth is that because of this Meteor has as a better chance than ever!

HERE’S WHY:
Meteor’s problem thus far has been it makes development easy but provides no way to “drop down” to a lower level and configure things like you would on “bare metal” NPM. Despite its easiness, this has scared away many developers from Meteor–especially the expert developers who would otherwise evangelize once they joined Meteor.

Therefore, Meteor just needs to provide a way to BOTH do things with sufficiently less boilerplate (like it’s always done well), but also allow you to drop down to make lower level tweaks as you would on “bare metal” NPM (something it’s never done). And perhaps even an intermediate tier in between for some features. This doesn’t just boil down to NPM support, but rather both advanced and beginner interfaces for common tasks. This is akin to using an ORM and having the capability to use raw SQL if need be.

For example, Relay + GraphQL is great but there should be the “beginner’s way to Relay.”

So the killer feature in fact isn’t a “feature” in the traditional sense, but rather a mechanism that only a full stack framework could provide. Being the only full stack framework that matters (and the only “reactive full stack framework” in existence), and given how complex to implement most this stuff is (a la “javascript fatigue”), Meteor is well positioned to scoop up the entire NPM market if it plays its cards right!

That all said, my perspective is that it’s more important for MDG to devote its time to build and configuration related stuff than to building “full stack react components” as you’re indicating, or really anything that the community can build. If it had the time, sure, great, but they clearly don’t. We need the ability first and foremost to specify a replacement to a core package, eg in .meteor/packages I’d like to be able to do:

tracker refer: ultimatejs:tracker

There’s a lot more that needs to be done regarding Meteor 1.3, module integration and Webpack, and I’m not quite sure @benjamn is considering them or even has had the time to do so. Here’s my article on the Meteor 1.3 wishlist:

MDG should put more than just one developer on that. It should be an “all hands on deck” situation. Doing this correctly is the linchpin that if done correctly everything else will fall in line. But if done incorrectly will mean we’re still a sequestered ecosystem from NPM where expert NPM/javascript developers don’t wanna play. We need to somehow become an option for them. The marketability of their blog posts and recommendations toward Meteor (i.e. PR) will be without parallel. In many ways it’s ironic–we don’t have to compete on features anymore, we don’t have to build any features anymore; they all exist on NPM. Literally basically everything package we have has a better counterpart on NPM. Just look at @mattkrick’s Meatier: https://github.com/mattkrick/meatier .

I don’t think we should assume that there are any features we can do better than what’s coming out of NPM. We can’t. We need to come at the problem at a different angle. First of all our goal is now: become popular, become an accepted standard just like NPM is, and at all costs. Even if we have to become slightly different. People are talking about “curation” this, “curation” that. Bla bla bla. You can already curate on NPM. I don’t think curating is our killer feature. You can install one package that includes many sub-packages that does the curation for you–leave it up to @arunoda and Mantra, or whoever builds an actual package implementing and making easy the Manta specification. What’s more, on raw NPM there is a million “boilerplates” doing all sorts of curating for you! Again, Meatier is an example of such. So the point is curation is not going to win us this war. What will though will be the ease with which you can implement anything. An example of such is keeping it so you don’t have to import and export modules like you currently can do (and like you can in Rails despite the fact that Ruby supports modules). I know that will be received with great controversy, but it’s a perfect example of a non-feature-specific thing that Meteor does which makes it a lot easier to get started. It makes it a half order of magnitude easier for the newb developer to not have to deal with imports.

So we need more “global” mechanisms that can be applied to any package or feature that make it easier to code. Another example has been the ease with which we can deploy to servers. Another example is the consideration of multiple build targets: mobile native, browser, Electron, etc. This is the stuff we need more of. It’s the only area I see we can differentiate ourselves anymore. Basically we can only compete on stuff that comprises the building of full stack multi-target applications.

An example of where we should do the opposite is allow you to use Express (or Koa or whatever you wanna use) to serve your app. That’s an example of where we’re currently doing it wrong. Making custom full stack react components that make it easy to do Datatables is the wrong idea–it will come out of NPM better inevitably anyway. It will just require extra steps for you to wire it up to your DB, but someone will eventually provide the server aspects to Reactable, Griddable etc. We can’t lock you into our crappier versions anymore like we did with Blaze. We need to find angles unrelated to specific application features to compete on.

It’s all this glue that has to be best in class. All the “not so fun” stuff. The reason React is winning is because of React Native. period. When React Native came around, everyone’s head who hadn’t already turned turned. React Native is a “not so fun” problem that nobody wants to tackle. Binding to Objective C and Java is a time consuming challenging non-sexy problem. It’s the non-sexy stuff where Meteor will excel because there will be less to no competition there, not the sexy fun view framework stuff. Not wiring the view framework to databases on the server either–that’s pretty damn sexy still. It’s a lot of sysops stuff. It’s the stuff between the lines basically. Again, the glue.

But again most importantly, it must be done in a way that doesn’t obstruct NPM, that doesn’t force experts to forgo Meteor. As I see it, that’s the one and only goal worth focusing on to truly win, and I’m not sure our Meteor 1.3 modules plan will be enough. Win over the experts, the same way Webpack has, the same way Wallaby is in the middle of doing for testing, and the same of course for how NPM, Node, React, GraphQL each swooped in and defined themselves. We just keep defining ourselves as kiddie-ware. Ease was meant to be our biggest selling point–it’s easy to get started with–but that has to be a point, not the main one. Not anymore. It can’t in any shape or form take away from expert level development. It just didn’t work out the way the “marketing department” had hoped. Clearly the computer scienc-ey super thorough “turn the game upside down” approach is what’s getting the most eye balls–points in case: GraphQL, Relay, React, Falcor, Elm, Cycle, etc. We’re at a tipping point. It’s not the same world where something like Elm or ClojureScript can’t be considered options anymore. The sooner we recognize this, the sooner we can “win again” lol. We need to be part of that forward thinking crowd if we wanna be on top again. If not, the guy from Hacker News’ prediction will be correct–we’ll be less relevant than ever. It’s ultimately a very challenging task to get right.

Being super easy just makes us look like a million platforms like Ionic, Telerik, etc. They have their niches as commercial products, but we’re more than that. Meteor was supposed to become an open source standard! That’s the point. Those commercial products will only stand the test of time as long as their founders want to extract money from the sea of beginner developers, or until they get bought out. Meteor is supposed to be a standard winner-takes-all open source appliance like NPM or Linux. I think Meteor has lost sight of that. Or perhaps they haven’t, and that’s why they never made things like a Router priority, and have chosen to give no priority to a specific view framework. Either way, I just hope @benjamn has enough resources because it’s really looking like the fate of Meteor is lying in his hands.

sashko · January 21, 2016, 5:27am

I think we can target both. Like I said, it’s just good engineering to decouple the frontend. But that doesn’t mean we can put in extra effort for a smooth experience with a particular framework, for example React.

Also I sympathize with obsoleting oneself - I hope Meteor 2 is the thing that beats Meteor, before someone else does.

sacha · January 21, 2016, 5:57am

Right, I think we agree. All I’m saying is that when a complete newcomer asks which front-end framework to use with Meteor, the answer should be “use React”, not “well, you can use React, Blaze, or Angular, and they all have their pros and cons”.

awatson1978 · January 21, 2016, 6:06am

So, basically, you’re recommending that new users go to the bleeding-edge technology first, with unknown best practices, rather than the stable technology that has been worked on for the past three years. There are some people who respectfully disagree that is a good business model for the enterprise.

The answer that many people want to hear is ‘use React or Angular if you want to be on the bleeding edge with the latest features, use Blaze if you want stability, and there is a commitment to a migration/refactor path between Meteor 1.0 and Meteor 2.0.’

sashko · January 21, 2016, 6:11am

Yes, right now I think we recommend new users start with Blaze, and people who are excited about React or Angular can use that. But once we have more support, useful packages, and best practices figured out for React, it seems logical to me to switch to recommending that.

And yes, there will be migration paths if we ever actually deprecate something and remove it, which we actually haven’t done since Meteor 1.0 AFAIK, other than some relatively small and unavoidable breaks.

faceyspacey · January 21, 2016, 6:16am

the same is basically true for React. React at most is a year younger than Meteor. Overall, React has likely had many more man hours worked on it than Blaze. It’s also far from “bleeding edge.” Bleeding edge would be Cycle, Elm, Om Next, and even those have influenced React greatly.

What React is missing is just connections to the backend like Blaze has, which is exactly what @sacha is recommend we focus on building.

I hear you though–the switch from Blaze is time consuming and for most legacy apps likely never gonna be an option.

awatson1978 · January 21, 2016, 6:17am

Keep repeating that message right there, and I suspect there will be much less overall uncertainty and angst, and the forums will calm down.

sashko · January 21, 2016, 6:34am

I would say that React has pretty radical changes even very recently - the split between React and ReactDOM, stateless function components, mixins vs. class syntax, and more. This is one of the things that frustrates people IMO, just when you thought you learned the syntax there’s a new one that has a new set of pros and cons. Personally I wish they would recommend one syntax and stick to it.

Yeah I think we assumed that people would infer that we aren’t going to break everyone’s apps willy-nilly, but we should definitely place a lot more emphasis on this in future roadmap discussions/announcements.