Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Phoenix LiveView 1.2

phoenixframework.org

Post reply on HN
Print view View original

31–40 of 62 posts

Re: Phoenix LiveView 1.2

#31

Post by cpursley »

Traubenfuchs wrote: post #26
cpursley wrote: post #2

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

> 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.

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.

Re: Phoenix LiveView 1.2

#32

Post by cpursley »

orliesaurus wrote: post #22

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.

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

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

Re: Phoenix LiveView 1.2

#33

Post by cpursley »

Tinkeringz wrote: post #13
cpursley wrote: post #2

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

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

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

Re: Phoenix LiveView 1.2

#34

Post by OhSoHumble »

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.

Re: Phoenix LiveView 1.2

#35

Post by OhSoHumble »

lwouis wrote: post #25

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 recom…

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

Re: Phoenix LiveView 1.2

#36

Post by oliwarner »

epolanski wrote: post #30
Intermernet wrote: post #28

Earlier quoted context omitted.

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.

> 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 add…

> each navigation had to reload the whole page

Saving the world, 50ms at a time.

Honestly there are times when using the View Transition API makes sense, but the context here is a dinky brochure site. The weight of scripting does as much damage to first load as it saves on subsequent loads. Browsers are good enough at managing this stuff themselves.

Re: Phoenix LiveView 1.2

#37

Post by avanwyk »

orliesaurus wrote: post #22

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.

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).

Re: Phoenix LiveView 1.2

#38

Post by GCUMstlyHarmls »

mcintyre1994 wrote: post #20
cyberpunk wrote: post #18

Earlier quoted context omitted.

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.

I haven’t used it for anything in production so I haven’t seen these issues, could you give a bit more detail? I’m mostly wondering why you’d have any more websocket messages that you respond to than you would APIs if you were using any other approach. Does LiveView itself respond to certain messages bypassing your app?

There is some propensity to forget that you're basically making a REST API because its all "in my process, responding to messages", it feels like you're writing your regular server side render controller. But really instead of `PUT /create/post` its `websocket.send("create_post", {})`, so you need to understand that if you only want to operate on `user_id=1`, you need to not just accept `{user_id: 1, ...data}`.

I dont think its inherently any more insecure than another method, you just have to recognize that clients can create malicious requests to `handle_event(my_event, params, socket)`, just like you might to `my_action(params, conn)`. It's also pretty painless, normal, to just crash on bad data, it will only effect that one naughty lv process.

You could also send "control" signals to the phoenix liveview process via the same socket but I dont think that actually as much surface outside of heartbeats and closing the socket.

Re: Phoenix LiveView 1.2

#39

Post by GCUMstlyHarmls »

rubyn00bie wrote: post #11

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 har…

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.

Re: Phoenix LiveView 1.2

#40

Post by thibaut_barrere »

orliesaurus wrote: post #22

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.

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.

Post reply on HN