|Import-JS lightning talk proposal|
|Talk title: Where's that module again?|
|your dependencies can be a pain. To import a module you need to know where it is|
|located in the file system, and with a growing application this will quickly|
|become a problem. Typing all those "import foo from..." lines can hurt even the|
|most COLEMAK-savvy people out there. To ease some of that burden, you can|
|automate the process of importing dependencies through an editor plugin.|
|Import-JS integrates with your favorite editor and helps you resolve modules|
|such to turn remembering folder structure and typing import statements a thing|
|of the past.|
|In this ligthning talk focused on developer experience, I will demo Import-JS in|
|action. I will show how it can speed up your development by finding even the|
|shadiest modules. I'll show how it can be used in VIM, Emacs, and Sublime. And I|
|will show how you can contribute by integrating Import-JS with your own editor.|
I think in the current iteration of this proposal you miss the opportunity of saying that this tool removes some of the mundane work from working with a modular JS codebase--you mention knowing where modules are, but nothing about the typing involved in managing the list of imported modules. Also, and perhaps this is obvious, it might be worth mentioning that removing these tasks frees the developer up more for working on and thinking about the heart of the problem they are trying to solve.
"Developer experience" or DX was a big trend of React JS Conf Europe and it might be worth dropping that terminology in this proposal.