What's your favorite way to use Phoenix *without* node?

Phoenix Forum Questions / Help
, , ,
1

I’m curious what you’re favorite non-nodejs front-end bits are for Phoenix projects?
No holy wars intended here, just trying to get myself refreshed on what alternatives there are, such as Elm, ElixirScript, etc.

What else is out there, and why is it your favorite? Excited to hear your views!

2 Likes
2

LiveView is the current hotness I believe :slight_smile:

7 Likes
3

True! LiveView is super cool, and I’m sure will make an appearance in most of my projects that have a front-end to them. That said, there are plenty of cases where LiveView isn’t a great fit, and I’d love to still be able to avoid JS wherever possible. :slight_smile:

4

Personally, I’m excited for when Lumen is ready for production and I can use it in my own projects.

5 Likes
5

I’m mostly using plain Phoenix html right now. I used Phoenix liveview for a smaller tool last year, but I’ll very likely look into liveview again when the planned features (especially live link/redirect and file uploads) are released.

6

I don’t think I will ever work on a web app again without reaching for Unpoly, it’s the best and most versatile piece of kit since jQuery came out. 90% of dynamic behaviours in my apps are handled with it, and for more complex components I use lit-element/WebComponents.

7 Likes
7

Just started creating proof of concept GraphQL API with Phoenix and Absinthe, no NodeJS involved.

8

Plain HTML.

3 Likes
9

Unpoly looks pretty neat! Do you happen to have any handy resources for getting it working with Phoenix? I’m remarkably unskilled in getting anything JS-ish to function at all, so I need all the help I can get. :smiley:

10

For me either plain html, unpoly, or drab, depending on the level of control I need to do. ^.^

It’s a drop-in and decorate pure HTML to use javascript library. Look at it’s getting started area, if you have questions feel free to ask though. Most simple case is just dropping the CDN’s script tag in and go. :slight_smile:

1 Like
11

Thanks! I avoid most front-end work like the plague, but need to break out of my box, so I’ll give it a shot. :slight_smile:

1 Like
12

I like Elm. It’s a functional language like Elixir.

The compiler is super quick, it’s error messages are really helpful and friendly, and if it compiles it runs without error. There are a few edge cases where you can still get JS runtime errors, but not anything to really worry about.

It’s pretty simple to set up with Phoenix, just a couple of lines of JS in app.js.

I find it a joy to work with.

2 Likes
13

Right now I like to put my front-end application in a separated project and let my phoenix projects be 100% API driven. I kinda like the hot new React front-end stack, but I’d rather separate into another project that only consumes the phoenix API.

1 Like
14

You can do that with Elm, it doesn’t need to be part of the Phoenix project. Elm compiles to JS, so you can load your Elm app the same way you would load any JS library. You just need a one liner of JS to instantiate the Elm app, and tell it which HTML node to take over.

<script>
  var app = Elm.Main.init({node: document.getElementById("elm-app")})
</script>

One nice thing with Elm, is that you can introduce it gradually if you want. Converting small areas of your page to Elm, until you’re happy and decide to have a single Elm app for each page, or a complete Elm SPA for the whole Phoenix back end.

1 Like
15

I’m not sure why I was trying to over-complicate Unpoly in my head. :man_facepalming:

After having glanced at Elm, I’m not sure I need the level of “everything-ness” it brings, so I’ll tinker with Unpoly some more.

Thanks!

2 Likes
16

Just had a quick look at Unpoly - and the first thing that struck me was the reliance on CSS, and the fact that it’s all just JS - with the usual JS ‘null is not an object’ type errors on the horizon?

Since using Elm, I have been able to rid myself of the problem of managing CSS altogether - no need for CSS at all. And if it compiles, it runs without error. As a functional language it has a lot in common with Elixir, which I like. The cognitive load of switching from front end to back end is reduced. There are differences, obviously, but I’d rather use Elm/Elixir than JS/Elixir.

Not suggesting you’re wrong, I’ve been more of a hobbyist, using Ruby/Rails/JS and now Elixir/Phoenix/Elm to build apps to help run my company. I’m sure I don’t have the commercial experience you have.

I guess I should be an Elm envangelist :slight_smile: I have yet to find a front end problem I can’t solve with Elm.

Oh, and Elm and Phoenix Websockets are a great combination :slight_smile:

17

For small projects that target modern browsers, you can get away with TypeScript without Node/NPM (except for maybe installing the tsc binaries globally). I do that in this Elixir project and this no-backend project. If you don’t have deps (or only a couple), and are comfortable writing some things (like my dom.ts) yourself, then this works pretty well. :slight_smile:

It works because TypeScript compiles your code down to JS modules and modern browsers can nowadays directly use those modules without bundling. So you just tsc and off you go! :smiley: