Meteor – First impressions

community
1

First, some background: I am a Front End Developer working mostly with Node, with build tools like Gulp/Grunt/Broccoli, and obviously with JS and SASS.

In the last few days I have been evaluating Meteor for a personal project of mine, a simple app featuring HTML5 video games, a blog section and a contact form page. The basic idea would be to update and display a game leaderboard in real time and also save the game state in the mongoDB.

I haven’t actually wrote more than 15 lines of code till now, mostly because I have been investigating if it is worth spending my time learning Meteor. So, I am writing mostly to give the Meteor Community my feedback and also to seek advice.

Things I liked so far
I love the idea of being able to write Isomorphic client/server side code in the language I am most familiar with, and being able to easily exchange data between client and server. AFAIK this is by far the best feature of Meteor, and my main reason to give it a try (otherwise I could use any robust CMS based on Laravel).

I like the Blaze UI library, it is simple and straightforward. I believe that it is more than enough for my needs, React or Angular would probably be way too heavy (I like Riot though).

Meteor community is amazing. I can see that thousands of packages have been already created and the forum is one of the most active and friendly I’ve ever seen. This is a rather important point because I don’t expect Meteor to vanish into thin air anytime soon.

I can not ignore the fact that Meteor is a full-stack framework that combines several open source technologies and works out of the box. I can just type meteor create <path> and meteor and I am ready to code. The alternatives don’t look that promising.

Things I didn’t like
Isobuild: I have lot of issues with Isobuild and the package system in general. There is, AFAIK, very little control on what you can output with it. I am used to fine-tune my projects with Gulp and Grunt, but Isobuild seems to work mostly without any configuration file. For example, how do I exclude JS and CSS files (Note: I know I can create a folder with a specific name to exclude them) or compile them in a very specific order, or run them through NPM packages? How do I add a NPM package that isn’t supported by Isobuild? What if the maintainer of a package stop supporting it? Also, why is Isobuild so slow? I can compile large Gulp apps in 5ms compared do 3s or 4s of an empty Meteor project.

Another thing I don’t understand is why popular packages like yogiben/meteor-admin add all JS, templates and bootstrap CSS in the client? What if I don’t want bootstrap in the client but I still want to use the admin? Isn’t this a big performance issue? Shouldn’t the router take care of downloading all admin assets only when I navigate to myapp.com/admin? I don’t like the idea of having a huge js file with everything inside, it’s not scalable, I guess this could be fixed with something like WaitOnLib, but why not doing it by default though?

The last major issue I have with Meteor is the fact that the MDG is not having a clear roadmap. This is totally confusing for newcomers. What view should I learn? React, Blaze, Riot, EmberJS? I don’t personally care, but a choice must be made, otherwise this will result in a mess in the package system. How’s a package publisher going to support 3 or 4 view libraries? How’s MDG going to maintain the documentation for those libraries?

Because of these issues (expecially the last one), I have decided to temporarily park my Meteor project until there is a clear roadmap available.

6 Likes
2

For your last issue, React, Blaze, and Angular are the main view contenders. They announced recently that they plan to support all 3 equally. But it seems the competition is more between Blaze and React.

Considering their recommendation of FlowRouter, with how Flow works, both Blaze and React are interchangeable. Use the appropriate view package and call it with the router. Easy.

From the most recent explanation of how it stands, they said Blaze is still their recommendation, and they will be supporting all 3 (Blaze, React, Angular). They also said the recommendation may change in the future once React catches up to Blaze, which does need a bit of clarification, but my interpretation of this is: If React catches up and is still in the lead, they may suggest that as the “main” way to use Meteor, and Blaze will not be the recommendation (receiving no further updates) but still be usable.

I would really appreciate it if MDG could confirm this - I’m currently using Blaze in the project I’ve started working on lately. The reason being, we’re getting some new employees soon, and it will be much easier to teach them Blaze than React. So I would really appreciate it if they could confirm that even if Blaze will not be the recommendation in the future, they will not give up support for us legacy users. That’s what I suspect, but confirmation would ease my worries!

But in your case, you can feel 100% confident in using React right now. It has so much momentum it definitely isn’t going anywhere.

Hope that at least helps your last issue somewhat!

1 Like
3

I watched the screencast last week and my impression of the React vs Blaze was that MDG has a really good plan. In essence:

  1. Blaze is the recommended view layer of choice for newcomers to Meteor. It is also the recommended view layer of choice for small apps, prototyping, and the weekend/hobbyist programmer.
  2. React/Angular is the recommended view layer for apps which are expected to have significant investment over time, specifically catering to apps with large teams working on them, where significantly more granular control is required.
  3. It is very much expected, also encouraged, to start out with Blaze and if the app has legs move to React over time. It is possible to have mixed apps, which are being ‘transitioned’ from one view layer to another, i.e. can have Blaze and React components in the same app.

This was my understanding from the screencast last week. I think it makes good sense as MDG are trying to support both enterprise class folk (React/Angular) and new/prototyping guys (Blaze) hence different view layers. No point of a one size fits all.

Tat

2 Likes
4

Welcome. Be sure to read the official guide - http://guide.meteor.com, it’s a first thing you should read right after browsing the docs.

Thank you. Feel free to join us also on IRC (#meteor channel on Freenode), Gitter - https://gitter.im/meteor/meteor and get your Slack invite on http://slack.themeteorchef.com (this one is unofficial Slack channel of an awesome The Meteor Chief website).

If you like your code simple and straightforward, I highly recommend you to check out http://viewmodel.meteor.com - it’s one of most popular community enhancements for Blaze which I use on daily basis and I guarantee that with this package, Blaze becomes a much more clever beast, letting you write faster, less and in a more maintainable way.

That’s what package oriented architecture is for: http://experimentsinmeteor.com/package-based-architecture/ It’s recommended for middle and large Meteor projects, though it’s unclear to me for now if that will change when Meteor officially brings us ES6 modules.

This will be solved with ES6 modules - you’ll be able to specify which exact modules you want to import to your files, so Meteor will only download them when necessary.

This is kinda tricky. When Meteor was mainly about Blaze, people were complaining that it doesn’t give the choice. Now, when Meteor made React and Angular equal to Blaze, people are complaining that they must make a choice.

When Meteor wanted to recommend React not a long time ago, real shitstorm happened. Trust me, you don’t want to go back to these times. Just take it for granted that it’s better now how it is.

For your case, just go with Blaze and I recommend manuel:viewmodel once again. :slight_smile:

Usually package publishers just decide which view layer to support. Others may make forks of them if needed. But you can also mix view layers and use React with Blaze together if necessary. Many React guys do that, so that they have access to Blaze related packages.

Why would MDG maintain the documentation for community packages?

8 Likes
5

Regarding Blaze, react, and Angular, here is what MDG says -

“If you have an existing app in Blaze you’re fine…in Meteor 1.3”

"If your starting a new fast/proof of concept/weekend project we still Blaze as a really great way to build an app quickly…"
Blaze is going to community. I’d expect 1.4 it will all be angular2 and react

Meteor Night: https://www.youtube.com/watch?v=Okhoh6Mpjqs#

6

I expect Blaze to be in the same status as Angular and React - it will get updates outside of the main Meteor release cycle and can hopefully get a life of its own!

10 Likes
7

Yeah, Blaze I feel has a big advantage that it’s easy to have someone who knows just HTML/CSS and have them easily create content for your site. That’s the biggest reason I’m staying with Blaze. We have some new employees coming and it would be a lot of extra work to train them all in React in order to work on our software.

Even though our project is probably going to be at least 1 year of work, so a decent sized project, it’s not worth the losses as of right now.

3 Likes
8

Thanks everyone for all the suggestions, they are greately appreciated!

I guess I’ll go for manuel:viewmodel with Blaze and FlowRouter, although it is still not clear how ES6 modules will fix the Isobuild issue of concatenating all js files, the lack of control and the compilation speed. Is MDG going to replace Isobuild with NPM? Will this enable us to setup a customizable build system?

What I am basically looking for is a way to load just the core scripts of the app and then load other libraries/modules on demand(http://guybedford.com/practical-workflows-for-es6-modules) based on the route. Has anyone tried jspm.io and systemJS?

Sorry, I wasn’t clear. I was referring to Blaze/React/Angular, not the community packages.

1 Like
9

Like I said, you already have full control over your files with packages. It’s up to the user if he wants to use this approach or not.

No, but Isobuild will incorporate some features known from other build systems like Webpack.

When I was starting my Meteor adventure, I spent quite a few days browsing all available resources and learning about what’s going on in MDG and in the community. I highly recommend the same thing for every new Meteor developer. There’s a nice lecture waiting in many topics on this forum and many articles on the web.

Trust me, all the questions you ask were already answered quite a few times.

I still don’t really understand the question. React and Angular are not a part of Meteor. It’s not up to Meteor to document them. But there’s a whole website dedicated to Meteor-Angular managed by MDG and soon there will be React version of the official Guide too.

10

In the mean time, take a look at Preloader as well… :wink:

11

Great, this would be a cool addition to Isobuild!

I just thought that MDG would have a easier time concentrating in writing documentation for a single view library instead of splitting forces and supporting all. It would be less confusing for new users too :slight_smile:

Thanks for the suggestion, but this package is based on iron:router, isn’t flow-router recommanded over iron:router? I guess I could use the triggers functionality of flow-router with a ES6 module loader like vazco:universe-modules?

12

Yes, you’re right - the FlowRouter compatibility is in the works.

Stay tuned :slight_smile:

13

That’s one of many reasons to recommend one view library over the others. It’s a valid one. But there’s as many reasons not to. The most active and controversial thread on this forums used to be about Meteor trying to recommend React over Blaze and Angular, which generated a lot of rage among Blaze community.

14

@microcipcip,

Regarding the view library discussion, Meteor basically just has to give you instructions on how to set up your view layer. Once you have it setup, the view layers function mostly as they would elsewhere. For example, Blaze is fairly straightforward and already well documented, or once your setup with React then you can use most of Reacts documentation, etc.

In Reacts case, it actually works surprisingly well. Because React is mainly about views anyway, and Meteor basically backs React up with everything else it needs.

Because of this, it isn’t too much documentation to keep updated in the end. They just have to keep Blaze documentation up to date, and keep a tutorial for integrating the others. If you check the Tutorials page for Meteor, you can see an example with all 3 view libraries. That’s really all they need to keep updated, the rest you could find on the libraries documentation itself. Not too bad!

The bigger issue is if module developers start using one of the view layers as a requirement. Although that is more of an issue of badly designed modules (in most cases) rather than a Meteor issue.

In the end, the choice of Blaze or React comes down to personal preference. Blaze is easier for prototyping, and may be appropriate if you (or potential employees/partners) are going to be basing your design off of traditional HTML/CSS design. React would be better in the situation that you already know/are comfortable/have components designed for it, if your or potential employees/partners are already skilled in it, or if your project is going to be extremely large to where coding standards will need to be enforced between many contributors.

I’m going with Blaze because my main project will be a 1-2 year project at a small business, where I am leading the project and will have to train/work with a few other designers that have backgrounds in HTML/CSS/JS (mostly on the front end). Blaze will make it dead easy for the front end designers to feel comfortable immediately, and Meteor will allow them to assist me on some server work, which is ideal. React would up the learning curve quite a bit for each new employee, and wouldn’t take advantage of their backgrounds in my case.

If you are going to be the sole designer on this project, then it is 100% up to preference of which you feel more comfortable with.

2 Likes