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.
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.
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.
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 :)
But speaking of generators, I love this site: 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.
What do you mean? You can use other libraries, for instance Guardian or POW.
I can argue the exact opposite: you can just look at the generated code to understand what is going on. No magic involved.
> 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.
To me it sounds more like an issue with phoenix rather than with codegen in general. I would expect the static folder to not be generated if we pass the "--no-assets" flag.
Take a look at how django does it. `django-admin startproject` creates:
- settings.py
- wsgi.py
- asgi.py
- urls.py
Even with the codegen tools, you still need to learn what a plug router is, what a phoenix controller/view is, what an ecto repository is, etc...
The codegen tools just overwhelm you with irrelevant code (i'm making an API, why the hell do you generate static files? and why do i need to edit so many files to take it out?)
Another point I don't like about Ecto is that you can't easily switch the database backend depending on the environment.
With django, I can have an sqlite3 db for the dev environment, and a pgsql one for the production. I don't want to run a docker image for pgsql on my machine. I just need to read the DATABASE_URL environment variable, and the ORM takes care of the compatibility. If later on I need some specific pgsql feature, I will have to run the docker image on my computer anyway, but until them please keep the complexity out of my way.
The documentation explains every part of a Phoenix app pretty well.
The code generator is not there to learn you anything. That is your own job.
Adding a controller or schema to results in a small number o f new files. Git commit before you do and you can easily understand what was added.
[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
[...]Previously have seen: https://github.com/patrick-steele-idem/morphdom
I do not know how true it is today.
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.
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.