FR version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
65% Positive
Analyzed from 1176 words in the discussion.
Trending Topics
#liveview#phoenix#blazor#don#why#app#elixir#language#erlang#apps
Discussion (31 Comments)Read Original on HackerNews
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~
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.
And that can also be part of a normal static website...We have had JavaScript for more than 30 years to add reactivity.
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.
https://dashbit.co/blog/why-elixir-best-language-for-ai
https://elixirisallyouneed.dev
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).
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.
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.
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.
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.
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).
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.
A lot of folks assume mobile apps are “difficult” because of the underlying language. But it’s not the language that’s an issue, it’s the SDKs. They’re so wildly different from each other, and the way things work on the web, that it’s (IMHO) a losing proposition to do so.
That’s not to say things like Blazor or React Native don’t have a place but that place is one that’s inherently difficult to maintain without huge amounts of ongoing effort and capital invested in non user facing features.
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