Last active
December 14, 2015 18:02
-
-
Save trotzig/1c7c0fc1ae4cdea10f12 to your computer and use it in GitHub Desktop.
A talk proposal for React conf 2016
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Import-JS lightning talk proposal | |
Talk title: Where's that module again? | |
With JavaScript development becoming more and more modular, keeping track of | |
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 | |
based on variable names. It knows enough about JavaScript, ES6, node modules and | |
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. |
Cool, I'll work on this a bit.
I changed a little and added the thing about not having to type. Thanks for feedbacking on this!
COLEMAK-savvy
lol! However, COLEMAK shouldn't be in all caps. Same with VIM.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.