[flagged]
Phoenix LiveView 1.2
41–50 of 62 posts
Re: Phoenix LiveView 1.2
#42I'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 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
Re: Phoenix LiveView 1.2
#43I 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.
Re: Phoenix LiveView 1.2
#44[flagged]
Re: Phoenix LiveView 1.2
#45I'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’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.
Re: Phoenix LiveView 1.2
#46Earlier quoted context omitted.
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 ap…
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.
You authenticate and authorize them the same way you do any other frontend requests. The socket gets an authenticated user and you handle messages in that scope. It’s not hard at all. Since messages have a shape that has to structurally match you can’t just dump arbitrary messages on the socket and get replies.
Re: Phoenix LiveView 1.2
#47I'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.
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.
Re: Phoenix LiveView 1.2
#48I 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…
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
Re: Phoenix LiveView 1.2
#49Years ago I used surface ui's colocated css to great effect. Super happy to have it incorporated into mainline live view
Re: Phoenix LiveView 1.2
#50I’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…
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