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:

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…