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

51–60 of 62 posts

Re: Phoenix LiveView 1.2

#51

Post by moritzwarhier »

OhSoHumble wrote: post #34

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.

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?

Re: Phoenix LiveView 1.2

#52

Post by IAmGraydon »

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.

Worth checking out...

https://phoenix.new/

Re: Phoenix LiveView 1.2

#53

Post by projct »

moritzwarhier wrote: post #51
OhSoHumble wrote: post #34

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.

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?

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.

Re: Phoenix LiveView 1.2

#54

Post by moritzwarhier »

projct wrote: post #53
moritzwarhier wrote: post #51

Earlier quoted context omitted.

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?

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.

Thanks a lot! I'll give this a try next time I feel like coding for a hobby.

I've tried exactly this "project idea" in a half-assed way some time ago with next.js, Postgres and Prisma before I was out of free-time-in-front-of-computer.

Then abandoned it again it when I started coding for a living again. It was exactly the "modest RT capabilities" thing when I abandoned it. Because I started using Firebase (2023, Supabase was not known to me then) and then I felt like "OK, I managed to get full next.js running properly on shared hosting with limited server-side JS, but now I again need an external cloud provider for a hobby project" (Firebase).

I read a bit about their pricing models and lost interest.

I think next time I'm gonna try see what this stack can do.

In 2024, I heard a very interesting conference presentation about Erlang and its concurrency model, that was after the hobby experiment, and made me want to revisit losely functional languages with strong pattern matching (OCaml too, but that's a different topic).

Re: Phoenix LiveView 1.2

#55

Post by lwouis »

Intermernet wrote: post #28
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…

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

Re: Phoenix LiveView 1.2

#56

Post by kajman »

giovannibonetti wrote: post #43
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…

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

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.

Re: Phoenix LiveView 1.2

#57

Post by preg_match »

lwouis wrote: post #55
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 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 exis…

Static pages is basically always faster. The web browser is very, very quick at rendering HTML. Executing JavaScript is much slower. But, the real benefit of static sites is caching. You can cache on the edge and have remarkably fast load times.

For the flickering or flashing, you can just stick a couple lines of CSS for view transitions and boom, done. I understand the flashing looks less professional or fast, but it’s not actually.

Re: Phoenix LiveView 1.2

#58

Post by solid_fuel »

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?

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.

Re: Phoenix LiveView 1.2

#59

Post by joshspankit »

ricw wrote: post #42
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.

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…

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

Re: Phoenix LiveView 1.2

#60

Post by foxes »

zerr wrote: post #21
foxes wrote: post #6

Earlier quoted context omitted.

elixir/erlang gets compiled into beam byte code. It's a vm. why does this matter..

It's an interpreted byte code run (interpreted) by BEAM. Not a native binary run by CPU. But apparently BeamAsm JIT solves the issue? As mentioned in the sibling comment.

But why does a particular execution model matter?
Post reply on HN