ElixirScript - converts Elixir to JavaScript

Hmmm… maybe you would like using OCaml syntax instead of ReasonML syntax (both compiled to JS by Bucklescript) if you want a less verbose syntax. Although in that case not sure how you can use JSX. There is the bucklescript-tea project but instead of JSX it uses an Elm-style list-of-list representation of the DOM.

Maybe someone knowledgable over on the ReasonML Forums would know how you could use ReasonReact and JSX (which like you said is just calls to React.createElement) with the less verbose OCaml syntax. It must be possible I’ve just not seen examples.

I’m not as interested in the syntax but the excellent inferred typing (without using TS or Flow) is the big win for me. Biggest drawbacks is having to find (or write) bindings to random 3rd party JS libraries (if you need them) and the relatively small (but friendly) community. Anyway it might be close to what you are looking for.

Funny that you mention that. I literally came across Reason earlier today.

The thing is I’d argue Reason is a step down from JavaScript in terms of syntax.

In all, I’m really happy with React and JSX–I just miss the feeling I have when writing Elixir code, where every character is meaningful.

My issue with JavaScript’s at times slightly verbose syntax is it creates mental friction for me. Imagine reading a made up dialect of English that put “to” in front of all verbs and “a”, “an” or “the” in front of all nouns–

My an issue with the JavaScript’s at times slightly verbose the syntax to is it to creates mental the friction for me…

–It isn’t necessary and makes the sentence harder to read. I have to use effort to filter out these meaningless filler words in order to understand what I’ve written (or debug, for that matter).

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.

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.

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.

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.

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

• otherwise, remove the quirks and follow the structure of React

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.

Any usage examples / use cases mates?

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!