Is there a super-simple phoenix web framework alternative?

I’m wondering if there is an Elixir web framework that is basically just a router and some templates. I’ve noticed that with Phoenix I just feel like I have too many files and one extra layer of indirection through everything.

I don’t quite understand why the templates/ folder is not stored under the views/ folder for instance, since templates are just compiled into those view files, or even why the view files really exist at all – seems like they’re often just empty and play no role other than to follow a naming convention based on the controller.

I think Phoenix is aiming to be powerful enough to drive the most sophisticated current users of Ruby on Rails, but I think there is also a space for those who just want little toy websites, demo apps, examples, etc, and don’t need the extras that Phoenix provides.

You can always use Plug + Plug.Router and setup your templates the any way you like.
Here is an example from elixirschool.

@template_dir "lib/router_example/templates"

defp render(%{status: status} = conn, template, assigns \\ []) do
  body =
    @template_dir
    |> Path.join(template)
    |> String.replace_suffix(".html", ".html.eex")
    |> EEx.eval_file(assigns)

  send_resp(conn, (status || 200), body)
end
4 Likes

Plug is great, as suggested by cpgo.

If you want simpler still check out Raxx

https://hexdocs.pm/raxx/0.10.1/readme.html

4 Likes

I don’t quite understand why the templates/ folder is not stored under the views/ folder for instance

The purpose of a view is to take in data from a controller and render a template with it with whatever additional presentation logic is required. Rails takes these two concepts and mostly mashes them into one calling them “views”. I say “mostly” because combining these means there is no place to implement presentation logic, so they provide “helpers”.

Ah helpers… the dumping ground of so many rails apps I’ve worked on. And a lot of time presentation logic just ends up in the “view” itself! This is such a problem that such gems as draper and presenter came about. You could kind of think of these gems as the Phoenix’s view and Rails’ views as Phoenix’s templates.

I imagine Rails chose to combine these because a lot of time we don’t need additional presentation logic right of the bat. It also means helpers can be shared between view and controllers (which is of dubious utility). But it’s inevitable that anything more than a toy project is going to need additional presentation logic, so Phoenix points us in the right direction by giving us a proper view → template mechanism, forcing us to create a view even if sometimes we aren’t going to need any presenters.

12 Likes

You can make it have less files:

 mix phx.new my_api --no-webpack --no-html --no-dashboard --no-gettext --no-ecto

or

 mix phx.new my_simple_web_app --no-webpack --no-dashboard --no-gettext --no-ecto
5 Likes

You already got the technical reason: Views hold the compiled functions for rendering those templates. Without the view modules those templates would just be files sitting in your project with no way to use them. So while those view modules may seem empty they for sure don’t stay empty if there are templates for it. That would be more obvious if phoenix wouldn’t hide all the template loading code behind the use MyAppWeb, :view, ….

Also while for html based pages one often uses templates this is not at all the case of e.g. rendering json. There the composition of the output format usually takes place in those view modules directly. Not every format out there lends itself to templating being the prefered method of construction. In phoenix both are cleanly supported by having views be responsible to turn data into some response format, while only the view layer is concerned with the distinction between rendering the format from code or from a template.

6 Likes

It’s also worth pointing out that one of the great things about Elixir is you can pretty much move your files anywhere. I gather all my files together by resource, rather than by type, like:

posts/
  post_controller.ex
  post_view.ex
  templates/
    index.html.eex

Moving the templates just requires a change to the view function in MyAppWeb:

use Phoenix.View,
  root: __DIR__,
  path: "templates",
  namespace: MyAppWeb
5 Likes

there is also the ash framework https://www.ash-elixir.org - still in alpha though…

4 Likes

Just wanted to reiterate how great Plug and its documentation really is. Frameworks are great at handling the middleware leaving the developer to focus on strictly application logic but we miss out on a lot of knowledge. Plug on the other hand requires you to dig a little deeper when setting up your stack. It doesn’t force you to implement any RFC specs but you still need to be cognizant of some of the layers. I’ve done a few side projects to test it all out and I usually setup a pipeline with Plug.Builder — Plug v1.11.1 which includes all of my plugs (session, csrf, etc) and the router plug Plug.Router — Plug v1.11.1 as the last entry. I then use the router just like a Rails application essentially passing the conn down to a “controller”. From there you can be your own guide for view logic.

4 Likes

If the only thing you need is a router and some templates, I guess a static site generator will do? There’s Still GitHub - still-ex/still: A composable Elixir static site generator which is still alpha, but you can throw some files into a folder, compile it and deploy it to S3/Github Pages/Netlify/etc.

3 Likes