I'm still thinking about #306 and #274.

I wonder if it would be reasonable to include a feature (exposed as part of the js package I imagine) to include raw JavaScript. I can see why this would be considered evil and ugly and all sorts of bad juju, as it would make syntax and type checking impossible in that code--but that's already true in JavaScript included in the *.inc.js fashion, so I wonder if it's really any worse. It's also evil in that it does magical things with a function with an otherwise normal appearance.

What I am imagining is a new js package method that looks something like the existing MakeFunc, and works something like JS's new Function() constructor. By requiring that any raw JS is encapsulated in a function, at least we maintain a clear barrier between JS and Go, and we don't start to look like PHP.

As a contrived example, we can presently use new Function() like so:

jsAdd := js.Global.Get("Function").New("x","y","return x+y")

And it produces the following JS:

jsAdd = new ($global.Function)($externalize("x", $String), $externalize("y", $String), $externalize("return x+y", $String));

What I would like, is something that instead produces:

jsAdd = function(x,y) { return x+y }

or a functional equivalent using an IIFE or somesuch.

I have a hacked up proof of concept (flimzy@f048c21) which takes the following input:

jsAdd := js.LiteralFunc("function(x,y) { return x+y }")

and produces:

jsAdd = (function() { return function(x,y) { return x+y } })();

Am I smoking crack to go down this road?