I was happy to run into José Valim at Goto Aarhus this year. I asked him about the many web frameworks for Elixir and which one to choose. His response was that most are abandoned in favour of Phoenix. Phoenix was on my shortlist from before, so I will be spending some time writing myself back to Elixir with Phoenix.

By now I have gone through a number of Elixir web frameworks, a web framework in Cocoa, and not
really been able to release my homepage in a way that I liked. So what would be more natural than
to drop the code and try something else, perhaps something that I’ve worked on before and found wanting?
Hello Node.js (+Express & CoffeeScript).

One of the issues I’d had last time I worked with Node.js was that debugging was hard, or console.log
based. This time I found that someone had made a Eclipse distribution with Node.js support. Turns out,
syntax highlighting and debugging CoffeeScript is still flaky. But I can step through most of the
dependencies I use, so that helps, and a lot more people are using this, thus searching the net for
solutions is better. Stuff I’m really missing from the earlier approaches, though, are

the actor model

GCD or other nice threading

a crash only being local to a piece of the code and being restorable

What was really nice, was that I got up to where I’d been in both Elixir and in Cocoa fairly quickly.
Also, I have a feeling I will be able to complete it this time. ;-) So onwards we go, at least writing
posts is quick and easy with the approach I’ve tried to enforce through these different implementations.
And that, after all, is where I expect to have my “big win” when my page has finally been deployed.

In my last post, I was exploring new web frameworks to migrate to, while learning more Elixir.
I attempted a few, but learning a framework can be uphill, especially when not being fluent in
the language. The main frustrating point was not being able to understand the errors I was getting.
They were usually in one, long, truncated line. So not only was it formatted poorly, it didn’t give
me all the information that was intended for me. I didn’t really find a good way of getting better
error information or analyzing the errors I was getting, so finally I gave up… for now.

So I went back to what I know, and I know Objective-C and Cocoa really, really well. And there are
a few webservers for it. I grabbed OCFWeb, thinking perhaps I could add exploration of
Objective-Cloud to the task. This way I knew I would be able to understand the error messages I was
getting, I had a debugger I could set breakpoints with and step through, and I would be comfortable.

With the advice of Christian Kienle I switched my templating language to Mustache. I forked it
to update Mustache to a newer version and still be able to use OCFWeb as a Pod. That worked fairly
well, but of course it’s a new framework to learn, just like all the other web frameworks I’ve tried
so far. It isn’t much used, which means searching the web didn’t give many results, and thus I had
to dig through the source exploring how the pieces fit together when I didn’t understand how to do
something or why it behaved another way than I expected. That, of course, was a good opportunity
to contribute, but it also exposed a weakness with my Cocoa-approach: the recompile-restart-reload
cycle of seeing the results of my changes was rather longer than what I wanted. Of course, the content
could be modified by having it outside of my application, but the routes and logic could not. Or
at least I didn’t think of a way where I could keep it outside the server app.

So for now, I won’t be deploying my website as a Cocoa app either. Coming up next, back to Node.js

My first “real” Elixir project was to build my own homepage with my blog and portfolio. I wrote it using Dynamo. Not the best of choices, since it now recommends I look other places. The options I’ve found so far are:

Project

Commits

Last

Watchers

Stars

Forks

Contributors

Elixir version

Charlotte

71

Sun Mar 2 07:51:01 2014 -0700

4

5

0

1

pre 0.13

Phoenix

328

Mon Jun 16 19:20:17 2014 -0400

46

274

37

23

0.14

Plug

157

Mon Jun 16 11:50:37 2014 +0200

27

98

25

14

0.14

Sugar

161

Wed May 28 23:53:53 2014 -0400

10

75

4

2

pre 0.13

Weber

603

Fri Jun 13 08:11:04 2014 -0400

36

263

41

24

0.14

The four of them depend on Plug, and thus on Cowboy. When I started my work, 0.13 had just come out. A week ago, 0.14 was released, so it’s great Plug, Phoenix and Weber are all updated already. At least as long as all of your other dependencies are at least up to 0.13, anyway, if not they’ll probably be broken now.

So, since I’m getting Plug anyway, do I want it the Phoenix way or Weber way? By reading their README.md, I don’t really have a preference. They seem to be very similar. Both have one main maintainer, two “leutnants” and many with a commit or two. Both have one-digit open issues and 3-digit closed issues.

When it came down to “mix test”, Phoenix had significantly more tests, and they gave no warnings, where I had 25 warnings when running Webers tests. So with lots of probably insignificant data points, this was the one that tipped the scale to let me try out Phoenix first.

However, my run with Phoenix was short. I had expected to be able to reuse my .eex template files from my Dynamo project, but there was just no documentation or examples to support this. Not even an itty-bitty template file in the generated scaffold. I could see from the dependencies that there is support, but it looked like I would have to do quite a bit of work on that on my own.

So I tried out Weber. Generate the scaffold and launch. Fine, there’s HTML on launch and it seems to be taken from a view file. The HTML includes a link to the Weber site, which is 404. Now that is reassuring…