Phoenix LiveView 1.2

https://phoenixframework.org/blog/phoenix-liveview-1-2-released

by ksec • 1 month ago

203 58 1 month ago

cpursley5• 1 month ago

LiveView is such a breath of fresh air, especially over the vibe coded NextJS rats nests that have become the norm (that need specialized hosting, are dog slow and require a ton of proprietary paid services bolted on like caching, background workers and even auth which Elixir and Phoenix provide out of the box).

https://elixirisallyouneed.dev

Tinkeringz• 1 month ago

What caching is provided out of the box for Phoenix framework?

conradfr3• 1 month ago

Doesn't seem to be mentioned in the page but if you're talking about request caching there's libraries like PlugHTTPCache or RequestCache.

Otherwise I usually use Nebulex (annotations are nice for Ecto queries) with ETS as it's faster than with Redis (if you don't care about losing the cache on deployment).

cpursley5• 1 month ago

Out of the box in Elixir/Erlang, Phoenix is the web framework layer.

solid_fuel• 1 month ago

There's options, what do you want to cache? One thing to keep in mind is that with LiveView, there is a live process on the server side while the websocket remains connected.

That means that many small things, like fetching user permissions, do not need to be performed again on every single request like a more tradition SPA application would require. Instead you can perform them once when the user connects and then simple store them in the LiveView process. That process can also subscribe to PubSub notifications for changes, which provides a cache invalidation method.

Effectively, a LiveView process functions as a tiny dedicated cache for any given connected user.

AdamConwayIE• 1 month ago

I've been loving LiveView. Been using it for a project for a client recently and it's so... chill. I like it a lot.

Traubenfuchs• 1 month ago

specialized hosting

What do you mean?

My private next.js fullstack slop runs dockerized on my kubernetes cluster and for auth I use auth0, because I am too lazy to run keycloak or whatever dockerized auth slop is currently en vogue.

cpursley5• 1 month ago

It's possible but most default to vercel and it's required if you want the fancy stuff (hybrid). And you made my point, Kubernetes is overkill as well.

Regarding auth, in phoenix it's literally as simple as "mix phx.gen.auth Accounts User users" and boom, your users live right in your database for free.

candl• 1 month ago

What are the pros and cons compared to ASP.Net/Blazor?

weatherlight• 1 month ago

The BEAM virtual machine. Its has lightweight isolated processes, message passing, supervisors, hot-ish runtime introspection, and fault containment are not libraries bolted on later. They are the substrate. not an after thought.

if you are build an app that needs the following: + many concurrent users + real-time UI + background jobs + workflows + stateful sessions + distributed events + failure isolation + “this thing should keep running for months”

You're going to want the thing built on the BEAM.

zerr3• 1 month ago

But it doesn't have neither AOT nor JIT.

rubyn00bie3• 1 month ago

TLDR; LiveView is web only.

There have been efforts to make LiveView native, but it’s extremely difficult to do so, and thus far (to my knowledge) all have failed.

I was thinking about this the other day because carsandbids (Doug DeMuro’s car auction site) uses Blazor (at least as far as I can tell). And I think that’s one of its biggest advantages of Blazor—- is that it is capable of producing native apps and web apps while LiveView is resolutely not. And that’s because Microsoft can pay for it (or at least sponsor huge amounts of supporting infrastructure).

And FWIW— that’s an extremely difficult problem to solve. It requires an enormous amount of funding, both a huge team capable of both understanding Android and iOS SDKs and capital to employ folks on pure engineering challenges (hence why MS or Meta can). End users don’t care if it’s made with LiveView, Blazor, React, Java, SwiftUI, et. al. And, the list of companies that can facilitate that long term is extremely small.

There’s also the issue of OTP being non-trivial to implement or meaningfully transpile into another language/runtime. Erlang, BEAM, and OTP were made together for each other in a very peculiar and specific way, for a specific set of problems, and if it wasn’t a necessity that they were developed together it would be a dead language, runtime, and platform (and for the record it’s absolutely not).

cpursley5• 1 month ago

Why not just build mobile apps in their native language (Swift etc)? Anyways, end users absolutely notice and care - cross platform mobile apps are all hot garbage without exception.

cyberpunk• 1 month ago

I am a fan of the idea, but the websocket is also quite a big attack surface; you can do a lot more by sending messages over this socket to your phoenix app than you would likely expect to have exposed via some api on another framework.

It’s difficult to secure, in my opinion. Perhaps not impossible but the cost of doing so pretty much eclipses the benefits of using liveview imo.

noodletheworld• 1 month ago

Many people love liveview.

Many people dislike blazor and it has had its reputation sullied by Microsoft treating it as “new webforms” (yes, they do. It is literally the official migration path for legacy webforms projects).

The pro of blazor, arguably, is c# and the .Net ecosystem.

If I personally had to choose, I wouldn't choose blazor over almost any other technology because I’ve had bad experiences with it.

Technically, they're very similar, but the devexp matters, in my oppinion.

rubyn00bie3• 1 month ago

I’m not sure how I feel about the CSS integration. Nor the collocated JS that was somewhat recently released.

On one hand, yes it is convenient, but on the other it could become a huge mess. It reminds me of Rails 2.x where it became almost impossible to debug, or fix front end code that used rjs or whatever it was called. Because disparate snippets of JS were littered throughout your code base in files that were hard to find.

I’m sure the Phoenix team has put a lot of effort into it, and I truly hope it slaps. I myself am just really hesitant to use it, when CSS files and non colocated JS work just fine. I’ll probably be waiting a couple years before giving it a try

conradfr3• 1 month ago

To be honest that's copied from the JS frameworks. I tend to agree with you but sometimes scoped CSS is nice to have.

GCUMstlyHarmls2• 1 month ago

I quite like the colocated JS. I much prefer to define a components "hook" code inside the component. I think you could abuse it, I would never put colocated JS just in some template to include it "just to avoid writing a js file" but for keeping `email_validator.js` code right next to the `email_input` component, its quite nice I think.

The nature of them being basically forced to inherit the module name means its pretty obvious that `MyAppWeb.Admin.Components.EmailValidator` is in the `MyAppWeb.Admin.Components` module. I also think it probably strongly depends on how much JS you actually have, most of my liveview apps have it "here and there" to enhance something or minor DOM fiddling, if you are booting react components everywhere and have some other pile of existing js code, its probably not so good.

paradox4602• 1 month ago

Surface, vue, and svelte have all have colocated css and js for ages. It usually results in easier to maintain code, without having to resort to unsolutions like tailwind

Global styles can still be global, but component level styles stay at the component level

orliesaurus• 1 month ago

I've been using Phoenix for super basic things for a very long time since I first discovered it at the Elixir meetup in ATX.

I haven't touched it in a while, Since writing code these days, as most of us know, it's basically steering an LLM.

So I wonder how good are LLMs at writing Phoenix or Elixir so to speak? Time for me to create another side project... and figure it out.

johnisgood• 1 month ago

They were pretty good a year ago, so I am sure it is even better than that now.

cpursley5• 1 month ago

I'd argue that it's one of the best, especially with Tidewave:

https://dashbit.co/blog/why-elixir-best-language-for-ai

avanwyk• 1 month ago

I've built several production quality, mid-sized apps in Phoenix/Elixir over the last year using Claude Code (CC). In my experience, it's great, I had better results with this stack than I had with Django when using purely CC. It's token efficient (because of code generator), has great static analysis, and terse (because functional). Phoenix even generates an Agents.md The apps themselves are highly scalable and look great.

Checkout https://github.com/oliver-kriska/claude-elixir-phoenix (not me).

thibaut_barrere• 1 month ago

LLM use is very solid here. I have been shipping some fairly cool stuff for different clients, just like if I was managing a team of 3 or 4 people.

The stable nature of the language, and the static/immutable nature of constructs, presumably really helps moving safely here.

ricw• 1 month ago

It works great for a number of reasons

- it’s functional making it much easier to reason about for LLMs (eg no side effects)

- it’s compiled (including the html template), so the LLM get instant feedback if something is off and can fix it quicker

- it’s more concise than other frameworks (language, framework, no front/backend split) and consequently you hit the max token limit much less frequently

- it has excellent tailwind support

I told a business partner to just use claude for certain tasks a year ago, and it failed miserably in python where it succeeded in elixir/phoenix liveview. This was a regular occurrence. LLMs have obviously progressed since, but the principle still stands that they work much better in elixir than python.

So in short: it’s great and arguably better than most other languages and frameworks

joshspankit• 1 month ago

I’d like some confirmation if possible, but my gut says the general internet (and therefore the training data) probably has a lot of sloppy Python code along with a lot of sloppy writing about Python whereas Phoenix has majority good code and well-reasoned writing

ch4s32• 1 month ago

It’s exceptional. We’ve improved throughput on new features by about 2x and sentry errors are down. Our codebase is 2-300k loc and pretty old in some places, I’ve been really impressed with just sonnet.

scwoodal• 1 month ago

Pretty good as others have mentioned. Even more so when one starts adding packages like credo, ex_slop, and boundary to run deterministically and steer the LLM.

Don’t like a pattern that LLM introduced? Write a custom credo rule and the problem doesn’t come back.

IAmGraydon• 1 month ago

Worth checking out...

https://phoenix.new/

lwouis2• 1 month ago

I like this familly of technologies. Having an SPA-type app that's mostly backend.

Recently i've redone my app website (https://alt-tab.app), and I implemented a minimal spa.js that has a similar approach. I find the end result blazing fast, simple to maintain / reason about, few moving pieces. I used Early Hints, compressed every single thing, inlined CSS, etc. I don't know how i could even make it faster.

I recommend this approach for websites that are not very complex. Of course if i made a browser-based music player with a super dynamic UI, that would have been a different story~

sebmellen• 1 month ago

Very cool concept with AltTab. Have always been looking for something like it!

Intermernet• 1 month ago

Can't the website be literally static HTML for 99% of it? I don't really see any user defined input that would change the output.

It's really fast, and seems fine, but is it just static pages? If not, why not. That's the question most front end devs don't ask themselves enough.

epolanski2• 1 month ago

I don't really see any user defined input that would change the output.

I feel like the distinction between static websites and SPAs has been lost in the last decade, despite it being in the name _single page application_.

The point of SPAs is not "it's more interactive than a static website is", but "I don't need to fetch the new page and wait it to load as I navigate". You can have any custom behavior just by adding JavaScript. That's something we have from 30+ years.

"applications" don't interrupt the user as you navigate, and we tried to replicate that on the browser, by having history and render JavaScript controlled.

lwouis2• 1 month ago

I think it seems logical on paper. I tried it, and it feels perceptually way worse. It also think it's objectively slower.

When you go from HTML page to HTML page without JS, the browser starts from scratch on every page. The user gets a big flash, then the browser has to redraw the page from scratch. It's actually a lot of work often.

If the browser expected pages to be similar, and added optimizations to reuse existing content, essentially doing internal SPA work, that would be a different story. To my knowledge, the browser does no such optimization, and brute-forces renders every URL from scratch.

You can actually try for yourself on the website I linked. Chrome devtools > disable Javascript. It's a pretty good experience still since I optimized everything. However, you see all sorts of things flicker and move around. It's not the smoothest experience. And If you have worse Internet, it gets worse and worse as you see more of the tear-down > built-up on every click. With the SPA experience, if you have bad internet, you can still scroll around and use the page, as you wait for the update to arrive.

Of course, you're totally right that static HTML works pretty good when the website is already simple and fast. My point was that with 4KB-uncompressed / 140LoC, I can get the smoothest experience. And I unlock options later on like having loading spinners for example.

My general point was that you can do simple client-side rendering in 140 LoC. You keep a simple backend-served website, and add a little polish this way to have a smooth experience.

I find it very cool to have polished app-like experience, while having a simple backend to serve. I like the low-tech, few moving pieces, yet I get options for great UX if I want.

I got charmed by this path with LiveView and Hotwire back in the day. I'm thankful that people continue to push this approach. It's wonderful

OhSoHumble2• 1 month ago

Oh, the alt tab developer! I actually love your product.

giovannibonetti2• 1 month ago

For those of you a similar SPA-type app with more type safety – which is even more useful for writing code with AI – you may want to have a look at the Gleam language and the Lustre web framework [1]. It combines the best of Elixir and Elm. You can mix and match having more logic in the backend or the frontend, as Gleam compiles both to Erlang and to JS.

[1] https://lustre.hexdocs.pm/lustre/server_component.html

kajman• 1 month ago

I really wanted to like Gleam because the Rust-like syntax and static types looked familiar and robust, but seeing how Lustre does HTML templating versus how Phoenix does Heex was my deciding factor to try the latter. My understanding is this is because of a current lack of any macro system.

I probably didn't give it a fair shake, but it all looks very early days, which isn't for me. Kind of a shame, because the dynamic types are still kind of driving me up the wall in Elixir. Elixir structs and dialyzer type specs feel so much worse than what statically typed languages provide.

princevegeta89• 1 month ago

Dude thank you for making AltTab. Recently you've introduced the pro version and paywalled some features behind it. That's totally fine and I bought the pro version but my honest 2c for you is...25 bucks for a window switcher app seems too high. Please make it 15 or less. Thanks

OhSoHumble2• 1 month ago

I'm pretty smitten with Phoenix as a framework. A lot is built into the BEAM by default and the Elixir ecosystem is quite lovely.

I've been building an Etsy-lite replacement in my free time with it: https://plukio.com/

It's pretty enjoyable. I also like using Ash for data modeling and business logic expression. It's also quite lovely.

moritzwarhier2• 1 month ago

I wanted to try out Erlang + Elixir since forever, do you think Phoenix LiveView would be a good starting point? For example, to create something like a simple game with modest persistence and only very limited RT-features? I was thinking about sth like a quiz app, not a web MMORPG of course :)

Or is LiveView only useful to optimize partial page reloads and SEO?

projct• 1 month ago

LiveView is perfect for that. one of the easiest to understand demos of it is actually something just like that.

that said liveview is capable of 60fps server-rendered animation, so it's definitely not just for speeding up page loads.

paradox4602• 1 month ago

Years ago I used surface ui's colocated css to great effect. Super happy to have it incorporated into mainline live view

Phoenix LiveView 1.2

Related Stories