Game of Thrones; My Meteor Journey

react
1

If I may compare Meteor to the Game of Thrones (and I think I may) then I am the guy who seems to have missed several recent episodes. Wait, what John Snow died? Oh, now he’s alive? But everyone else is dead?

And rather like GOT, apparently the books aren’t any help any more, either:

I am not a real geek. I needed to develop an app for my business and - after several false starts on other platforms I was captivated by the comparative simplicity and immediacy of Meteor.

Like many others, I am sure, I followed the brilliant Discover Meteor book and within only a few short weeks I had an app that did everything I needed it to do and looked shop-bought.

After 2 years of infrequent tinkering and improvement I have three apps that I (and a few dozen other users) rely upon every day.

About 10 days ago I settled down to write a new app that will eventually help to manage our warehouse. Or so I thought. A brief perusal of my usual resources revealed that nothing is the same, everything has changed and I KNOW NOTHING!

Admittedly, no one is actually dead.

I don’t want to re litigate the whole react v blaze bun fight (TL;DR). At this point, I just want someone smarter and more knowledgeable than me to tell me what I should do.

Formerly, Discover Meteor was the definitive voice for newbies like me (yes, that’s right, I am apparently a newbie again). But in my view that responsibility now falls to MDG. MDG needs to pick a side, make a stand and tell us what to do. [There are a whole bunch of GOT metaphors that can go here, but I can never remember the names so pick your own.]

Of course, there is the Meteor Guide and the excellent tutorials, but these are, frankly, a hot mess of blaze and react and different routers and seemingly shifting patterns. It will not do.

Virtually every new app needs a basic framework and plumbing. MDG needs to sanction a plain vanilla structure (along the lines of Discover Meteor’s Microscope app) and to include it (preferably step-by-easy-step) in the guide / tutorials.

To include:

  • React templates
  • Flow Router
  • Bootstrap
  • User Accounts mechanism (using FlowRouter and Bootstrap, so it’s pretty)

[assuming these all are the anointed ‘winners’]

In short, MDG needs to stop being a player in its own convoluted drama, step through the 4th wall and start writing the script.

Pretty please.

Many, many thanks for all the amazing work thus far.

18 Likes
2

I think I know the perfect medicine for you.

  1. Forget everything.
  2. Forget all routers. Just use Flow-Router.
  3. Forget React, pretend it doesn’t exist. Use Blaze. It’s simpler. It’s faster to implement.
  4. Read the full docs twice, and never look at Discover Meteor again.

After these four steps, I’m 90% positive your condition will be cured.

12 Likes
3

Yeah I think this brings up a fair point though - there isn’t a super clear opinionated path to follow like there was a year or two ago. Definitely something to think about.

5 Likes
4

Dont forget React. :slight_smile:

4 Likes
5

The good news is that it won’t take me long to forget everything.

6

Thanks Sashko.

Think fast

7

May I submit my study plan? :slight_smile:

But I think the biggest reason there isn’t a super clear opinionated path to follow is that Meteor just isn’t as opinionated and all-in-one anymore.

Modern Meteor apps are now one part React, one part plain Node/JS code, and one part pub/sub glue. That last part is the only one that is really Meteor-specific, and I think it’s pretty well covered by the guide.

5 Likes
8

We sound like on similar level.

Stick with most of the books use, which is iron router and blaze. Learn react in between projects and implement it after you master it.

9

Blaze was founded to reflect Meteor JS philosophy like clarity and simplicity. Meteor JS used to be kind of one product with one framework and now (from a user perspective ) is kind of three different products . Meteor Blaze, Meteor React and Meteor Angular. Previously if someone want to explain meteor he would right one book now he has to write three books. if someone want to make an example on how to use meteor he has to write three examples. Isn’t this a waste of resources and time? If I speak Blaze then I can’t understand React and vice versa. Meteor is starting to have the same complication and non “Meteoric” ways in it. Apple company as an example define the best approach for the user (from their perspective) prefect it and avoid scattering the energies on so many directions by adopting others way of working. I really liked Meteor JS as it was and I am concerned that it will start to change and abandon its own philosophy.

5 Likes
10

Honestly I think you’re the one over-complicating things here. A large chunk of the Meteor community has happily moved on to React as the standard front-end framework.

Giving people the freedom to use other options like Blaze and Angular doesn’t seem bad to me, as long as there’s a clear default (i.e. React). Even Apple has more than one iPhone model :slight_smile:

3 Likes
11

I’m in a similar boat to the OP…

I’m going to be doing a small introduction talk on Meteor to my fellow work mates as I’ve been recommending it for a long long time! They are used to making apps with Laravel’s PHP framework which is very well made but quite tedious and verbose to use.

At the time of my recommendation of Meteor it had a very easy to grasp framework with (Blaze, sub/pub MongoDB). In comparison to Laravel, Meteor was quick to understand, there was less to learn to get started, less code to write to get your results and the output was a reactive website! It was a really easy sell! :smile:

Now I feel like what I will be teaching them could change again very soon. Apollo will be that next big change for instance. Probably for the better :slight_smile:

It seems like Meteor is no longer as tight of a framework and its not as clear where to start and what ‘tools/libraries’ will be most effective and give you the best long term support.

I haven’t found any professional videos that give a nice introduction to meteor as of 1.3 and I think its because its not as simple anymore. Currently Meteor would have to make 3 videos. With Apollo Meteor might need to make many more!

As a company my teammates recognise the value in having a framework that is clear in its approach. This helps with coding readability across workers, a shared understanding of the framework and it makes code easy to recognise after not looking at it for a few months. At Meteor’s current state I think they will be left feeling that it’s really cool but not settled enough to work with on big projects.

I’m now stuck with the decision to teach them the new ‘trendy’ set of additions in Meteor and tell them Apollo will change everything soon because that’s where meteor is heading OR to teach them the ‘classic’ simple approach which is easy to pick up but might not exist next year.

6 Likes
12

Thanks for sharing this @sacha ! Really helpful! :smiley:

There was a video I watched once that talked about Meteor striving to be a platform. As you say I think its starting to feel more like an interchangeable stack.

This to me looks like Meteor’s future:

Template engine / front-end - React :unamused:
Client/Server - Meteors node.js
Querying - Apollo/GraphQL
Database - Up to the developer

2 Likes
13

A man must become no one. A man must forget his loves and hates and fears. There are many more development paradigms to offer up to the many-faced god.

18 Likes
14

I’ve been using Meteor since 0.9, and very quickly fell in love. And while I see the value in what MDG is doing in making Meteor a more open platform and integrating it better with the Node and JS ecosystem, I have to admin that this last release put me in a difficult situation. I’m about halfway through writing an app, and I’ve got what I had about halfway converted to the new import structure. A lot of the reasons I gave to people for choosing Meteor are shifting.

Atmosphere, for example, is rapidly losing value for me. It used to be great because I knew all the Atmosphere packages integrated with all the other packages I was using, such as Blaze. It also used to be the case that if I wanted to use a package I would just ‘meteor add’ it and start using it. And sure, I can still do that. If I’m using Blaze. And if I don’t care to prepare my project for the eventual elimination of eager loading.

Lately I feel like React has become the biggest thorn in my side. I built my app using Blaze, but I’ve been studying React and honestly I think it’s better. But if I switch to React now, I have to re-figure out a bunch of stuff I’ve already figured out, and I don’t have that kind of time. Also a number of the packages I currently use to great effect would have to be replaced somehow.

And I must say that more and more I feel like I’m becoming an expert in Meteor esoterica when what drew me to it in the first place was that it obviated the need for such detailed understanding. And while I grant that you can still use Meteor the old way (eager loading, Blaze, etc), the elephant in the room is that MDG is quite obviously moving away from that.

Another elephant in the room is that, as far as I’ve been able to tell, the Meteor core developers themselves prefer React. Someone please correct me if I’m wrong, but I think Galaxy was created with React, not Blaze. If React is better, which I think it is, and if the Meteor devs prefer it, which I think they do, I’d rather see them just go whole hog and make React the default and focus on making it as simple to use as possible.

That being said, I’m super impressed and actually quite pleased at the progress MDG has made toward integrating Meteor with the rest of the ecosystem. And a big part of the reason I use Meteor is that I trust the MDG team. I think that this is just a phase we’re going through. Some things just didn’t scale well for large projects, and they’re fixing that. Once they’ve conquered those challenges, I think we’ll see an effort to simplify the new world order. Towards that end, I think creating the Meteor Guide is one of the best things they could have done, because somebody has to write it and keep it up to date. And the process of documenting their decisions for the community and introducing new developers to the platform will becoming increasingly painful if things get more complex.

I for one am still betting on Meteor. And as hard as it sometimes is, part of this whole game is being willing and able to throw away the old way when a better way comes along. I think the most important thing that MDG does for me is get out ahead of me and figure out better ways of doing things and then make those ways available to me. And they’ve done an excellent job! Thanks guys!

5 Likes
15

Yes, the study guide is excellent and I have been following it - together with your screencasts on converting to React. However I note that, even in the short time you posted these screencasts, the patterns have shifted again and the Meteor Guide / Tutorial provide quite different methodologies, which is confusing to the newbie / convert.

1 Like
16

Agreed. I think we are looking for clarity - and for MDG to lead, not follow.

1 Like
17

Just do what you know works until you learn something that is better. (Nearly) Everything that worked for Meteor 1.0 still works in Meteor 1.3. If you want to learn something new, start with the new ES2015 features, because language features are very stable. I think libraries are in flux all the time, so there is no stable winner.

1 Like
18

Don’t need to fear about react.it is a super cool thing .in start i am also confused about it but after 3 to 4 weeks struggle learned a lot and now i don’t want to look back to blaze.

Meteor ,React,ES6 & NPM Rocks!!!

1 Like
19

I think @Sanjo makes a great point, if you are just building an internal warehouse app, I doubt you’ll run into any issues just sticking with what you’ve used before (i.e. iron router / blaze). At this point I use Meteor for small personal projects or prototypes… and I mostly stick with IR (because I find the before / after filters convenient) and Blaze. Concepts in Discover Meteor I think still work well for smallish apps where you don’t expect to have a lot of users.

2 Likes
20

I would compare this to construction industry:

You can build houses from bricks and you can build them from iron and cement blocks or you can build them from fancy polymer modules.

If you are alone and building a small house, using bricks would be MUCH MUCH easier and you would not have to find a vehicle to move reinforced concrete blocks around.

The same goes for roof. There are at least 5-7 mainstream choices, and no one is using ceramic tiles for commercial buildings.

Iron Router and Flow Router are still routers, they route. Even if there will be fancy Banana Router for Meteor in 2017, it will still route, otherwise it would be called something else :slight_smile: Walls are still walls irrespectably of material. Users do not care how beautiful your code is, users care about utility, and for speed of adding new features (if that matters).

7 Likes