On big team projects I definitely understand the problems with globals, but when working alone I’ve never had any issues with name clashes. So is it really worth it to go through all the trouble of listing exports and imports in every file you make? I also feel the file structure of the example apps using imports seems so unnecessarily convoluted.
Is it right to feel bad about not doing things “properly”, or is it okay to be lazy and do what works well for you? 
That’s a fair question. Personally, I’ve worked on several projects alone and I do see benefits in having explicit import declarations as the project grows in complexity and duration even for a solo developer.
I’ve listed some of the benefits on this thread.
I see how it can feel a bit unnecessary for small projects, but as soon as your app grows, it gets really hard to follow where all the global stuff is coming from. For me, the imports work as documentation, I know where each component in the file comes from, I can trace it in the imports, and it annoys me when stuff is in my file but I don’t know where it came from.
Consider also the cases where you stop working on a project for a while, then come back and have forgotten everything. Then it is nice to be able to read and trace imports to see how stuff fits together.
Another thing, you get better control of load order, so you can start and import files in a specific order, super useful.
How about because it encourages modularity and enhances test-ability?
Thanks for your input 
Not trying to refute you guys, just giving my experience here. For context, my current app is an “old style” Meteor app, built with Blaze. It consists of 110 .js files (not counting packages).
Vue = require('vue');
I’m in a similar camp, and I see no benefits either.
For modules, I create packages to house my functionality. For state, I use Reactive-Dict. Everything else is usually namespaced.
I imagine imports/exports are a much bigger deal to the regular JavaScript world than for Meteor.
Just wanted to +1 for import/export.
Refactoring post import/export implementation becomes much easier. Longer, but more consistent and with less of those “where did I put that” moments. Honestly, seeing all of those import statements is a bit overwhelming at first, but having typed/looked at them so many times, I can probably tell you the path to most of my key modules without having to think about it, which makes navigation quicker also.
Also, if you import/export and eslint with as few globals as possible, I can almost guarantee you that your code will be cleaner and more legible to others (and yourself in a few months when you revisit the stale bits).
@msavin Hehe thanks for the support. Having a well known package author in my camp makes me feel better 
Honestly my app is pretty big. Big enough that my folder structure is getting a little annoying sometimes, but globals have never really caused a problem for me.
Also, if you actually used imports to import different things using the same name, that would get really confusing! In that sense globals are actually “stricter”
Yep, likewise. One-man project with 236 files (sans packages) and all old-style Meteor globals. I’ve never had much trouble finding where stuff is coming from using the editor’s global find on variable names. So not much motivation to use import/export thus far.
If I was ever to bring someone else onto the project, however, I imagine it wouldn’t take very long before I started appreciating the value in using import/export.
Indeed - half of the time, developers are messy with globals… then they blame globals and say oh, globals suck and imports/exports are the solution. This kind of stuff happens way too often. I think if you approach it the right way globals can be seen as a good or even better thing.
For example, while imports/exports have the advantage of letting you trace back code, with globals, you can pretty much inspect all your functions from the console.
the own code often becomes other’s code after a while.
Altough you know and understand your code now doesn’t mean you still know it so well some months later. In particular, if you worked on something else in the meantime. So I would not distinguish between working in a team and working alone.
Having said that I think that imports/exports definitily help to understand/refactor/debug/improve code. IDEs and tools like import.js (e.g. in atom https://github.com/Galooshi/atom-import-js) and eslint can make it a no-brainer to work with imports/exports so i don’t see any reason to not do it.
I dunno … I quite like being able to change file and folder names and move them around willy nilly. How does that work out with import/export?
6 months later without imports and dependencies 
or: “what the hell does this mean? Who did this piece of smelly code?” - checks git blame, sees his own name - “stupid me!”
I am currently a solo developer. I’ve been more than that in the past. Small projects can quickly become big ones…
I think the issue with all the new Javascript features is that many have come to programming only through the scripting path and have not experienced big projects with big longevity. Because (currently) Javascript is very lenient when it comes to forcing the use of specific features it seems to many that those features are redundant.
I’ve been working on one Meteor project for about 18 months (on and off). During that time, my knowledge has grown, my techniques have changed - even though I have been developing for over 35 years. Now, leading up to launch, I have to revisit some of the earlier code (that has been working reliably) in order to bring about owner-driven changes (mostly legal). I can’t believe some of the code that I wrote not all that long ago and how easy it was to break it with simple changes.
However, I can definitely say that, where I have used modularisation (export/import) it has been much easier to resolve the issues or make the changes. I also say this coming from an object-oriented experience base.
Yes, I do have some “global” (namespaced) code but it is mainly for global reuse (e.g. I am now loading Numeral and Moment into a global namespace because they are used on just about every page). My other justification for doing that is they are 3rd party libraries that I am not changing. I may change my mind later and add them in my top-level React component and have them passed as properties (but that would only be to facilitate switching them both out for a different component - unlikely because the API to the them would change anyway). In other languages, that pattern is known as the “singleton” pattern.
Finally, when this system goes into production shortly and the cash flow starts, there will be other development staff (devs, testers, etc.) that will need structure and standards to work against. Export/Import are GOLD for doing that due to enforcing encapsulation. You may be a solo developer today - but tomorrow?
[DISCLOSURE: I architected and built (with a small team) a meteor-like Javascript environment with modules, build to a single file, ddp-like messaging, etc. about 15 years ago and wish I had all these new JS features back then. The language was still only for quick page functionality and the engines weren’t mature enough so we ended up abandoning the project and rebuilding the architecture in a client/server Java for performance. But it DID work. So I am really happy to have ES+Meteor+React+Mongo now.]