getting to 1.0 ?

[clarkevans]

This project seems quite interesting. I assume the lack of commits means that it's more or less stable? I started to add features like this to HypertextLiteral but it might be better to just delegate JS content interpolation to this library. That said, I'd like to tag HypertextLiteral as 1.0 before JuliaCon.

[twavv]

Hey @clarkevans!

I released a 1.0 many moons ago which then swiftly broke lots of other stuff in the ecosystem because it swapped the dependency of this package and WebIO (this package currently depends on WebIO).

The 1.0 release was a complete rewrite and I think it works pretty well, but we had to yank it from the package repository because it caused so many issues. I never got around to fixing the WebIO issues. I really should but there are never enough hours in the day.

In the meantime, if you want to fork this repo and create a new package, I'd be happy to help with that (maybe they can be unified down the road). I can create a new repository in the JuliaGizmos organization and give you access if you're so inclined.

(also, by fork, I'd recommend creating a new repository and copying the history instead of using the GitHub fork feature since that means you don't get search functionality, etc.).

[clarkevans]

Oh. Is this work in a branch? What should we call the new package?

[twavv]

The new-but-yanked work is in the master branch, but it's not published to the general registry.

Something like JSMacro.jl would be relatively self descriptive I think.

[clarkevans]

Wow. This is a neat package. I'm still wrapping my head about how it might help HypertextLiteral but I think it's distinct, and they should work together nicely, but not having any inter-dependency.

• Is there a need for JSON dependency? When you want to serialize directly to Javascript, I'd rather have nothing become undefined, missing become null, NaN become NaN, and Inf become Infinity. Moreover, JSON doesn't escape <s, <S and <! within a string value, as would be useful within a <script> tag.

• Why not convert Dict into an object?

I'm still thinking I don't love JSMacro this is a conversion of Julia AST to Javascript code, it's rather useful project -- for writing data validation code, for example, that could work on both backend and front-end.

[twavv]

Is there a need for JSON dependency?

For arbitrary objects, I'd expect user-defined JSON serializations to work, so I'd say yes. This would let other packages work without explicitly depending on JSExpr.

Re: null, I think that could be handled by introducing a custom serialization context. I think that could be done relatively simply, but would require threading that context struct around.

deparse(::AbstractSerializationContext, ::Val{...}, node) = ...

With respect to <script /> tags, I didn't design this package around the use case where the output would be literally embedded in an HTML file. If you have a relatively simple solution I'd be happy to incorporate it. One option could be just to use the custom serialization context above to escape / in strings (since I think(?) that's the only place would be valid in JS syntax).

Why not convert Dict into an object?

Do we currently not?

mydict = Dict("foo" => "bar")
@js @const myvar = $mydict
# const myvar = {"foo":"bar"}

If you mean @js Dict("foo" => "bar"), I made the decision to not "transpile" anything like that (Dict is a valid function in javascript!). This project is strictly for JS using Julia syntax. Otherwise, you start to get issues where things work how you expect 95% of the time. For example, if we do Dict, why not also map sin to Math.sin? You end up going down a rabbit hole that way and you'll always forget to handle someone's favorite function, or they'll be confused because they defined their own sin function and it's not getting called.

In general, I stayed away from translating Julia semantics to JavaScript because the languages are VERY different.

I don't love JSMacro I'd also do something like JSAST (or JsAst?). The only downside to that is that packages can't use variables with the same name as the module (and there is a JSAST type in this package).

[twavv]

it's rather useful project -- for writing data validation code, for example, that could work on both backend and front-end

I want to be rather explicit that I don't think this package is appropriate writing "isomorphic Julia." Translating the semantics of a piece of Julia code to JavaScript is beyond the scope of this package.

It's maybe possible to do something like that if you restrict yourself to a HEAVILY limited subset of Julia (no multiple dispatch, for example) but that would require a large amount of forethought and planning to avoid those "95%" issues I mentioned above. And at that point, you're just getting the worst of both Julia and JavaScript. It's also not clear how to do anything involving asynchronous operations nice JavaScript is event-loop-based; if your function does IO, it probably needs an async/await -- so do we await every single function call on chance that it's asynchronous?

[clarkevans]

I think this is too much for me to bite off at this time. I'm going to stick with simple value interpolation inside HypertextLiteral directly. Regardless, I added a few suggestions as tickets so that JSExpr could be used inside a <script> tag, and have a closer mapping of Julia to JavaScript. I hope it's helpful.