I was thinking about the recent moves about imports statement.
I do think this thing should always remain optional:
Here is my reasoning: Imports statement make my code less lisible, it is actually trying to replace the purpose of structuring my data in tree folders, but with little success.
For plugins, as we are in Meteor or npm, I believe we should not state things like import { Meteor } from 'meteor/meteor' (Atmosphere and npm should do that instead)
These are ceremonies making my own code less visible (to use @manuel 's expression from ViewModel docs)
Furthermore, MDG is working on delivering the âcode splittingâ capabilities in Meteor 1.5, will the import be mandatory to have this? If so I am figuring out that youâre also splitting the community at MDG.
Many Meteor developers I personally know chose Meteor for the easy tree structure; if MDG manage to have the same benefits as code splitting for all users, why would anyone use Imports statement any longer ?! Huge leap forward if you ask me
TLDR: MDG, Please donât force imports, donât try to rally other developerâs communities (like reactâs), please make code splitting available without it and define the future best practice of development
For a long time, I was on the fence, leaning towards your point of view. Since being exposed to Visual Studio Code, Iâve come around to a different viewpoint:
Imports are the better approach.
However. To make them work for all developers, we need better tooling. Specifically, we need code editors and IDEs that can manage Rename and Move refactors, which will update the imports automatically. Once thatâs accomplished, we need Drag and Drop functionality, which will automatically trigger the Rename and Move refactors when people are organizing files in tree folders.
Visual Studio Code is making a tangible step towards this functionality. Which makes sense, because these kinds of refactoring tools have been around in C#/.Net for decades. So, itâs to be expected that the Visual Studio team would try to be bringing that kind of refactoring to Node/Javascript. And Import statements explicitly enable such functionality.
The problem of course, is getting a best practice disseminated throughout the rest of the community. Not everybody uses Visual Studio Code. Implementing refactoring tools in Atom, Sublime, WebStudio, etc is difficult and takes time. etc.
Nonetheless, Iâd like to respectfully suggest that instead of rejecting Import statements, we should be thinking about what kind of plugins we can create for editors that will enable Rename, Move, and Drag and Drop refactorings.
Hello @antoninadert for my experience with Meteor thus far having imports makes maintaining and managing complex codebase much more transparent and controllable. Not using imports might be easier to start with but then as the codebase grows, itâs much easier to look at the top of the file and figure out what is being loaded from where.
Furthermore, imports is where the rest of the JS community and the language are heading and Meteor needs to be embraced and embrace the rest of the JS community. Also code splitting is based on dynamic imports for specifying the splitting points, and dynamic imports syntax is a tc39 proposal, re-inventing the wheel is not wise and will backfire for sure.
I had the same thoughts as you when I first encountered imported, but I think itâs the right approach going forward
What I say is that you donât need to embrace the existing community if you make the best move, then the community will follow.
Your suggestion is not incompatible. This would make sense that a special code parser would automatically generate these imports statement for you. (Am I too optimistic ?)
So that you keep benefits of looking at them at the top of your files, minus the current downsides of having to do it yourself, which is a distraction from actual coding.
Imports answer a very important question for me: âWhere does X object comes from?â Itâs harder to answer the question with global objects. Not to mention naming components gets cumbersome when theyâre global. The problems arenât insurmountable, but theyâre annoying enough for me to add imports to the top of my files.
That said, there are cases where itâs just ridiculous. For example React demands that you type in the react import in files with stateless components, even though you have no reference to react at all.
Fanboy: Thatâs because the stateless component gets transpiled to a regular React component behind the scenes, and that uses the react import. So you have to add the react import. Me: Okay, if the react import is only used behind the scenes, why not import it behind the scenes? Fanboy: Ah but that is too much MAGIC! Me: So transpiling stateless components into what React actually understands isnât magic, but adding the react import is? Fanboy: Of course! Me: /facepalm
I see your point @antoninadert and yes one needs to know when to lead and when to follow.
This sounds like a first-class IDE support for JS imports and npm packages. Java and .Net had them for ages.
Like I said I do think import is the right step forward for supporting complex projects. Luckily due to the way Meteor evolved and the smart folks at MDG keeping backward compatibility, Meteor as it exist today has built-in support for eager-loading and itâs coexisting nicely with JS imports. However right now the import folder isnât really perfect, I think itâd be nice if weâve a package (kind like insecure, and autopublish, maybe globals?) that can be removed later as your code base grows in complexity.
Meteor is evolving in an interesting and unique way, in the sense that it has all those quick development tools (blaze, autopublish, insecure, accounts, globals? etcâŚ) but it also adapts as your project complexity and timelines change. I havenât personally seen any platform inside and outside the Node ecosystem with that level of adaptability.
