Phoenix 1.7 for Elixir: Edit a Form in a Modal

I see this same issue with htmx and other takes on SSR.. just because you can dynamically update the HTML doesn't mean you should make EVERYTHING dynamic. It's okay to have normal page transitions. It's okay to do something dynamic. It's okay to to toss a little plain ol' JavaScript in there if it's simple.

I strongly agree with you.

I'm fairly involved in Elixir, so I run a risk of catching some frustration for agreeing with you here.

I get why they are going the direction they are, but I think it comes at increased complexity for beginners (that don't want to use LiveView). For example, Phoenix components (which are usable in static server-rendered controllers) live in phoenix_live_view package.

All of that said, Elixir / Phoenix is the best development experience I've ever had and I have no plans to stop using it.

I recently started to only use liveviews for any page. Yes, I could do a simple controller/template combo, but then after some time comes the feature request for some interactivity, and I have to convert the page to LV manually. Or something like the global navbar needs some dynamic thing, and here you go: either embed a LV in the static page or... do nothing since all pages are LV to begin with. The overhead is pretty minimal IMO, a simple LV that does nothing is a few lines of module code, not much more than a controller route. And by standardizing this (no more deadviews), pipelines/plugs can be simplified, and live_session for seamless navigation becomes much better. Phoenix Deadviews render within a few MS, but still a live_navigate is snappier.

What is "TFA", please?

It's like that piece in Fantasia where the apprentice (Mickey) gains the wizard's powers, then loses control as all hell breaks loose. It's a powerful new tool, but there's a time and a place for it, and I believe that the tendency towards LiveView-everywhere should be balanced against pure practicality. I look forward to a future in which the boundaries of the paradigm are more well-understood, and the models of when and how to use these tools are more fleshed-out.

Also, I agree with your heuristics. It is untenable to make a round trip to the server for things that can be done purely on the client side. Alpine.js is great for managing purely client-side stuff IMO (as are LV hooks, although I haven't used them too often), but they don't really mix well, and Alpine seems to have fallen out of favor lately with the Phoenix crowd as the complexity of people's projects starts to reveal the cracks in the paradigm.

To add to your heuristics, the `phx-loading` attribute should be used when possible to notify the user that 1) yes, you made the action, and 2) we're still waiting for a response.

100% agree, and it's scary.

By the way, did something like activeadmin pop up?

I kind of agree with you, and LiveView is not even 1.0 yet (it should have been before the whole components thing IMHO).

I also think they kind of jump the shark with the core_components.ex tied to Tailwind.

Out of interest, what book was that?

I've had a brief look into the ecosystem, but I found it quite hard for me to understand how a multinode Erlang cluster is setup.

> Does this stack really put everything under the sun to shame?

Yes. I'm a .NET guy by trade and I've poked around Elixir/Phoenix a bit. I wish this stack (and its concepts) would gain some popularity in the enterprise so we could get rid of microservices and SPAs entirely. 99% of companies don't need Microservices, they solve problems they don't have at costs they shouldn't have to pay (velocity, complexity, etc.) SPAs could go away for most LOB apps with Phoenix Live, Blazor (.NET), or even just classic server-side web apps + Htmx.

Not everything of course but for the sort of network-based soft low latency uses web apps are built around yes pretty much. Even within its domain it has some weaknesses but their contours and mitigations are well understood. OTP is venerable and proven.

If you're ever looking at microservices as possibly a good idea you should definitely consider "can I just do this in erlang." Usually the answer is "yes, but no, because of company politics" and those hurt a lot once you know what you're giving up.

BEAM is overall inferior to Kubernetes in terms of features, also BEAM only work with Erlang, so what do other languages do?

I think it's bad design to have your runtime handling those kind of problems, a generic scheduler should be, not the runtime of your language.

> Does this stack really put everything under the sun to shame?

I feel like protobufs are an improvement to Erlang serialization for talking to possibly older versions of things.

k8s is meant for frameworks and runtimes, like Rails, that don’t have any real concepts of processes or clustering.

I think of Elixir as a way to get full control of the stack in one runtime. It has process management and clustering built right in, which is kind of redundant with everything k8s offers. It gives you so much control over so many things with one runtime and language.

Contrast that to a runtime like Ruby/Rails where it’s “run a server process and don’t attempt anything outside of that” — k8s can actually be helpful for process management, clustering, and service discovery because doing so in Ruby would be a huge effort that requires cobbling the Ruby, Linux, and k8s things together that you just don’t have to do in Elixir.

it does[1].

- A phoenix application basically can be seen as a "microlith": monolithic codebase (even with umbrella setups!) and during runtime there a lots of independent processes that scale over clusters of VMs, where partial failure doesn't neccessarily affect the rest. So no truly independent deployments of microservices, but most advantages of the pattern, without HTTP-API overheads or similar, since sending messages between processes is a natural thing to do anyways.

- Liveview extends that by connecting a client with the VM via websocket, where there is only a minor difference between receiving a message from another server process or from the client (handle_info vs handle_event). The data/state lives completely in the users' backend process, so much less cognitive overhead about getting data into the client, you actually don't even think about this topic. Also no JS blobs that get bigger with increasing amounts of pages/components or clever splitting + latency compensation of prefetching, and the SSR performance is spectacular, and also free (see the complexity of ReactServerComponents) and no thinking about the whole topic while doing LV.

- under demanding pressure, the VM behaves optimal for a web app actually. Every LV is its own process on the server, every "thing" ultimately lives in some process, and its all supervised by other dedicated processes that do automatic restarts/... in case of failure, sometimes called "self-healing". Erlang was the original system actually achieving the nine-nies of uptime. Garbage collection is also on a per-process level, not a global stop-the-world thing, with short-lived processes cleaned right away without the local GC kicking in. And the VM itself does aggressive preemptive scheduling. This translates into: quick http responses stay quick even under load, but long-running jobs run even longer when there is pressure - exactly what you want: not blocking visitors' experience with crunching jobs.

- the database story is exceptionally great, you have schemas and separate functions to do stuff with data (validations/...), not a coupled thing like ActiveRecord models - I can have different changesets/rules per usecase on the same schema easily. Can also be used for casting JSON responses, and supports embedding document-like structures (with schema/...) into postgres natively.

- many problems you would reach out for external services to solve have native built-in equivalents. IE you don't need Redis, since there is the built-in (D)ETS. which also is objectively better than redis for caching needs, since there is no serialization overhead between service boundaries, and native language structs are used for keys/values, not just strings, and it can be queried/matched with full power. When you know your full Elixir toolbox, your app becomes much simpler on the highlevel (architecture/infrastructure) and more convenient on the lower (code) levels.

- Everything[2] is packaged up (i believe) in an industry-leading level of polish and quality, from exhaustive docs, awesome testing tools built-in (ExUnit for liveviews is dramatically better to use than something like cypress and getting app configs right for testing modes and you have the fullstack integration testing level by default easily.

- the data processing/ML story is generally great and is quickly catching up to python levels, and the unique capabilities of the VM itself unlock tools like Broadway to build data pipelines to feed into things like ML models. Speaking of, some algorithms like NN have great native libs now, there is a adhoc integration with huggingface (bumblebee), and last but not least some things like evolutionary algorithms are great to design with OTP constructs.

- the language itself is as powerful as a lisp in practice, the only noticable exception being its not homoiconic so you need quote/unqote for macros and AST stuff, but also there are less brackets. But everything you see is a macro ultimately, even defmacro is a macro. create your own DSLs with ease if needed.

---

as a downside, deployment is more complex when you want to leverage the distributed nature of some native features, but you don't need to in general, you can also deploy it like any other ruby/django app iE with a dockerfile and loadbalance it traditionally. Also there is a learning curve in general, since all this stuff _looks_ alien for many devs not used to it, and there are features that don't exist at all in more mainstream languages.

---

[1] except for raw compute tasks, when even Nx doesn't cut it, but then there is rustler for native extensions which works reasonable well!

[2] except for liveview itself - the docs are there but cluttered over many places, and not really within phoenix itself but as an external lib, and there has been lots of changes over time.

How does Erlang/OTP handle auto-scalup and scale-down ? k8s offers that.

Maybe something like fly.io?

I know they support Elixir/Phoenix.

https://fly.io/docs/elixir/the-basics/clustering/

In my experience, deploying BEAM has been just as easy as anything else I can containerize.

WRT getting them to communicate? I ended up giving up on that altogether…

I’m usually good at figuring that stuff out but this one ended up not being worth it (in my case).

We deploy Erlang VMs to EC2 and they communicate just fine. Deploying via a Dockerfile and `mix release` has been a breeze.

As a bonus point, no real need for container orchestration as the BEAM just figures it out.

The answer for any language is just to stick it in a container. Elixir fits inside a container, and the Phoenix generator creates a Dockerfile for you out of the box.

You can host Elixir apps on PaaS like Gigalixir[0] or Fly.io[1] (no associated with these).

I personally use mix release[2] that assembles a tarball of itself (together with BEAM), then rsync that to Hetzner, restart the remote process and viola. I like simplicity.

Re cluster of nodes, the easiest would be to use a library[3] to automate the formation of said cluster.

[0] https://www.gigalixir.com/

[1] https://fly.io/docs/elixir/getting-started/

[2] https://elixir-lang.org/getting-started/mix-otp/config-and-r...

[3] https://github.com/bitwalker/libcluster

> Is there easy tooling for deploying to something like AWS ECS and having nodes communicate with each other?

libcluster[0] has a bunch of strategies to form clusters. It seems that ECS supports service discovery through DNS, so the DNSPoll[1] strategy should work.

[0] https://github.com/bitwalker/libcluster [1] https://hexdocs.pm/libcluster/Cluster.Strategy.DNSPoll.html

You already got good answers, I'm only going to add that you can also integrate the self-contained `mix release` final build production artifact with systemd just fine. I've done it.

As an aside, Elixir is doing some interesting, novel stuff exploring its own type system. José Valim's keynote at ElixirConf last week went into detail on the topic, so I'd keep an eye out for it on YouTube in the coming weeks if that sort of thing interests you.

I would say it depends on the kind of app you are building.

Your link says at the bottom that modals can be used for forms.

You may be aware of this already, but the current LiveView generators address many of these concerns by serving the same LiveView template for multiple routes, but the assigns will be different based on which route is accessed. So, for the :index route, the modal will not be visible, but it will be visible for the :new route. Plus, with live patching, you preserve back button functionality (and it even preserves the page state as a bonus). So that addresses the back button problem.

But the problem still exists where clicking outside the modal (or pressing the back button) will destroy the form and any unmodified content, which is super annoying. This can be addressed by listening for changes to the form's input fields and showing a warning when any navigation event occurs when the form is changed-but-not-submitted (easier said than done, but ).

I'm not even disagreeing with your point, really. It's just worth mentioning that 1) many of the problems described have an out-of-the-box solution when using the current LiveView generators, and 2) refinements can be made to address some of the remaining issues.

Thank you for your sanity on modals. They are horrible on mobile devices and not necessary in most cases.

I'm not super active in the ecosystem but Elixir+Phoenix is a true joy, the community is great. The community is also great. Depending on your use case LiveView may or may not be a game changer as well.

It's my goto for any hobby projects these days (used to be Django).

We've been using Elixir + Phoenix in production for about 5 years and I really like the ecosystem.

Phoenix has undergone some bigger changes with recent versions due to the Liveview development, which were a bit annoying to keep up with but in general, everything is very stable and well documented.

Elixir in general is one of my most beloved ecosystems in terms of develper productivity. - Opinionated, configurable formatter, type annotations and checking, very good test and doc tools, awesome community...

It's everything I know from the Ruby + Rails community years ago but dialled up a bit. I haven't done much Ruby work in the last 5 years so I can't provide a direct comparison but I always felt like you really feel the extra 10% of polish Elixir has over Ruby due to the core teams strong involvement in tooling and developer experience.

The only even more streamlined experience for in recent times was Flutter (as long as you don't stray too deep into ffi/native code)

I switched from Rails to Phoenix a few years ago and have never looked back. It solves basically all of the frustrations I had with Rails (see e.g. Peter Solnica's writing [0]) and is truly a joy to work with.

If anyone else is thinking of switching from Rails to Phoenix then I humbly recommend my course Phoenix on Rails (http://phoenixonrails.com/). Sorry for the self-promo, but if you use the code HIT8RUN (valid for the next 48 hours) then you can have a 10% discount.

[0] https://solnic.codes/2016/05/22/my-time-with-rails-is-up/

Big fan of both Rails and Phoenix. I use both situationally.

One random concrete example I found while playing with Hotwire is that if you need a full PWA, it's much easier than in LiveView. With Hotwire it JustWorks(tm) while with LiveView it's a giant pain as you have to double up events with controller actions (which is terrible). If you don't need this, though, which many don't, LiveView is cognitively easier simpler its DOM-diffing as opposed to Hotwire's frame-targeting mechanism. To be crystal clear, I'm not saying that targeting frames is hard, just that's it's even easier not have to have to do it at all.

Yeah, I agree. Building a really nice slide over is surprisingly hard.

At the time of me writing this comment it had 9 points after 8 minutes. I guess the ratio of points/time_since_posted is more important than the absolute points.

From the FAQ:

> How are stories ranked?

> The basic algorithm divides points by a power of the time since a story was submitted. Comments in threads are ranked the same way.

> Other factors affecting rank include user flags, anti-abuse software, software which demotes overheated discussions, account or site weighting, and moderator action.

So if a story gets points very quickly, it will appear on the front page. If it don't keep getting points it will disappear.

Elixir-related stories hit the front page of HN several times per week. It seems to be a topic that the HN audience likes to upvote.

Moderators sometimes put something on the homepage. HN is a little bit curated, it's not just upvotes.

It’s probably the same force that drove Phoenix to be at the top of this year’s Stack Overflow Developer Survey of “Most Admired Web Frameworks”: https://survey.stackoverflow.co/2023/#section-admired-and-de...

Don't quote me on that but it's pretty crude: if it receives N upvotes in a short amount of time, it's promoted to the frontpage quite quickly. If it takes two hours to get the same number of upvotes, it probably gets lost in the neverending ocean of /new.

So it's basically a game of pure chance, a topic that's not too niche, a topic that one upvotes without even reading, and/or good clickbait technique.

HN's algo optimises for popularity, rather than meaty content.

Fly.io is involved with YCombinator at https://www.ycombinator.com/companies/fly-io. One of the core contributors of Phoenix also works there and Fly.io tends to tie in with Elixir as a language.

I'm just speculating here but I think a number of posts are curated to land on the home page when you're directly or indirectly related to YCombinator funded companies.

LiveView Native is exactly that and being worked on by DockYard. https://native.live

Really interesting read! I was always curious about Elixir but we've been using kotlin in the backend for years now an I'm really happy (except the JVM and spring bullshit stuff). The language tho is on another level. Lot's of compile-time safety and syntatic sugar. We're really productive with that.

Elixir+Phoenix does web stuff very well, with little maintenance required (i've upgraded 4+ years old project in two ot three days, time mostly spent on upgrading some 3rd party libs that bumped major version). Unlike ruby, it's really easy to understand what's going on (no hidden state, all variables are passed explicitly, imports are stored in one file (in phoenix) you can look at or explicit as well.

With added LiveView on top, you could avoid writing a lot of SPA react (vue, svelte etc) code (some limitations apply, but you can do a lot), spending less people, time and resources for the same result.

Traditional setup: backend logic + backend api + react SPA + logic for calling backend api

LiveVew setup: phoenix backend + LiveView views + a bit of glue code (in elixir) to replace onclick etc stuff

I can't speak for other companies or devs, but as a relatively junior developer I quite enjoy working in Elixir, and especially with Phoenix and the Ecto ORM.

The syntax reads and writes very well. When I now have to write other languages, mainly Typescript, I miss native pattern matching and the pipe operator.

Plenty of languages can get a solid standard library to write most code with, but only elixir gives you a modern, simple standard library with the tools to scale an app as high as apps can be scaled.

Whatsapp famously got to 1 billion messages a day with only 11 engineers on the BEAM (the VM that elixir runs on). It has proven itself immensely capable at the highest levels of scale so the only thing for anyone to decide is whether the stdlib and tooling is to their liking (speaking mostly in the context of networked IO bound applications, which is most things on the internet)

"many" not really.

Elixir is bolted on top of erlang so reading error stacks with erlang is common, needing to grok erlang concepts and docs is also sometimes needed. This makes it odd to work with. I know if I'm using a Java, Ruby, Python or PHP framework (django, laravel, rails, whatever latest java web framework) I can read thru docs or source code and troubleshoot stack traces without having to learn another language. Its unavoidable with Elixir beyond simple apps.

We (Mirego) made the move from Rails to Elixir years ago for three main reasons: productivity, maintainability and performance → https://shift.mirego.com/en/elixir-functional-programming

My understanding from talking to some former Brex developers was that the switch was entirely because Kotlin is the CTO's favorite language and everything else was just a post-facto justification. So take it with a grain of salt.