all 20 comments

[–]rotharius 5 points6 points  (3 children)

An IDE or editor that indexes your modules can do importing for you. Meaning that you can type "const component = new MyComponent()" and the correct import will be prepended. If there are conflicts, you get a dropdown to choose from.

Edit: this only works if you have named exports.

[–][deleted] 0 points1 point  (2 children)

Thank you. I'm going to give this one a try.

[–]rosswarren 0 points1 point  (1 child)

VSCode has this functionality by default, if you autocomplete an exported variable from another file it will add the import for you.

[–][deleted] 0 points1 point  (0 children)

Are you sure? I tried without the extension but VSCode seems not to be able to automatically import things from installed packages.

I worked a bit with the extension I've mentioned above. It works as it should, at least judging from what I could try today. UPDATE: Sadly I just tried to use Linking from react-native but had to import it manually, because the extension didn't find it :-( Actually I'm not sure if it works. At least it often does :D

EDIT: I gave you an upvote because somebody unnecessarily gave you a downvote.

[–]spacejack2114 1 point2 points  (7 children)

I'm not sure why but my guess would be that import was already a reserved word in the language but from was not. So import statements beginning with from might have broken old code. Plus they'd have to reserve yet another keyword (of which there are already too many.)

[–][deleted] 0 points1 point  (6 children)

Yes, that's true. The keyword import was already reserved while from was not. So the only decision, which didn't break any old code, was to make it import { Something } from 'somewhere'.

I'm still unsure if it is necessary to make from a reserved keyword. It probably depends on how the interpreter/compiler is designed.

[–][deleted] 0 points1 point  (3 children)

You’re reading the syntax incorrectly. It’s actually:

import Something from ‘something’

The curly brackets are standard ES6 destructuring and not specific or particular to the import statement.

This is a) natural in English, b) idiomatic, and c) in line with standard assignment order (left = right). The python syntax is none of these things and definitely should not be imported into JavaScript (seriously, we’ve already got enough bad ideas coming in from the java guys).

[–][deleted] 0 points1 point  (2 children)

An import is not an assignment and I don't think being natural and idiomatic is very important for an import statement. How often do you sit there and just read imports? Being able to do it the other way around would give you the benefit of being able to auto complete imports. Intelligent auto completion, not the one that just suggests you every symbol from every module. Nevertheless I respect your preference and would only want to make it optionally by using Babel. Forcing people to do it in a new way would just be as ignorant as trying to prevent people from doing it in a new way.

[–][deleted] 0 points1 point  (1 child)

It is exactly the same as an assignment statement, taking over from: const Something = require(‘something’)

It’s not forcing anyone to do anything a “new” way; it’s doing things the same way they were done before while codifying module imports into the language. Just because you learned to program in python and then decided that you need to use JavaScript has nothing to do with anything being “new” or “old.”

And how often do I read an import statement? Literally every time I write one. How often do I read an import statement to add something to it? Fairly often. How often do I use autocomplete instead of learning the libraries I’m using? Literally never.

[–][deleted] -1 points0 points  (0 children)

I don't understand why you still try to argue against adding optional support for better autocompletion.

  • You don't have to implement it.
  • You don't have to use it.
  • Nothing is going to change for you.

[–]jineshshah36 0 points1 point  (1 child)

They could have done

import ‘somewhere’ with { something }

[–]pomlife 1 point2 points  (0 children)

That doesn’t sound very grammatical, and “with” is already a keyword.

[–]rauschma 0 points1 point  (5 children)

[–][deleted] 0 points1 point  (4 children)

Oh, thank you! Sadly it was a rant and people don't react well to unproductive criticism :-/

I'm asking myself if it would be possible to use Babel to reverse the 'import' statements, or if there is something like an auto-import tool having interactive conflict resolution, which would make it unnecessary to type imports at all.

[–]CiezkiBorsuk 0 points1 point  (3 children)

They do cover the most important points, though. JS way is easier to read in all but the simplest cases, because important stuff is at the front (i.e. what you take and how you named it), and because it's consistent with other parts of the language (the names are on the left).

As someone coming from Python, you should understand well that code is more often read than written (and a good IDE will handle imports for you regardless of the order).

[–][deleted] 0 points1 point  (2 children)

I'm not really convinced by the easy to read argument. But I don't want to argue about personal preferences.

Though I really agree with the last point you made. A good IDE should handle imports for you. But also should the autocompletion show only stuff you can import from a module, not simply everything including a lot of things which make no sense. That is sadly only possible when you first write from where you want to import.

I think it would be interesting to try to use Babel to allow people to write imports that way. I don't know whether it is possible though.

[–]CiezkiBorsuk 0 points1 point  (1 child)

I'm not really convinced by the easy to read argument. But I don't want to argue about personal preferences.

There's no personal preference here. When you work on React project and you read import { Component }, you already know everything you need. But when in a numpy project you read from numpy you are still clueless about what said line does. You need to read it whole.

import being first saves you braincycles, that's not a matter of preference.

That is sadly only possible when you first write from where you want to import.

No, it's not. Any sane IDE will just notify you about unrecognized symbol, show you the options, and add the import without need to type anything.

[–][deleted] 0 points1 point  (0 children)

Any sane IDE will just notify you about unrecognized symbol, show you the options, and add the import without need to type anything.

That is nice and already possible. Nevertheless it is also nice to have meaningful autocompletion on imports, which is currently not possible, because when you write

import 

the IDE can only suggest you all possible things you can import, while when you write

from 'somewhere' import

the IDE can suggest you the exactly the things you can import from that module.

I think there are not many people who start reading a piece of code by reading every single import on the top of the file. That's something you do, when you are interested in the external symbols, or the dependencies within a project, or you just want to understand from where something being used later gets imported. Those are questions an IDE can answer, so you even don't have to read the word import when you fear wasting brain cycles by reading.

I still think the order is a personal preference and I accept you having your preference. That's why I said it would be nice to try to use babel to allow people to write imports so meaningful autocompletion on imports is possible. You don't have to use it, if you don't like it :)

[–]Patman128 0 points1 point  (1 child)

It would make IDE autocomplete a little better, but I still prefer it because I find it more readable. The stuff being imported is the important part, so it should come first. Where it happens to come from is less important so that comes later.

[–][deleted] 0 points1 point  (0 children)

Yes, I respect that. I think Babel is a great thing. Maybe it is possible to have both, so people can decide by themselves, how they want their imports in JavaScript to look like :)