4 ms·

Elixir is great! BEAM and friends is amazing. I think Elixir/Phoenix could use a little bit of Javascript (and modern PHP) enthusiasm to help with adoption - t

Elixir is great! BEAM and friends is amazing. I think Elixir/Phoenix could use a little bit of Javascript (and modern PHP) enthusiasm to help with adoption - this all seems a bit…dry.

DANmode 3y ago
> lecture.md
johnisgood 3y ago
Personally I want to move away from JavaScript and its ecosystem. There is https://hexdocs.pm/phoenix_live_view/js-interop.html https://hexdocs.pm/phoenix_live_view/js-interop.html though. For the record, Phoenix does use JavaScript for its "LiveView"[1], but I think it is optional? At least I remember someone telling me this when I was complaining that generating a basic Phoenix project (using "mix") is too bloated due to JavaScript and such. [1] [...] ./deps/phoenix_live_view/assets/js/phoenix_live_view/view_hook.js ./deps/phoenix_live_reload/priv/static/phoenix_live_reload.js ./assets/package-lock.json ./assets/vendor/topbar.js ./assets/js ./assets/js/app.js [...]
- elicksaur 3y ago
  It uses websockets, which as I understand it, browsers only allow interfacing with them via JavaScript (at least easily). Is there a tech stack/protocol that gets comparable functionality to websockets but without using JavaScript?
- evadne 3y ago
  Phoenix LiveView uses JS because the core of the tech requires the server to compute diffs & the client to patch the DOM accordingly. This is why a JS package is needed alongside the other default package from Phoenix, which brings Phoenix Sockets & Channels capability (which builds on top of transports such as Websocket). Previously have seen: https://github.com/patrick-steele-idem/morphdom https://github.com/patrick-steele-idem/morphdom Can check: https://www.npmjs.com/package/phoenix_live_view https://www.npmjs.com/package/phoenix_live_view
  - johnisgood 3y ago
    For anyone wondering, this is where I complain about Phoenix being bloated[1], and others have informed me that "There’s no JavaScript unless you write it into the template.", and that I can reduce the bloat in this way: "You pass the `--no-assets` flag when using `mix phx.new`"[2] I do not know how true it is today. [1] https://news.ycombinator.com/item?id=31317545 https://news.ycombinator.com/item?id=31317545 [2] https://hexdocs.pm/phoenix/Mix.Tasks.Phx.New.html https://hexdocs.pm/phoenix/Mix.Tasks.Phx.New.html
    - di4na 3y ago
      It depends what you do. If all you want is http requests and assets, no js needed. Being html or api. If you want to handle a websocket and have a 2 way bindings, then no way around it. But that is not phoenix fault. It is the reality of the browsers api. It is pretty minimal js though.
    - ricketycricket 3y ago
      As one of those others, I can confirm this is indeed still true as of Phoenix 1.7. `--no-assets` will not add any CSS or JS to the project other than empty `app.js` and `app.css` files in `/priv/static/assets` for you to fill in yourself if you want. You are completely on your own to implement an asset pipeline of your choosing. Of course, if you want LiveView you will have to bring some JS back in.
sph 3y ago
What? Phoenix is dope because you get tailwind and esbuild without having to run a single npm install, then LiveView does most of the interactivity. My stack these days is just Phoenix, Liveview and a sprinkle of client-side interactivity with Stimulus.js, which is super-simple, composable, progressive (i.e. just add it where you need it) and plays excellently with Liveview. I am designing a super interactive, fully synchronized in real time dashboard with no more than 100 lines of Javascript code to handle: dropdown menus, show/hide burger menu, scroll to top after pagination. Just as it was originally designed, JS should only be the icing on the cake, not the entire buffet. Yeah, I'm so hipster I'm already living in a post-Javascript world. Feels good, man.
linkdd 3y ago
The thing I don't like with Elixir/Phoenix is the code generators. I hate code generators with a passion. They obfuscate the inner workings of the library. Have you tried to find a tutorial which do not use the Mix task "phx.new"? (an up-to-date one). For example, if I need an API, I will pass `--no-assets --no-html --no-live --no-mailer --no-dashboard` and the generator still creates a static files folder and static files related code. If I want the strict minimum, I have to take some time to remove the un-necessary code. Don't misinterpret me, I think Phoenix is a great framework, just like Python/Django, and Ruby on Rails are. But sometimes, I just want Flask/FastAPI. You can say "just use plug_cowboy", but IMHO, "plug_cowboy" is more like "express.js", not really a FastAPI-like framework. Also, absinthe is the only GraphQL implementation that natively supports subscriptions (via phoenix+phoenix_pubsub). In Django (graphene), you need so much more boilerplate with django-channels and yet another library. In JS land, Apollo Server also do not support it natively, you need graphql-ws and a pubsub implementation as well. And most of those pubsub implementations will need a Redis (or whatever) to distribute the queue between multiple web workers, while Erlang/Elixir have been designed for this (which actually simplify your infrastructure). In the end, I often go with Django Async (via ASGI) with Server-Sent-Event (via an async StreamingHTTPResponse) to avoid the complexity of GraphQL subscriptions. But even that, I need a pubsub via Redis to make my multiple workers aware of each other. While with Elixir, a simple libcluster dependency, and a `receive` in the endpoint handler would be enough :)
- sph 3y ago
  I have to agree. I never use generators, and really dislike that authentication is only available with `mix phx.gen.auth`. But speaking of generators, I love this site: https://www.phoenixdiff.org/ https://www.phoenixdiff.org/ — diff your local Phoenix version with the latest one to bring your codebase up to date. I use it every major release to adopt the latest best practices, even if Phoenix has decent backwards compatibility.
  - shakow 3y ago
    > authentication is only available with `mix phx.gen.auth`. What do you mean? You can use other libraries, for instance Guardian or POW.
pbowyer 3y ago
> I think Elixir/Phoenix could use a little bit of Javascript (and modern PHP) enthusiasm to help with adoption Definitely, although as someone who finds that level of "enthusiasm" or fanboism a turn off, I like that it's not there. But it has to be there to ensure the success and growth of the language/ecosystem.
POiNTx 3y ago
Might want to look into LiveSvelte[0]. LiveView by itself is already really nice. LiveSvelte on top of LiveView gets you into JS land for really rich interactive content. [0] https://github.com/woutdp/live_svelte https://github.com/woutdp/live_svelte

Elixir is great! BEAM and friends is amazing. I think Elixir/Phoenix could use a little bit of Javascript (and modern PHP) enthusiasm to help with adoption - this all seems a bit…dry.

DANmode 3y ago

> lecture.md

johnisgood 3y ago

Personally I want to move away from JavaScript and its ecosystem. There is https://hexdocs.pm/phoenix_live_view/js-interop.html https://hexdocs.pm/phoenix_live_view/js-interop.html though. For the record, Phoenix does use JavaScript for its "LiveView"[1], but I think it is optional? At least I remember someone telling me this when I was complaining that generating a basic Phoenix project (using "mix") is too bloated due to JavaScript and such. [1] [...] ./deps/phoenix_live_view/assets/js/phoenix_live_view/view_hook.js ./deps/phoenix_live_reload/priv/static/phoenix_live_reload.js ./assets/package-lock.json ./assets/vendor/topbar.js ./assets/js ./assets/js/app.js [...]

elicksaur 3y ago
It uses websockets, which as I understand it, browsers only allow interfacing with them via JavaScript (at least easily). Is there a tech stack/protocol that gets comparable functionality to websockets but without using JavaScript?
evadne 3y ago
Phoenix LiveView uses JS because the core of the tech requires the server to compute diffs & the client to patch the DOM accordingly. This is why a JS package is needed alongside the other default package from Phoenix, which brings Phoenix Sockets & Channels capability (which builds on top of transports such as Websocket). Previously have seen: https://github.com/patrick-steele-idem/morphdom https://github.com/patrick-steele-idem/morphdom Can check: https://www.npmjs.com/package/phoenix_live_view https://www.npmjs.com/package/phoenix_live_view
- johnisgood 3y ago
  For anyone wondering, this is where I complain about Phoenix being bloated[1], and others have informed me that "There’s no JavaScript unless you write it into the template.", and that I can reduce the bloat in this way: "You pass the `--no-assets` flag when using `mix phx.new`"[2] I do not know how true it is today. [1] https://news.ycombinator.com/item?id=31317545 https://news.ycombinator.com/item?id=31317545 [2] https://hexdocs.pm/phoenix/Mix.Tasks.Phx.New.html https://hexdocs.pm/phoenix/Mix.Tasks.Phx.New.html
  - di4na 3y ago
    It depends what you do. If all you want is http requests and assets, no js needed. Being html or api. If you want to handle a websocket and have a 2 way bindings, then no way around it. But that is not phoenix fault. It is the reality of the browsers api. It is pretty minimal js though.
  - ricketycricket 3y ago
    As one of those others, I can confirm this is indeed still true as of Phoenix 1.7. `--no-assets` will not add any CSS or JS to the project other than empty `app.js` and `app.css` files in `/priv/static/assets` for you to fill in yourself if you want. You are completely on your own to implement an asset pipeline of your choosing. Of course, if you want LiveView you will have to bring some JS back in.

sph 3y ago

What? Phoenix is dope because you get tailwind and esbuild without having to run a single npm install, then LiveView does most of the interactivity. My stack these days is just Phoenix, Liveview and a sprinkle of client-side interactivity with Stimulus.js, which is super-simple, composable, progressive (i.e. just add it where you need it) and plays excellently with Liveview. I am designing a super interactive, fully synchronized in real time dashboard with no more than 100 lines of Javascript code to handle: dropdown menus, show/hide burger menu, scroll to top after pagination. Just as it was originally designed, JS should only be the icing on the cake, not the entire buffet. Yeah, I'm so hipster I'm already living in a post-Javascript world. Feels good, man.

linkdd 3y ago

The thing I don't like with Elixir/Phoenix is the code generators. I hate code generators with a passion. They obfuscate the inner workings of the library. Have you tried to find a tutorial which do not use the Mix task "phx.new"? (an up-to-date one). For example, if I need an API, I will pass `--no-assets --no-html --no-live --no-mailer --no-dashboard` and the generator still creates a static files folder and static files related code. If I want the strict minimum, I have to take some time to remove the un-necessary code. Don't misinterpret me, I think Phoenix is a great framework, just like Python/Django, and Ruby on Rails are. But sometimes, I just want Flask/FastAPI. You can say "just use plug_cowboy", but IMHO, "plug_cowboy" is more like "express.js", not really a FastAPI-like framework. Also, absinthe is the only GraphQL implementation that natively supports subscriptions (via phoenix+phoenix_pubsub). In Django (graphene), you need so much more boilerplate with django-channels and yet another library. In JS land, Apollo Server also do not support it natively, you need graphql-ws and a pubsub implementation as well. And most of those pubsub implementations will need a Redis (or whatever) to distribute the queue between multiple web workers, while Erlang/Elixir have been designed for this (which actually simplify your infrastructure). In the end, I often go with Django Async (via ASGI) with Server-Sent-Event (via an async StreamingHTTPResponse) to avoid the complexity of GraphQL subscriptions. But even that, I need a pubsub via Redis to make my multiple workers aware of each other. While with Elixir, a simple libcluster dependency, and a `receive` in the endpoint handler would be enough :)

sph 3y ago
I have to agree. I never use generators, and really dislike that authentication is only available with `mix phx.gen.auth`. But speaking of generators, I love this site: https://www.phoenixdiff.org/ https://www.phoenixdiff.org/ — diff your local Phoenix version with the latest one to bring your codebase up to date. I use it every major release to adopt the latest best practices, even if Phoenix has decent backwards compatibility.
- shakow 3y ago
  > authentication is only available with `mix phx.gen.auth`. What do you mean? You can use other libraries, for instance Guardian or POW.

pbowyer 3y ago

> I think Elixir/Phoenix could use a little bit of Javascript (and modern PHP) enthusiasm to help with adoption Definitely, although as someone who finds that level of "enthusiasm" or fanboism a turn off, I like that it's not there. But it has to be there to ensure the success and growth of the language/ecosystem.

POiNTx 3y ago

Might want to look into LiveSvelte[0]. LiveView by itself is already really nice. LiveSvelte on top of LiveView gets you into JS land for really rich interactive content. [0] https://github.com/woutdp/live_svelte https://github.com/woutdp/live_svelte