ElixirScript - converts Elixir to JavaScript

Your Libraries & OS Mentoring Libraries
41

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.

42

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

43

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.

2 Likes