Hacker News Reader

Comment by alttab | Hacker News Reader

Is this "gain" really worth the additional compilation step? The best thing about javascript in my book is saving my file in VI, and then clicking "refresh" on the browser. Having to re-process these files after each change would be a total pain in the ass, not to mention my syntax highlighting won't work anymore.

There may be "macros", but with vanilla javascript and without an extra step, you can use "functions."

Also, commence having to build an adapter for your web framework, and integrate it into the build process. And forget it if you are using asset pipelines in Rails, what sort of crazy hack would that require?

All of this extra integration for Javascript macros?

View on HN

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). For sweet.js there's 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).

Maybe 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.

I 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

[1]: http://livereload.com/ (I use free, OSS command line versions, not the paid OS X app)

IMHO,

the problem with macros is not the build step.Most IDE support "build on save" operations.

Macros are just EVIL period, anything goes with them.

Devs end up not writing the same language since everybody has their own (undocumented) macros.

Good languages dont need macros. Hopefully,they will never make it to JS core...

>Macros are just EVIL period, anything goes with them.

Have you ever worked with a Lisp? Macros are incredibly useful for all sorts of things. For instance, the 'if' form is a macro. So are 'define' and 'let'. For an example of something that isn't a core language feature, there's the SRFI-41 Streams API that uses several macros.

I know that this is trite, but as with any feature of any programming language, it can be abused. That doesn't nullify the benefits of macros.

>Good languages dont need macros

I hold the opposite opinion. Good languages need hygienic macros. Macros allow a programmer to build a language suited to their problem space.

> what sort of crazy hack would that require?

Exactly the same as are required for Coffeescript, which is to write a Tilt that uses ExecJS.

https://github.com/magnetised/sweetjs is a ruby gem for interfacing with sweetjs using ExecJS. The Tilt wrapper would be about 50 lines of code.

This is exactly the sort of thing the asset pipeline is designed to do, and the ruby community has been figuring out how to take advantage of the tooling the javascript community is writing for a while now.

I don't like coffee script for the same reason - it adds extra processing steps and runs different code than I write in the browser. While it cleans things up, I personally haven't worked on a Javascript project that would benefit from what I see as only incremental improvements to "cruft," which can be just as easily implemented with functions and continuations/monads.

nowadays, most of the front end development relies on grunt. After you configure livereload(grunt-watch), you will never hit refresh again. So if you integrate sweet.js in grunt, it is a breeze to use. Same holds for sass, compass, uglify, rev, etc, etc...

Reply on news.ycombinator.com