This Release Makes Me Want To Leave React...

Seriously. Elixir has always been my guilty pleasure and LiveView makes me rethink everything. Aaaaaaaaaa. So cool. Phoenix is dope and makes functional programming in a rails-like env fun
SOURCE
phoenixframework.org/blog/pho...
Check out my Twitch, Twitter, Discord more at t3.gg
S/O Ph4se0n3 for the awesome edit 🙏

[@jackevansevo]

Elixir/Phoenix has been tempting me for years, might have to finally take the Elixir pill.

[@LiveErrors]

silly, you drink an elixir, you dont take it in pill form

[@jsonkody]

It's awesome, but sooo different .. I highly recommend Pragmatic Studio's Elixir & OTP or Codegnome's Elixir courses. I was blown away by some features like the omnipresent pattern matching, etc.

[@jackevansevo]

😂 very true!

[@theblackquill5921]

every elixir is a love elixir when you love elixirs :)

[@kristun216]

i took it and i ended up wanting more and more only to realise there's 5 companies in the whole country using it

[@ream88]

Doing Elixir now for 7 years and it is getting better and better every year. My biggest concern with it is that devs are rare as unicorns. However, once you've assembled the right team, the possibilities with Elixir are endless!

[@grimm_gen]

I once had a recruiter from samsung who contacted me for an elixir position there!

[@SamOween]

@@grimm_gen how did they find you?

[@awnion]

That's not a big deal since it's quite easy to onboard pretty much any FP fanboy (Haskell, OCaml, even Scala)

[@MrJfergs]

is work in Elixir quite rare, I feel like it's a small niche.

[@tuananhdo1870]

Dev are rare maybe is an pros. Because you got less compatitive

[@seymores]

It is crazy how Elixir/Erlang is not as popular as it should be.

[@username7763]

It is dynamic-typing so it is probably about as popular as it should be. JavaScript, on the other hand, is way more popular than it should be.

[@naughtiousmaximus7853]

JS is forced into popularity.

[@samjohns8381]

@@username7763 The dynamic typing isn't nearly as bad as people claim it is. Elixir's pattern matching and type-specific operators prevent those "whole classes of errors" people talk about. They aren't caught at compile time, but your general tests should catch them-that is, tests you would have anyway, NOT type-specific tests (I don't have any of those myself). The whole "let is crash" philosophy makes it more than fine for most systems. All that said, I'm not mad it's getting static typing, but I'm in no rush. I also don't work on HUGE systems, though.

[@Erandros]

i actually like elixir, sounds great for performance heavy apps, but... as it "should be"? we got some celestial beings in the yt comments. elixir has no mature type checking before runtime. js has multiple issues (inexperiencedly designed lang, ecosystem rebirths every 8 years) but it has (pseudo) static typing with typescript. I change the type of a field in my zod types, I get to know before pushing about edge cases with proper eslint config. people choose, man. something better comes along? people switch. webdev via wasm+some lang has yet to be proven as a good setup to switch out of js. I write a web app with node+some framework, only learn 1 language for client and server side. guess what happens when you are 1 year into building a really cool elixir app. oh, you need to learn js to deal with all the edge cases: the frankenstein app begins. the guy is writing html inside a string for fuck's sake. i don't care if it has good highlighting, remember how nice it was writing jsx with typing? so you get know if you messed up the name or value of an attribute? gone idk what else to say man.

[@whimahwhe]

@@username7763 bullshit

[@adamsilber-gniady6326]

let me tell you as someone who found elixir a few months ago after severe JS burnout: elixir phoenix is the way and is a beautiful piece of tech. come to this side, it is in fact filled with greener grass

[@user-ik7rp8qz5g]

As someone who tried it out of interest year or two ago, I couldnt make mx command work even while following tutorial step by step. Imagine not being able to get working project after running npx create-next-app

[@rashzh5502]

He used to program in Elixir when he was at twitch

[@schtauffen5975]

now we will make phoenix for gleam and call it thunderbird

[@ChrisPepper1989]

Is elixir blazor but not Microsoft?

[@trevorhunka7689]

We've never heard anything like this before

[@Mentioum]

Loved this video Theo - as someone who hasn't written Elixir or Erlang since 2014 where I built a custom Unity3D Component Serialisation System for Realtime Networking, so happy to see Elixir coverage.

[@professormikeoxlong]

Create a HTML MPA. Rewrite to PHP. Rewrite to Django. Rewrite to Ruby. Rewrite to Next.js. Rewrite to Svelte. Rewrite to Go. Rewrite to Rust. Rewrite to Elixir. We'll never get anything done lol 😂

[@hamm8934]

Because social media developers only care about coding, they really dont care about make a product or solution. Just the fun of making it.

[@RasmusSchultz]

We should have stopped at "create an MPA". This was never hard. All the "requirements" that came after were invented by developers with feelings. I'm half joking, but I'm half serious as well - the large majority of projects would be *just fine* as an MPA with a bit of backend in Whatever. This stuff is as complex as we choose to make it.

[@Erandros]

What an odd joke/complain, are you annoyed by variety and innovation?

[@professormikeoxlong]

@@Erandros are you even a developer?

[@Erandros]

@@professormikeoxlong bruh

[@PhilKingstonByron]

Crazy Good! And such a well written post to be able to capture the complex nuance in short sentences. Thanks.

[@alexander0gorkunov]

Using elixir for last 6 years full time and very happy (moved from ruby). Thanks to mature core (OTP/beam) we have a lot of instruments for live debugging that helps with day to day debugging and dev. But I want to aware about hot-code reloading (swapping) - it's very hard and almost nobody from elixir community uses it for release processes. It's just increase release process complexity to non-acceptable level. It's only sound great but in reality state management and swapping is very hard. And when we are talking about web apps where state-less (http nature) is natural approach it's much simpler to go just with regular blue/green releases. However during development hot-code reloading (specially on test-servers) it's a game changer.

[@starmountpictures]

I moved from React to Phoenix and LiveView about a year ago. Never going back.

[@austincodes]

Those saying that PHP already did this don't get it...

[@DKLHensen]

PHP already did this

[@TokyoXtreme]

@@DKLHensenYou don't get it.

[@2dstencil847]

I bet both of your guy are right. First half of video, It just auto ajax and auto reload project when project code change. (At least on real time development, both php laravel livewire and elixir are equivalence, only final feature(shipped feature) always varies, because browser always changing, different web technology update at different pace against new browser feature) To be fair. Web is a big and large ecosystem, too many stuff hiding that framework and library already do for us... and niche place that help here and there, just phoenix is slowly steady and never use shortcut like most javascript developer do, so they think it is magic.....especially those work around facebook era, should know that trick, but maybe they never use it, but they know

[@EightNineOne]

I think this video could do with a follow up. A lot of people are missing that the BEAM is the real special sauce and how well it compliments LiveView. Almost like flipped the other way around.

[@joshuazermeno3040]

19:18 are you referring to The old Turbolinks? Or the current iteration of Turbo under Hotwire? Payloads now operate by either providing a frame tag to replace an existing frame tag (without loading whole template/layout) or specifying a swap of any ID'd DOM element with a small payload via turbo_stream (still without rendering template/layout). I guess the latter supports their argument of requiring additional dev tuning.

[@SeanLazer]

Yeah I think Theo is a bit out of date on Rails' frontend solutions but it looks like LiveView blows Turbo out of the water. LiveView's creator seems to have spent time with React and internalized its advantages whereas I don't think DHH ever gave it any real consideration. Still I don't think Theo should shit on Turbo and praise HTMX when they're doing fundamentally the same thing.

[@wojciechorzechowski2211]

I have moved from Python to Elixir... I won't come back to anything else! Ruby syntax, Erlang ecosystem, beauty!

[@mitchrivet]

absolutely loving elixir and phoenix- feeling much more productive than nextjs

[@Kobra8220]

i'm so glad that i'm learning this tech stack for a few months beside my full time job, looking forward to switch to this stack as my full time job

[@khealer]

So we're back to PHP?

[@glebtsoy4139]

Yes, PHP with websockets. Really tho this looks pretty cool.

[@ristekostadinov2820]

laravel livewire

[@MrManafon]

@@glebtsoy4139 It is so much more lol. The first 3 seconds of the vidoe, Theo shows it updating a whole network of servers, their build caches AND pages on clients that are currently connected. Elixir/Beam/OTP are instanely well designed and battle tested.

[@rawallon]

@@glebtsoy4139 I'll get on that once php implements it

[@MrManafon]

While I agree that PHP is amazingly well suited for the types of systems it is usually applied to, Elixir/BEAM is five steps ahead of everything in the industry. You souldn't focus solely on the templating, instead take a wider look at the runtime model, ability to spawn thousands of processes, to create server networks, use other technologies, have sane throws and sane logging mechanisms, switch between HTTP APIs, Websockets, RPC, async APIs without needing half of AWS to achieve it.

[@vaaaaaas]

- rewrite your backend to Ruby on Rails - rewrite your backend to nodejs - rewrite your backend to go - rewrite your backend to rust - rewrite your backend to elixir Will so much time spent rewriting it's a real wonder how anything gets done in this fkn industry.

[@lastrae8129]

The truth is nobody rewrites except for tech youtubers. The project I work on still uses PHP/backbone/jquery like it did 10 years ago.

[@usbgus]

A lot of the web still works on PHP and will for years to come. There are many new projects that still start on PHP, not no mention Java or C#. All of these cool new stuff happen only in twitter and youtube.

[@tedchirvasiu]

@@lastrae8129 and noobs

[@Mooooov0815]

Nobody is rewriting anything lol. This is just the infinite content mill going

[@shadyworld1]

Douglas Crokford was right! The industry needs a whole new alternative to JavaScript itself not just libraries! Something to end all that fuckups Changes of technology And adopt widely with all browser bases

[@Dreamvention]

Making server side cool again? I feel like we just gone through a loop

[@bruceleeharrison9284]

Welcome to CS. I'm waiting for the inevitable backlash to cloud providers, and everyone runs back to in-house data centers.

[@Frostbytedigital]

​@bruceleeharrison9284 getting away from cloud would be hard these days. But if i was gonna dream up a perfect scenario(imo) id say CS devs/engineers create a union that works to protects our rights and experience. But ALSO creates AT cost data centers for union members to utilize.

[@thelvadam5269]

@@FrostbytedigitalIt’ll have to get a lot worse for developers and engineers to unionize. They’re not really the type to. You’d have more luck in specific industries where people have been abused for a long time like in game development.

[@thewiirocks]

@@Frostbytedigital it wouldn't be a reversion to what came before. It would be a new, updated approach that revisits the concept with a modern approach. Probably a way to outright buy capacity in a datacenter such that you "own" the machines. Services would allow web reconfiguration of the setup, some being immediate (since they can be controlled in software) and some having a lead time to physically setup. (e.g. installing a direct network line) I can see this being so much cheaper than clouds that excess capacity will be bought to ensure little to no lead time for teams requesting hardware. Which will work fine right up until someone decides further excess capacity isn't needed and trims the budget. Then we'll be back to long lead times and cloud will become more appealing again. Yay, the CompSci pendulum...

[@willcoder]

The pendulum between client and server has been swinging since the late teletype early dumb-terminal days. We seem to have new names every few years for mostly the same concepts. At least it's a client-vs-server loop... and not recursive... Unless you look at the bare metal/image/package/VM/container progression... that definitely _feels_ recursive.

[@BorisBarroso]

Wow this is incredible I haven’t used phoenix in a long time and I want to go back to it🎉 Amazing

[@PieJee1]

The innerHTML reminds me what I built in the pre-js-framework time period, where we used jQuery for being compatible with all browsers. Also we had to support IE 6.0, where it was easier to update the DOM with innerHTML and not do DOM operations, because they were too slow. The only downside is that you also lose the focus of an input field if the HTML is being updated that contains the input field. We did try to reassign the cursor position after an update. It was much faster in loading the page and also in building the javascript.

[@MrManafon]

I feel like that every day I go to work... I miss Elixir so bad

[@arthur-zhuk]

Recently picked up Elixir after being in JS for a decade and have to say it feels revolutionary.

[@bigsnacks913]

just came to make the "so we're back to PHP?" comment without doing reading up on anything for even 5 minutes

[@lawrencejob]

To me I like incredibly thin clients where the server sends HTML and it’s done (an archivable resource); OR, I like thick clients where the user has so much to hand that the app might even run offline or in difficult environments. Even though this is amazing, I have almost no need for something in the middle - an app that is symbiotically tangled with the server and at the whims of my connectivity.

[@keithjohnson6510]

You make a good point about offline, it's one of the reason I'm not a fan of any form of SSR. If I have a section of an app I want to make offline, going from client side is pretty easy, work out some sync logic / storage and your done. If all my eggs are in the SSR camp, I'll have a much bigger job on my hands.

[@aghileslounis]

It's so good! I'm so excited. Thanks Theo, for covering this news! I can't wait for Elixir to become a fully typed language like TypeScript as fast as possible. I swear it will be one of the best language and tech to build APPLICATIONS in general. Web/Mobile/Embedded....... They have a remarkable "base" features no one truly has

[@aucusticguitar8069]

Why does Elixir need static types? It's pattern matching and testing workflow prevent the category of errors you're referring to

[@metropolis10]

I remember back in the C++ Borland Builder days, you could change a property on the representation of a UI component and it just updated live. In MS Visual C++ however you had to call a function and say if you wanted to push UI state into your model, or your model into UI state. The later won out... why was that?

[@programmerjowo]

Like mfc updatedata(false)

[@madlep]

Did Vercel... just use "The Conjoined Triangles of Success" for their graphic about blue-green deployments?

[@lawrencejob]

HA! Good spot

[@DahrkDaiz]

I don't understand this problem of out of sync state. My front end only ever maintains its own state. We solved this decades ago with MVVM (model, view, view model). The frontend is the view, it works off a view model (it's own state), and then the model comes from the server. This feels like a specific problem that's being appied to every situation, much like redux. Making your server responsible for UI state means your client is now tightly bound to the backend, making backend changes riskier. Want a simple UI change? Make two changes and two deployments. The benefits of even having an API fall away because every client now has to accept an HTML response. The moment you have a frontend that needs to have a different HTML structure returned, this architecture becomes a horrible mess. I expect to see "server side UI API responses were a mistake" videos in the the future.

[@simonhartley9158]

It sounds like in MVVM can be expensive to make changes to the server model. Usually the UI is driving changes to the shape of the server model and development can become hampered by the UI team having to wait 3 to 5 business days for prioritisation, implementation, testing and deployment of server changes.

[@thewiirocks]

Stop making sense. If we made web development solved and boring, how could we talk about the new mistak-- err... "technology" of the week?

[@Leonhart_93]

Just a consequence of trying to force JS on both backend and frontend and then blurring the line between the two of them. The server sends the DB data as JSON or whatever, the frontend uses it to create an UI. If that data changes, the server sends the updated version. This is not hard at all, it is just made hard as marketing for certain tools.

[@MadsterV]

@@simonhartley9158 MVC and it''s children are VERY battle tested by now and no, the UI shouldn't drive server model changes. The UI should display what the app needs to display and the server should be providing enough information to do that. You don't change the server in response to UI changes, you change BOTH in response to app design changes. Management paperwork is a separate, unrelated issue. Changing the color of a button should definitely not require a backend change. I feel every framework is driving towards being a new Visual Basic, which we abandoned for good reasons. JSON is pretty good for me, I can still do rich, dynamic UI without having to fight a renderer to produce the HTML I want the client to use.

[@simonhartley9158]

@@Leonhart_93 your model doesn't seem to take advantage of the benefits of streaming, nor deal with update granularity vs. client side request waterfalls.

[@ThymeCypher]

Grandpa PHP has that "Told you so" face rn

[@jrrrohm]

Been using it for 5+ years now. Getting better all the time.

[@spl45hz]

Coming from blazor I am very hesitant to have a server call to update any state. This sucks if you have a slow Internet connection, and makes it unusable if connections drop. Curious if their solution works better

[@dahahaka]

They're closing the connection once the page has loaded, and then the client components can take over for interactivity etc. at least that's one way to do it. I'm also using blazor and while i love what microsoft is doing i'm starting to see the pitfalls... still has a long long way to go. (Currently using Blazor Hybrid on android and iOS, i love C# especially the functional parts)

[@hauleth]

It is not. It will suck with poor network exactly the same way as Blazor.

[@dahahaka]

@@hauleth That doesn't make any sense, you can use Phoenix without keeping the connection alive, performance with that is equivalent with a normal request, you just get to draw faster

[@dahahaka]

@@hauleth Same goes for blazor btw, and idk why you think blazor sucks lol

[@hauleth]

@@dahahaka I didn't said that Blazor nor LiveView sucks. Just both technologies will suck when there is poor connection between server and client.

[@brennan123]

This still super exciting. I will have to check out a bunch of these technologies. I still think Haskell is the closest syntax needed for modern full stack development. Everything is based off the C imperative syntax but most of what we do now is functional reactive programming so it makes sense to have a syntax more optimized for that.

[@username7763]

Reminds me a bit of atozed Intraweb at least the old versions I used a while ago. All the code you wrote was server-side. The dev tools acted like you were writing a desktop GUI application but it would do all the magic of syncing the GUI from the server. It had it's problems, it didn't scale at all and was resource heavy. The abstraction would break down at times. Maybe it's gotten better, I'm not sure. But I like the basic model.

[@flyguy8791]

Well, this is definitely the push I needed to check out Elixir/Phoenix. This looks really impressive.

[@filipebraganca2558]

I've know the liveview since it's inception, but I'm not using elixir for the last few years and really thought it was already 1.0/ready for production for a long time, really surprised to see that 1.0 was just released now. It shows the care the team takes.

[@bideshbanerjee5506]

15:00 same thing I am still thinking in case of RSC when I got to know of it, for every updates sending the whole json representation of the page. How optimal is that ?? Or maybe be revalidateTag (sends the respective component's json representation) works differently than revalidatePath (sends the all components json representation) I guess

[@bakbak1830]

i started learning phoenix liveview an year ago; haven't seen a complete framework like this. It is little difficult to learn it as there are not many tutorials available but books are solid.

[@MrManafon]

It is unforunately very true. There are a lot of resources out there, sure, but nothing beats working on a real project or seeing someone's real-world codebase. I remember watching Jose Valim use Livebooks on his Advent Of Code Twitch stream, and god darn i learned so much from seeeing that. I suppose, a bit of a lucky thing is that the whole ecosystem, including Elixir itself, is written in Elixir, so we can fairly easily inspect their files and the way they manage projects. There are also a couple of amazing podcasts on Spotify worth listening to.

[@Duconi]

22:44 I don't know about GraphQL. But if you have multiple services you don't want them to call the auth server all the time. So you use JWT instead. With that you just ask the auth server once for their public key and then you can check every request with checking the signature of the JWT. If it is valid you can read the data from the JWT and know which user it is. No need to do any additional call. Btw. with the web sockets solution, either you don't use microservices but a monolithic application. Then you don't have multiple services, you just have one monolith that does authentication and all the endpoints. Or you have to split the web sockets and basically have 3 separate connections. So you kind of compare different things / different architectures with each other.

[@Robert-zc8hr]

But what if there is a change in the user permissions? The JWT will be outdated and that may be dangerous, so you need to specify short times to live and re-validate (going all the way to the DB or centralized auth service). If you're going to do that why not simply use a traditional server side in-memory cache? In that case you can use cookies or whatever (that only hold user id) and check in the cache for the permissions. If the cache is short lived you are in the same situation as JWT except for the specific instance where the client is connected where you can edit the cache record directly (considering how load balancers work, in most cases will be the same server anyway).

[@Duconi]

@@Robert-zc8hr the privileges rarely change. You can have for example 15 minutes tokens and a refresh token. If privileges change you create a new 15 minutes token with the changed privileges after the other expired. The alternative with the cache isn't good, as the auth service needs to be online all the time and each application server has to ask it. So if it is down, everything is down. It you have JWT and the auth server is down for 10 minutes, it's not that big of an issue. Some users can not use the services, but others can. Also you can use stateless logic like Cloudfront functions to check JWT tokens.

[@Don_XII]

Wow this is so interesting, things are getting more fun and fun.

[@dogoku]

17:12 "This is like Qwik, but good and solving real problems" - I really wish you'd elaborate a bit more on this, because to me both libs seem to solving the same problems, just doing it differently. Both libs identify they need of splitting into static and dynamic parts, both only send minimal code for interactivity and both do fine-grained updates. What is the "real problems" that Phoenix is solving and why is it "good"?

[@bas080]

I believe that a real difference between Qwik and Phoenix is that Qwik has a better user-story when it comes to frontend/browser only components/islands. Phoenix dev-experience would favor the back and forth between server and client over WS (at the moment of writing).

[@dogoku]

​@@bas080 that is (more or less) my understanding as well. Each solution has its pros and cons, but claiming one is simply "good" and "solving real problems" (implying that the other one doesn't do neither of those things) is just childish.

[@Frostbytedigital]

Also to be fair. Users being on the existing page and not getting the update till they refresh is not some huge problem. Even massive companies like amazon accept that behavior and wont be changing frameworks to "fix" it.

[@ark_knight]

He has talked about it in a js framework tier list. I think you can boil it down to having quik's weird syntax that he can't digest.

[@perc-ai]

brother it can scale to 1m websocket connections its all REAL-TIME. Quik does not even compare in the slightest

[@user-iv1pt2sy8j]

How does this compare to what Blazor does with Websockets?

[@seanknowles9985]

Can we do offline first PWA apps with live view? Seems limiting...

[@t3dotgg]

No lol

[@seanknowles9985]

@@t3dotgg that's a huge load of functionality just boom, poof, gone..

[@MrManafon]

@@t3dotgg Actually yes, there are people (crazy people) who run a local liveview instance on your device, that powers the frontend, and communicates with the backends.

[@matt-james-c]

😂

[@eurustse4189]

@@t3dotgg liveview-svelte-pwa I am not sure is it a "offline first PWA apps with live view"...

[@ulrich-tonmoy]

imagine someone editing a big form and out of nowhere it change

[@imanmokwena1593]

This is the best theo. The educator with a great tone and not sounding pompous like in some videos.

[@brssnkl]

What do you do with your iOS Android apps? This doesn't make sense when you have native apps and treat the website as just another one of your platforms.

[@osman3404]

Keeping realtime web socket connection comes with lots of issues

[@DerekKraan]

There is a fallback to long-polling. Curious to hear which other issues you are referring to, because LiveView has been running in production for years.

[@samjohns8381]

Not a lot of issues, no, just some issues like anything in tech.

[@MikeKasprzak]

Nice. I don't know how much of this PHP is suited for, but I agree this is presented excellently.

[@Leonhart_93]

PHP is suited for anything on the server-side. In the end you are just sending some plain html to a client.

[@BosonCollider]

Thank you. We desperately need more variety in architecture, the json API monoculture needs to be challenged, HTMX and Liveview are two complementary approaches to do this

[@Duconi]

Why not using SOAP? Why not using XML? We moved away from them to JSON, because it's more simple. Sending HTML snippets is a way back in the wrong direction. I don't say it's bad in any case. And I agree that we need more variety in architecture. A better solution than React and Phoenix LiveView is for example static HTML. If you don't need dynamic content, just put it there as a static HTML. You can generate a blog with Hugo and don't need computing. Neither on client nor on server side. Of course that is not working for everything. Where you need a bit of dynamic content, you can provide it as a custom element. For example comments in a blog. But if you have for example a live ticker on that page, Phoenix LiveView is maybe a good solution for that. Can you add a custom element and serve it with Phoenix LiveView? 🤔

[@Goshified]

The end result (demoed in the intro) reminds me of how cool it was to work with Meteor ~10 years ago.

[@VeitLehmann]

This is awesome news! I used to work with Elixir/Phoenix and LiveView. But I had the choice to work on a questionable product with those technologies, or on a great product with React/Next.js, and went for the latter. But sometimes I miss the elegance of Elixir/Phoenix. I'm not a big fan of Tailwind - it's like a hammer that makes everything look like a nail. But Elixir/Phoenix IS the right nail for it, it's the perfect match and I wouldn't like to use anything other than Tailwind with it.

[@ironhammer4095]

Let me guess: a gambling site?

[@VeitLehmann]

@@ironhammer4095 Not that shady, but close 😅

[@keithjohnson6510]

Streaming is not just an SSR tech stack thing, been using Sockets for years now. Generally speaking the types of web pages I create are for commercial dashboard, data entry type systems, the majority of comms are via sockets, and like you pointed out in the video one advantage here is Auth is only required once, other advantages is that data can also be sent in binary, and even before HTTP2 allowed you to create a protocol that multiplexed the requests. Still use Rest end points, but generally this if for legacy comms, or B2B logic. In the long run this takes way less data than sending HTML, mainly because the data can be cached aggressively, and invalidated by the server triggering updates. SSR makes streaming easy, but please don't make claims that it takes less bandwidth than client side rendering, because it depends on how you do client side rendering, using REST is just one option that because of it's stateless model is not the best for performance.

[@thelinuxlich]

If the communication between browser-API server goes through HTTP2/3, the many requests might get a boost by running in kind of a batch on the same socket

[@gerritweiermann79]

But not auth what was his main concern

[@AderionsVids]

@@gerritweiermann79 The auth point is moot. If you are using JWTs you don't need to hit the Auth system every time. I hope no serious application checks back with their auth system on every single request.

[@helleye311]

Still not a huge fan of elixir syntax, but other than that, this looks fantastic! I'm not entirely sure how well it would work with highly interactive sites that have animations etc, there might be some interaction delay still, just because network latency. Not talking about updating a progress bar, but things like tooltips, drawers, popups etc (unless I'm understanding this wrong. But I wouldn't want 100ms delay after clicking a button to show a popup). But if you don't need that stuff and just want a semi-interactive site, it's very much promising. Kudos to the team for pushing this pattern!

[@adamsilber-gniady6326]

Drawers and stuff are things that JS does good. You don't need liveview for that

[@EsperSpirit]

They ran 60fps animations across the ocean in one of the keynotes and it worked without issue. Some folks even build browser games with LiveView. And usually you'd use css animations for most things anyway

[@javiasilis]

In 23:28 we were talking about Auth and how it would require 3 roundtrips to the server. Wouldn't it make sense to have the profile and permissions within a JWT or Secure Cookie? If there's an update in one of these you could update the JWT or Cookie. I know this depends a bunch on the architecture and the server, and whether you have it split into several services...

[@chakritlikitkhajorn8730]

Secure cookie still require authentication if you use normal bearer token. JWT have an issue of invalidation. If you want real-time JWT revoke, you again, need to do authentication for every round trip.

[@javiasilis]

@@chakritlikitkhajorn8730 Yes. But you'd have less roundtrips as they are part of the token (correct me if I'm wrong). Additionally, you can always have an in-memory storage with it, right? That way you can blacklist the JWT and it'd be fast. If you have short lived JWTs (Expiring an hour or so) you can minimize an attack surface in which the in-memory storage becomes unavailable

[@dyunior]

What field is this?

[@abhigyanmohanta8861]

Let's goooo 🚀

[@ICodeForALiving]

Every release makes me want to leave React. Only the food on the table makes me stay.

[@samjohns8381]

I'm making great money writing Elixir at work. Just keep an eye out :)

[@manjurulkhan2308]

No, thank you. Isn't that what Blazor Server is already doing?

[@9jaForce]

Does Blazor have the superpower of the Erlang-OTP BEAM? I don't think so. LiveView is powered by the most powerful virtual machine on the planet.

[@user-vs3hi5kc6w]

Yes, and it comes with a bunch of issues.

[@cherubin7th]

I rather wish for something that is focused on being local (client side) first. So like everything you do is local and synced with the server if available at some point in time, including the updating of the client itself.

[@davfive]

What drawing tool is Theo using at 21:14?

[@vladgonzaleza8774]

I have used the .Net version of this which is called blazor server. However, the big problem is the high latency for anyone who does not live close to the server.

[@mihailmojsoski4202]

You mean high latency? Because low latency is good as it's measured in seconds (or milliseconds).

[@vladgonzaleza8774]

I meant high

[@skapator]

"might seem great if you are near the servers it is hosted, but as soon as you go somewhere else your experience sucks" is a perfect description of a specifc problem and not a generic one. You might think that all apps are like email clients or file uploads or streaming, targeting all possible universe's users where distances could easily matter and introduce niche problems to those revenue generating specs, but most apps are fairly local. And most of their problems can be solved horizontaly. I would argue that most MVPs are not worth the effort of fast speeds either. So you are only left with those niche apps. not niche in terms of user volume but in type of app. Also keep in mind that distance is not the only factor for speed experience. So how many flies did those bazookas killed?

[@user-vs3hi5kc6w]

I use blazor server at work which I guess works similarly to liveview. The problems we encounter at work is scaling and connection issues due to the constant need of being connected to the socket. For example chrome browser saving features disconnect the socket and the state of said page is gone forever due to needing to reload the page. If the server is getting crowded latency becomes a big issue and interactive elements on the page feel sluggish. I can’t say I’m a big fan of needing to be connected at all times to the server. How does Phoenix tackle these problems?

[@samjohns8381]

I have no .NET experience but the BEAM is exceptionally good at handling lots of connections. It favours equal distribution over raw speed. In terms of losing state, I think it's a general misconception with these technologies that you should be storing lot of ephemeral state. While the initial sell of LiveView was "no JS," it's moved FAR on from that tagline. It encourages doing many things on the client, like opening menus and whatnot, and they have helpers for that. If you have state that needs to survive a refresh then it needs to go in the database or local/sessionStorage. You have the same problem with with client-side JS frameworks if you are just storing state in memory.

[@matreyes]

you don’t need the round trip for every interaction, but if you do, Beam (VM) handles the connection trough lightweight processes that works independently handling millions of connections without increasing latency (unless you have another bottleneck)

[@limpiadora]

28:00 I think a lot of back-end devs start to realize that MVC doesn't work and the Component are the correct way to abstract, I think Django have them and Laravel also

[@dariofagotto4047]

So many vibes I wonder how long before we get a based reactivity updates

[@Fanaro]

That the web still isn't a pubsub thing by default in 2024 would make my blood boil back when I learned programming in 2011.

[@jrdn5206]

I listen to your videos with my 2 year old prior to switching to toddler music in the mornings….. it’s a matter of time before he starts saying f*ck

[@heldim92]

Noob, but serious question: 24:55 -> Amongst Elixir, Go, Rust, Zig and C#, which ones have similar "included" approaches, delivering comparable results, in terms of requests volume reduction? Or is it exclusive to Elixir's ecosystem? I'm just trying to understand if this is something new for Elixir specifically or actually for the whole scene.

[@t3dotgg]

This is new to the web. There's been some similar ish things in game dev for multiplayer games, but this is entirely new as a way to update HTML and manage a user's session over time People are gonna come in here and reply "but TurboLink did this before!!!1!". Those people are wrong. Nobody's done a real concept of "long running per-user sessions on the server" in Ruby.

[@heldim92]

​@@t3dotgg Thank you so much for such a fast reply! I'll definitely take a further look to understand more about this new feature, it indeed seems to be a very relevant mark! How big of a project (number of online concurrent users) would you say is enough to justify choosing Elixir instead of Go (for example), if your main concern were to reduce financial costs while utilizing cloud services as the main backend? I know this is a broad question and heavily depends on the way the code is structured, but as an independent dev living outside the US, that's kinda my main nightmare and I rarely see people talking about these managerial aspects of development...

[@greyshopleskin2315]

Pease make a little course about phoenix :)

[@adamgonda]

It's so fucking cool!

[@alexleung842]

Obv this breaks down for things which need frequent rerenders. Like a game for example

[@t3dotgg]

Yep! Server components do as well. IMO it's not a "break down" thing so much as not the solution space server-first tools operate in :)

[@mihailmojsoski4202]

Even react shits the bed for anything that is real-time. Canvas with WebGL/WebGPU is the only way to go.

[@olealeksandersjofasting1392]

Used elixir to deploy a service maybe 4 years ago and it was a blast, but back then it seemed like the elixir ecosystem was a bit stagnant. Might have to consider this again, now that I am bootstrapping a new company

[@thekingdev4675]

I'm Brazilian, Elixir was developed by a Brazilian coincidence? I have been programming elixir for over years

[@AlanPCS]

What do you mean by “needing to auth 3 times”? We usually just use a JWT that is signed with a BE secret.

[@upsxace]

You have to decode the JWT and verify the signature every time genius. And that's if you're using JWT. There is other types of authentication, and tbh most services nowadays leave the auth part for an external service, so you will have to do 3 requests to those external services.

[@AlanPCS]

@@upsxace wow, toxic trash talk. No thanks. Just study some more :)

[@upsxace]

@@AlanPCS saying "genius" is enough to hurt you? wow. Tell me where I'm wrong please, I'm open to it (unironically)

[@AlanPCS]

@@upsxace nah… I think you are Genius enough to find it by yourself :) have fun!

[@EsperSpirit]

What app are you working on where you don't need the ability to ban people or change their roles? JWT doesn't magically solve those issues. Besides that JWT still requires resources on every request just cryptography instead of a DB lookup.

[@siriguillo]

Can someone explain to me why people prefer to use k8s and react for all these?

[@ronindevninja]

I continue using react for react native, and for static sites, only use elixir for admin dashboards and graphql apis

[@AdamMusaAli]

It's exactly like hotwire for rails

[@mmmmello6964]

I swear half of these commenters are here just to be upset that their favorite technology isn’t getting promoted by the content mill today

[@ThugLifeModafocah]

Damn, I guess I'm going back to Elixir... Even suspense is there now...

[@AndrewErwin73]

I guess this is old school or "old guard" mentality...but I HATE the idea of having the server update or even know anything about the front end. In most of the applications I develop, a web frontend is only one option (and most of the time, not the only one being utilized)... this has always been my gripe with react. It was developer by engineers who could not figure out how to use the MVC design pattern.

[@boredbytrash]

Can’t wait till SPAs are the hot shit again in a few years 😂😂

[@amirhosseinahmadi3706]

This is all fun and games until every UI interaction takes 2 seconds to react because the server is overloaded.

[@awksedgreep]

Good luck overloading beam to an unresponsive state.

[@awksedgreep]

Google 1m websockets elixir chat. Still

[@zegg90]

The beam vm makes this very unlikely to happen. That's why the video calls out the beam vm for making this possible, something which would be insane to do in any other language.

[@hafermuech]

what about scaleability? isn't scaling websockets super hard?

[@EightNineOne]

In a BEAM world, nope, not really. It's very linear and the tooling to scale and share data between multiple servers is baked in and core to Elixir and erlang. It was literally designed for this from the ground up.

[@hafermuech]

@@EightNineOne thanks for the answer!

[@diegovadell5707]

I love Elixir and Phoenix so much

[@mfpears]

How is offline support?

[@mrleblanc]

Can we use this with a templating language that is not horrible ?

[@kp8752]

Could be worse. It could use JSX 🤢

[@DerekKraan]

Is "basically just HTML" terrible?

[@mikesveganlife4359]

I'm not a full stack guy, but I like to know what is going on. I hadn't heard a walk through of Elixir before but when I saw Theo react at time code 6:18 I immediately thought, I bet this is written in Erlang. Yup, that's what it is. That hot swapping stuff is pretty cool.

[@CoolestPossibleName]

Using web sockets to update the html is a bit overkill

[@kezzu5849]

Welcome to web dev in 2024.

[@Mooooov0815]

@@kezzu5849well is it any more overkill than having hundreds of thousands of JavaScript lines running to compile a 600kByte JS bundle to run in the users browser to show a hello world?

[@jsonkody]

?? me not uderstand You update it in all web-apps by something .. by json .. by html .. by websockets etc.

[@CoolestPossibleName]

@@jsonkody why not just update it with js using fetch?

[@cahva2]

Good luck when you have lots of people hitting your api endpoint at the same time instead of streaming the change via websocket.

[@ESMakino]

Using liveview in production for years and I didn’t have any problem with it

[@dylan_the_wizard]

Elixir is a nice language and LiveView is an ok (albeit buggy) alternative to the React model. But after giving it a fair shot, I just couldn't make the sacrifice of type safety. Maybe in a few years if they get their static type system implemented. The fact that their JS side is so half-assed and lacks TS types (the Elixir/Phoenix team is AGAINST typescript) is also a massive turnoff.

[@LukeFrisken]

Gleam + Lustre might get there first

[@MrManafon]

Legit comment, I had the same, but I implore you to give it a chance. After working on a real Elixir project for a while, I've realized that all the tools you need for typesafety are built in. Most of the time you simply don't need types because the language provides significantly stronger type-checks than TS can. Additionally, you do have types, in the form of typespecs. As for what you do in your own JS/TS, it isn't really Elixir's concern if you have a separate build system or a headless frontend.

[@KangoV]

HTMX ftw. Our JS devs love Go/Templ. No JS, yay! :)

[@firedeepadarshan]

Server-side Blazor has been doing it for a long time

[@wakeuphugo]

Thank you. I was thinking, does it suffers from the same limitations in terms of scale or when user connection sucks? If I understood, this use websockets.

[@Qrzychu92]

@@wakeuphugo yes, it's the exact same list of issues :)

[@vrcca]

@wakeuphugo Phoenix falls back to HTTP long poll when WS sucks

[@wakeuphugo]

@@vrcca I think that blazor server does the same, since it uses signalR for the websocket part. But I'm not sure if it fallback to long poll after the WS is established.

[@user-vs3hi5kc6w]

I don’t think it does. At least not in my experience. If the connection is lost the page just stops being interactive until it’s reconnected. Which happens after a reload.

[@pencilcheck]

aha, ruby moneky patching in real time for server frontend application lol sounds really cool though

[@rankarat]

Blazor server does exactly that for years now!

[@JacobSantosDev]

Hmm. This is possible without the framework. It does sound like a better way of doing websockets so i am curious about implementing this.

[@matreyes]

this is possible not only because of the framework, but also because of the language and virtual machine that handles the connections.

[@JacobSantosDev]

@@matreyes it is easier to do and most of it is free. However transitioning connections from one process to another is possible in Golang and on Linux. Hotswapping processes is also possible in other languages. From the standpoint of the frontend, none of that is important. It sounds like since a lot of the feature set is just using web sockets, using a gateway or not even a gateway, it is possible to implement the same features. Probably not worth it but I am curious about doing so.

[@pdevito]

The auth diagram doesn’t make sense. If you have your token in a cookie your backend should just need that to get checked when you hit the endpoint. That doesn’t spam your IDP

[@mihailmojsoski4202]

Still need to check the signature (if using JWT or similar).

[@pdevito]

Yeah but that’s not a full IDP check like was shown

[@dahahaka]

The thing that makese me sad about all this is that if you want to scrape something you'll have to start parsing html again.... :( but i guess maybe html parsers will improve or you can use machine learning for it

[@MrManafon]

Elixir does have HTTP/gRPC APIs as well, if that is what you meant.

[@hauleth]

Or maybe in 1000 years or so HATEOAS became a real thing and it will make parsing everything way easier.

[@dahahaka]

@@MrManafon I meant scraping sites that other people have built :D nowadays it's really easy to archive a website because they'll often have user facing apis

[@k3rnel-p4n1c]

10:54, Ok I can see why being able to overload funcs like this is good, but these are literally three identical funcs, why would I want to write something three times if all of them do the same thing?

[@hauleth]

Elixir do not have overloading functions. These **are** the same function just with different heads (as it is called in Elixir). It is literally compiled to single function with big switch inside of it. And no, these functions do not need to do the same thing in several places.

[@k3rnel-p4n1c]

@@hauleth thanks for correcting me, but after checking again the first two are identical. I do not see a reason to write something twice if it compiles into the same thing

[@DerekKraan]

@@k3rnel-p4n1c I think you're right, the code here could be condensed slightly. One thing to note is that `handle_info/3` is the generic callback for _any message_ being received by the process. This means that you have to be a little more specific in your pattern matching, to make sure it doesn't match on other messages that could come in. That might be the reason for the verbosity here.

[@adriancaor]

Elixir mentioned

[@Bryan-zo6ng]

I honestly dont see the big deal. We've had these kind of technologies for awhile. Am I wrong?