Why import when it works without?

help
1

Why is this needed when it works without it in a new app with Blaze?

import { Template } from 'meteor/templating';
import { ReactiveVar } from 'meteor/reactive-var';

import './main.html';
1 Like
2

As soon as v1.5 hits, you’ll probably wish you did import because Meteor will be installed as separate NPM packages/modules and all you’ll have to do is rename a few things.

As far as I can tell, the “not needing to import” is only a feature for Meteor’s API. Anything other NPM packages or modules, you’ll need to import.

1 Like
3

And this is needed in every .js file? I don’t understand why they’ve done it like this, seems more complicated than before, also the structure with “imports/ui/…”

1 Like
4

I guess you may be interested in this article:

1 Like
5

Yes. Well said. It resemble my experience with rails. I’m thinking that maybe I should stick with php for what I want to do. Their path (php) has been very consistent and probably a reason for why it has (have had) a huge following.

6

I like to keep a basic structure:

client/

  • layout/
    – mainlayout.html
  • pages/
    – main.html
  • partials/
    – header.html
  • script/
    – main.js

I now understand that “Files inside imports/ only load if they are imported”. I would like to skip import. Not sure by http://guide.meteor.com/structure.html if this will be possible in the future.

  1. Why would you use this setup and have imports/ for a “normal” app (I guess a majority of apps)?
  2. Can I keep my setup without using import?
7

You currently can keep this structure, with or without imports.

Having a explicit import behavior makes it much more easy to reason about where do things come from in your code, that makes refactoring and maintaining much easier. With imports you can also influence load-order, which you could only by renaming or moving files in subfolders prior to meteor 1.3

Btw. I don’t think you can compare PHP with meteor. And… PHP has imports since long ago.

8
  1. If you wanted to make sure that ALL of your files (inside imports/ anyway) are modules/used in some way or you have code that you don’t want to load unless imported.
9

Making everything global might seem easier in the beginning, but once you work on larger apps almost everybody agrees that imports are necessary. I think this is a case where you have to bite the bullet and just trust the rest of the programming community, even if you don’t (yet) see the need for it.

10

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.

11

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.

12

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
13

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.

14

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
15

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
16

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
17

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
18

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
19

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.

20

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. :slight_smile:

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?