I know. Was thinking of how to get my idea to market. With meteor I can create apps for Android and iOS. That’s why I like it. Otherwise I would stick with php.
for now i am not putting in imports in my massive project. but i wll dive into react over the winter and then redo the whole thing with imports.
I understand and realize this fact. More a question of if I can follow and how hard and much time it will take to learn a new way (for me). I also admit I’m often against a bigger changes in the beginning, having to learn again, but will accept it afterwards when I see the benefit. Though I love development and updates that makes things better as long as it’s not major changes.
From my perspective meteor is more complicated than before and lost it’s beauty of simplify and my gut feeling tells me that this might have a bigger implication than you think. Look at rails. Followed the same path, from simplicity to becoming more complex (as I see it). I believe this is one reason it lost for that.
I know I’m not the right person to talk about this, not having a natural born programmer’s mind, but simplicity and consistency are parameters for market penetration as it helps people like me to adopt it.
(Could also be that I need to dive into a good tutorial, explanation. The meteor tutorial suddenly adds this thing with import without much explanation.)
3 Likes
Imports and other references to .h files come from compiled programming. The method prototypes (argument types and return types) had to be checked by the compiler - it also avoided name collisions.
In node (i.e. on server) it makes sense for when you are using external modules / packages.
But when you are the author(s) of the referenced code (e.g. same folder), it does not make sense. And it makes even even less sense when you are running in the browser where everything is global.
We need to know where things come from - not just trust blindly. I disagree with just trusting the dev community because something works for them. Take a look at npm - most packages are dormant and / or of lousy design.
Been reading about modules but I don’t get it. I get the concept, import and export aspect but not how it would benefit building an app in meteor in most cases as it by default becomes more complex.
Look at https://www.meteor.com/tutorials/blaze/templates, what’s the point of making it this complicated for a basic app? Could be useful in some cases but doesn’t make sense.
And do I need to keep track of what I need and import that?
https://guide.meteor.com/structure.html#example-app-structure Seriously?
1 Like
My app is still on 1.2 and I am now considering porting it to 1.3 I have to admit that I am sharing your confusion. Though I really love the idea of imports in general, the current state seems to be a bit half-baked to me.
For instance, the npm vs. atmosphere comparison in the Guide says:
Atmosphere packages are packages written specifically for Meteor and have several advantages over npm when used with Meteor. In particular, Atmosphere packages can:
- Depend on core Meteor packages, such as ddp and blaze
- Explicitly include non-javascript files including CSS, Less, Sass, Stylus and static assets
- Take advantage of Meteor’s build system to be automatically transpiled from languages like CoffeeScript
- Have a well defined way to ship different code for client and server, enabling different behavior in each context
- …
Well, these are actually the features I need most in nearly all of my packages. As I am developing for both desktop and mobile, differentiating code between both worlds is crucial. So at least for me, it seems as if npm packages are only useful for generic code (comparable to moment.js) that does not rely on any Meteor or Cordova specifics at all. I guess this is just an intermediate state. But still, it makes things more complicated than necessary. It would have been easier to understand if npm support would have been limited to (non-Meteor) npm community pacakges in version 1.3 until all features of Atmosphere packages would have been ported to Meteor.
1 Like
PS: I tried to do a simple meteor update now. But just as with my migration from Meteor 1.1 to 1.2, all Meteor did was to throw a lot of exceptions. They seem to be related to mquandalle:bower. Despite the Meteor guide stating that the breaking changes are minimal (those mentioned should not affect me), nothing just works out-of-the-box. TBH, my trust in Meteor slowly erodes each time I am facing such kind of issues. I understand that the JS ecosystem is evolving fast and MDG wants to keep the pace. But developer experience is getting worse. Should it only be the Bower integration, I can live without it since I am mainly using this to import external libraries which I now could import via npm instead. But, if I fix this issue, what comes next? When I migrated from 1.1 to 1.2, it took me weeks to get over all issues, which were mainly related to SCSS these days.
1 Like
This:
my trust in Meteor slowly erodes each time I am facing such kind of issues
is a crucial issue with anything, especially a new-ish JS Node-based solution aiming for mindshare. If it’s not addressed, developers will leave and new ones become wary. Someone needs to test and document the issues honestly and thoroughly, but briefly.
Especially as I was (still am) intending to teach Meteor to over 90 eager front-end computer science students in October.
3 Likes
I was in a similar situation lately. Hired new employees based upon Meteor <1.3. Due to this we just looked for frontend devs experienced in javascript - that would have been sufficient pre 1.3.
After hiring them but before they started, 1.3 dropped, suddenly the tutorials are not fit anymore to teach them, and even the file/directory structure changed. Now you need specialized javascript developers to move forward, rather than just front end devs. I had to teach them myself, and spend hours of work time on that rather than developing our software.
Now I am in the bad position of having a huge project that will need to (eventually) all be upgraded with imports, and absolutely no easy way to do that.
Just think how the meeting with the owner/head manager is going to go when I tell them we need to spend at least a week or so converting to an updated format that will offer no visible gains in the software. I can explain it is for the best, but tbh I myself don’t think it’s a very smooth system, and it feels very much like we’re being punished for being faithful to Meteor and starting a serious project with it (even though it was being advertised as Production-Ready at the time the project was started).
My issue with imports is it should not be difficult at all to make a system to assist with the transition. IDE’s have offered features to assist for many years, but the Meteor IDE’s have not been updated based around these changes yet (and who knows if/when they will be changed to support this specific issue). But if an IDE can do it, the creators of the platform should be able to as well.
I would think that ensuring Meteor still uses the “Meteor Way” would have been the top design priority for the developers, as it’s what made Meteor unique and enjoyable to use… That’s what really was the selling point for Meteor. They have gave some reassurance in the past that things will be looked at again in the future, but some of their comments make me not so sure…
3 Likes
By not using imports, you will shoot yourself in the foot when your app gets bigger. Globals are fine for small apps, but on bigger projects with multi-person teams, imports solve a lot of problems. This is not just true in JS, but true in any code system. Plus, ES6 Modules are part of JavaScript’s spec now, and Browsers will soon support modules natively, so the recommended is for you to embrace them.
Maybe you’re right. I will try. If I dive in MDG has to promise that they will not take a new sharp turn down the road. 
With Atmosphere I could add a functionality without knowing things in detail, like “Need file upload? Add this package x and do like this”. With npm packages it doesn’t seem that easy. Or I’m I wrong?
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:
- is there a well-documented smooth path between major versions?
- does the learning curve scale nicely for beginners?
- 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
- 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.
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.
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.