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
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).
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”
> The BeamAsm JIT-compiler has been added to Erlang/OTP and will give a significant performance boost for many applications. The JIT-compiler is enabled by default on most x86 64-bit platforms that have a C++ compiler that can compile C++17.
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).
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.
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
https://elixirisallyouneed.dev
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.
EDIT: It is, since OTP 24 was released in 2021:
https://www.erlang.org/downloads/24
> The BeamAsm JIT-compiler has been added to Erlang/OTP and will give a significant performance boost for many applications. The JIT-compiler is enabled by default on most x86 64-bit platforms that have a C++ compiler that can compile C++17.
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).