In the blaze todos app you often see import statement that do not seem to do anything because meteor is loaded anyway.
Example: import { $ } from 'meteor/jquery
Is this just for good form?
1 Like
Yes, this sets you up for loading Meteor packages the correct future-proof way. I’d wager globals will be removed in a future version of Meteor (1.4?).
Why do Meteor DEVs want to force us to do dirty import export while this is beautiful not to have to worry about that???
This is exactly why I loved Meteor: no boilerplate, concise code, no need to worry about things like import export… So why are Meteor core developers wanting to enforce me to do that?? This was a strength of Meteor: really user (dev) friendly.
Seriously if you want to keep track of your import export let them optional don’t force us to do it. We’re not all big teams of 30+ DEV people that want to reference every stupid thing…
Why do you even want to do that? For the sake of simplicity STOP !
Please Meteor, don’t force us to do this. Please !!! Your tutorial was much simpler without the export/import. WHAT HAPPENED???
I feel this is going in the wrong direction ! This is my alert guys ! I used to love the simplicity, now you lose your spirits.
As a guy with little DEV background, I could put my hands on Meteor easily, now it is becoming more complex, more boilerplate… after 1.3 update. You introduce concept we don’t want. You’re basically going away from the first spirit of simplicity.
You’re turning just like angular and react. It looks like your backend DEV took the control of your solution. We’re not all from a very technical background…
To align with the ES2105 JavaScript community.
2 Likes
And also to keep and track namespaces I think
1 Like
I’m with @antoninadert here. When I’ve built non-Meteor apps using Browserify, I went out of my way to find things like bulk-require to avoid having to manually specify—and then maintain—hundreds of require/import statements. In general if a file was in my project tree, it was meant to be there and should be included, end of story. Meteor’s (original) implementation of automatically requiring files was exactly what I wanted, even if it meant some hassle with making sure that things were defined in such a way that every function was defined before it was called.
I’m all for importing things from external libraries, especially if it allows me to import less than the full library, e.g. slugify = require('underscore.string/slugify'). But dealing with lots of imports for my own app just seems like a maintenance burden with little upside. I suppose it makes tests faster, as you can test a file in isolation without having to load the entire app, but that’s the only real-world benefit that might sway me.
1 Like
Import/exports do away with leaking globals to the client, too. With globals, you can interact with pretty much every part of your app’s API that’s defined on the client from any browser…can’t do that w/ imports. Way safer.