Why import when it works without?

I spent some time considering alternatives, but Meteor came out on top because its web/iOS/Android ‘write once run anywhere’ approach seemed more promising than other similar solutions, and if I could get something running in a few hours and then go back and work on it, so can newbie students.

But for me there are three crucial issues that determine whether I stay with it:

  1. is there a well-documented smooth path between major versions?
  2. does the learning curve scale nicely for beginners?
  3. is there a well-trodden "Meteor way’ without too many choices?

This thread seems to have gone slightly off-topic, but the original question raised a bigger issue, especially for those coming to Meteor recently from other technologies/solutions.

No need to worry about that, since ES6 modules are part of JavaScript, not part of Meteor specifically. JavaScript isn’t going to deviate from ES6 Modules anytime soon (probably never), and I highly doubt Meteor will drop them.

Everything is backwards compatible for the most part. That’s a feature of Meteor.

How do the tutorials look? That’s what a beginner would use.

Yep, just meteor create then start coding with Mongo.Collections and Blaze templates with reactivity. That’s the easy get-up-and-go Meteor way of getting started. For that case, choose the “Blaze” version of the tutorials.

thanks for the concise reply :slight_smile:

  • Backwards compatibility: fine, I’ve not yet been through an update but have an app in development that will require it, so will test things there.
  • Learning curve: yes, the tutorials are fine, but I was thinking of the process after that, and where to steer students tackling their post-tutorial phase.
  • Meteor way: definitely Blaze for now, although I found exporting to iOS a little unpredictable, and deployment is unknown territory.

As for further learning resources, the Kadira academy looks useful and Meteor-up or (this version which one??) seems like the way to go for deployment if you have your own server.

Take a look at the official guide.

I use the official guide, but students won’t because TL;DR. I tend to condense the essentials, which I’ll probably have to do if there’s no minimal intermediate info once they’ve completed the tutorial.

Wow. As an engineer, I read user guides, documents, and data sheets like good bedtime novels. You’re too good to your students. :slight_smile:

3 Likes

Good question. I think I would go with React, although it may have higher learning curve than Blaze, and then I’d send people to the React docs/examples (as well as show them myself).

I feel like with React an app is less likely to be buggy unless you really know the internals of Blaze, because with React we are more in control of when/how things are rendered, whereas with Blaze that stuff is hidden behind the scene in a compile step. So, although Blaze is easier to start with, I feel like React is more flexible in terms of letting us solve rendering problems because we are dealing directly with the JS code, whereas with Blaze we write HTML and we don’t actually ever interact with the compiled JS that is generated from our templates. We can use the JS Template API, but that’s not really a documented feature of Meteor, and probably ends up being a lot more complicated than just using React.

One thing that the guide doesn’t cover, and which can kill performance in a big app, is how to limit the rate at which reactive computations happen. If you have tons of data, and that data is changing all the time, then it may cause your blaze template to render all the time and cause jank. There are topics on that here in the forums, but I can’t find the one where I posted a snippet showing how to handle it, but this one describes the concept.

1 Like

NPM is just a package distribution mechanism. What the code of a given package actually does is a different story, and depends on the package in question. Some packages might be easy to use, others maybe not.