From what I understand, Elixirscript compiles Elixir to erlang and then converts erlang to Javascript, right?
This means that I can’t convert isolated elixir expressions into Javascript expressions based on the AST of Elixir and not the compiled output. I was thinking of something like f(x, 1, %{a: 1, b: 2}) bring converted into f(x, 1, {a: 1, b: 3}).
Is there anything in Elixirscript that can help me do this, or my best bet is to write a custom solution myself?
I don’t think elixirscript runs on erlang bytecode. From the readme:
This is done by taking the Elixir AST and converting it into JavaScript AST and then to JavaScript code. This is done using the Elixir-ESTree library.
I haven’t looked at the source, but from the blog:
Calls to Erlang functions that the Elixir standard library make have to be reimplemented in JavaScript. There are many that are implemented, but there are more that need to be. This effects the availability of some Elixir standard library calls. A major contribution to ElixirScript would be to help with an implementation of an Erlang function that is blocking the use of an Elixir function you want to use!
I wanted to offer some feedback:
I am glad you have been working on compiling Elixir to JS. But what I’d really like to see is a ReactJS-like experience on the frontend. What I mean by that is:
keep the modules structure of Elixir, where anything in the project can be accessed without needing to know the specific file path or explicitly export anything
keep the ability for Elixir syntax to be transpiled to JavaScript
I’ll elaborate on the third point.
My main beef with JavaScript is the syntax includes meaningless, “boilerplate” characters. Conversely, I really like JSX. While it’s already too late and doesn’t mean much coming from a stranger, I think you went in the wrong direction with a DSL different from JSX.
I wish I could write a file like this:
# App.ex
defmodule ProjectName.App do
use React # EX
import ReactNativeWeb
alias ProjectName.ErrorBoundary
def mount,
do: IO.inspect "Mounted!"
def render(props, state) do
<ErrorBoundary>
<Text elixir={
if Platform.OS == "web", do: "web", else: "screen"
}/>
</ErrorBoundary>
end
end
This would render the text web on your computer or screen on your phone.
In the JSX article, there is a quote:
Angular, Ember and Knockout put “JS” in your HTML.
React puts “HTML” in your JS.
The analogy here is:
ElixirScript puts “JS” in your Elixir.
What I have proposed puts “Elixir” in your JSX.
I.e. Yes, Elixir is more powerful than JS–that’s why we’re replacing it. But, I hope you’d agree that JSX is a better DSL for the frontend.
From an implementation standpoint, this may mean creating a JSX DSL for Elixir (like Phoenix’s Ecto is for SQL queries).
I.e. Keep React’s design patterns and JSX. Replace JavaScript’s syntax with Elixir’s.
Actually, you don’t even need to handroll the DSL. You can just have a special render macro which accepts a do: block with JSX as its last argument.
I know this isn’t exactly what you are envisioning embedded directly into Elixir but have you looked at ReasonML with ReasonReact?
That’s what I am happily using to get JSX with elixir style “module”/component structure you are talking about (no explicit importing/exporting) and great type inference.
ElixirScript works at a level where if you can do what you defined in standard Elixir, it’s work in ElixirScript. I’d be interested if anyone did what you prescribed. There was an ElixirScript issue open for almost a year about JSX but nothing really came about from it.
Googling, JSX has not yet come to Elixir… Anyone know off the top of one’s head about other languages that have implemented it?
I found this article. In a nutshell, JSX syntax is merely syntactic sugar for an AST of React.createElement calls.
If you’ve seen the library Shorthand, it allows one to create maps with JS-like behavior: m(item) => %{item: item}. For ElixirScript, you could simply have a function jsx(type, props, children) that evaluates to the JS equivalent.
That said, in all honesty, I would advocate for a redesign.
The concept to keep in mind is to think of JavaScript as a virtual machine for the browser. Then, ElixirScript should build on top of JavaScript in the way Elixir builds upon Erlang. This means that if I put JS in an EXJS file, the JS will work (interoperability). So ElixirScript is just the building block that converts Elixir to JavaScript. It shouldn’t have opinions.
Next, we use React as the structure for our JSX. React should be implemented as a behaviour. It should require a @spec render(props :: map, state :: map | pid) function or macro that accepts a do: block with JSX. If implemented as a string, there is already the syntax to interpolate Elixir code. Then the string can be converted to JS, which can handle the parsing. It would be nice to have a JSX linter for .ex files though.
Beyond that, the React behaviour should allow for optional lifecycle methods (e.g. mount, unmount), a constructor (maybe call it init to follow Elixir convention), and I’d argue for an optional data method, ideally modeled after Relay…
Last, I would suggest a documentation revamp.
A great starting point for using plain ElixirScript would be a socket.ex in a Phoenix project. I’d love to see an example of this, or receive enough instruction from the documentation that I would know how to set this up for myself.
And a final note: I really like your implementation of state inside of a process. I think this is really powerful because then the backend and frontend can now share the same state (SEE: “Functional Web Development with Elixir” re: stateful servers). Add in Mnesia (in-memory database) and your React/React Native app will be faster than anything out there.
Reviewing React’s implementation notes, I definitely think the role of ElixirScript should simply be to convert Elixir to JavaScript. Likewise, React.EX should simply convert to React components.
I think you’ve already built those parts. I just want to see them refactored to be closer to the React experience.