3 ms·
If you already use build process, the additional step would be just one additional step in the build process, "invisible" to you. So "save in Vi, reload" still
by andreypopp 13y ago
If you already use build process, the additional step would be just one additional step in the build process, "invisible" to you. So "save in Vi, reload" still works.
If you don't have build process when writing JS code for browser, well... I don't know how it's possible.
I suggest you to look at browserify (http://browserify.org http://browserify.org). For sweet.js there's sweetify (https://npmjs.org/package/sweetify https://npmjs.org/package/sweetify) transform.
Note, that sweet.js compiler generates source maps, so you can debug your code with comfort.
Syntax highlighting still works, because most of the syntax highlighters highlight tokens and macros preserve token structure of the language (well it can kinda "introduce" keywords, but if you use Vi, it's just 1 line of code to fix your setup).
- alttab 13y agoMaybe this works for server stuff, but if you are doing client-side JS I feel like adding this sort of layering as more trouble than its worth. But when it comes to JS, I'm a minimalist.
- lowboy 13y agoI use js compilation (CoffeeScript, Browserify, React JSX, etc) and it is definitely worth the extra layer. I have a setup with Gulp[0] that watches my files for changes, compiles, and then LiveReload[1] automatically refreshes my browser window, so I never have to leave my editor for non-interactive changes. CoffeeScript compilation with gulp-coffee is usually on the order of a few hundred ms, and I'd expect SweetJS to be the same. [0]: http://gulpjs.com http://gulpjs.com [1]: http://livereload.com/ http://livereload.com/ (I use free, OSS command line versions, not the paid OS X app)