Phoenix LiveView Is Making Me Reconsider React...
HTML-код
- Опубликовано: 12 май 2024
- 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 🙏 
Наука
![Eminem - The Death of Slim Shady [Album Trailer]](http://i.ytimg.com/vi/X0HIrS6kUYI/mqdefault.jpg)
It is crazy how Elixir/Erlang is not as popular as it should be.
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.
JS is forced into popularity.
@@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.
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.
@@username7763 bullshit
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!
I once had a recruiter from samsung who contacted me for an elixir position there!
@@grimm_gen how did they find you?
That's not a big deal since it's quite easy to onboard pretty much any FP fanboy (Haskell, OCaml, even Scala)
is work in Elixir quite rare, I feel like it's a small niche.
Dev are rare maybe is an pros. Because you got less compatitive
Elixir/Phoenix has been tempting me for years, might have to finally take the Elixir pill.
silly, you drink an elixir, you dont take it in pill form
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.
😂 very true!
every elixir is a love elixir when you love elixirs :)
i took it and i ended up wanting more and more only to realise there's 5 companies in the whole country using it
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
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
He used to program in Elixir when he was at twitch
now we will make phoenix for gleam and call it thunderbird
Is elixir blazor but not Microsoft?
We've never heard anything like this before
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.
Crazy Good! And such a well written post to be able to capture the complex nuance in short sentences. Thanks.
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.
This sounds like a realistic Senior Dev take. “Use it a lot, but never in prod.” is a completely legit conclusion.
The BEAM VM solves a number of difficult problems very well and those same problems exists in other problem domains (i.e. managing a large system of telephones is a similar problem as managing a large number of async activities which is often a part of the business logic in web applications). IMHO hot-code reloading isn't one of those problems we have to deal with in our web applications; or if it is, we have developed other tools like containers and rolling deployments that make reasoning about the state of the system during a new deploy easier to reason about. Or the tolerance for rolling on new application processes isn't as stringent as it is for active phone calls. This is the basis on which I stay away from hot-code reload.
I moved from React to Phoenix and LiveView about a year ago. Never going back.
JS. JS is hell
Legit a legacy vanilla JS app almost made me quit dev because of how everything was strewn all over the place
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.
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.
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.
P
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 😂
Because social media developers only care about coding, they really dont care about make a product or solution. Just the fun of making it.
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.
What an odd joke/complain, are you annoyed by variety and innovation?
@@Erandros are you even a developer?
@@professormikeoxlong bruh
I have moved from Python to Elixir... I won't come back to anything else! Ruby syntax, Erlang ecosystem, beauty!
Making server side cool again? I feel like we just gone through a loop
Welcome to CS. I'm waiting for the inevitable backlash to cloud providers, and everyone runs back to in-house data centers.
@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.
@@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.
@@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...
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.
Wow this is incredible I haven’t used phoenix in a long time and I want to go back to it🎉 Amazing
Those saying that PHP already did this don't get it...
PHP already did this
@@DKLHensenYou don't get it.
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
Laravel copied LiveView. And I don't blame them
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
I feel like that every day I go to work... I miss Elixir so bad
absolutely loving elixir and phoenix- feeling much more productive than nextjs
So we're back to PHP?
laravel livewire
@@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.
@@glebtsoy4139 I'll get on that once php implements it
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.
I think both Elixir/BEAM and PHP have places in the future of development, Phoenix and Livebook are amazing and Laravel and Symfony are great for fast MVP work. I would assert the symptom you describe, paraphrased as “using half of AWS to achieve it” is often a failure of cloud engineering competency, in the case of PHP. That also applies to some Elixir apps’ infrastructure equally, though arguably less necessarily.
just came to make the "so we're back to PHP?" comment without doing reading up on anything for even 5 minutes
Recently picked up Elixir after being in JS for a decade and have to say it feels revolutionary.
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?
Like mfc updatedata(false)
Did Vercel... just use "The Conjoined Triangles of Success" for their graphic about blue-green deployments?
HA! Good spot
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
Why does Elixir need static types? It's pattern matching and testing workflow prevent the category of errors you're referring to
@@aucusticguitar8069 Lots of people do not understand that pattern matching is an alternative for static types... :(
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.
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.
Maybe this is the reason many of the offline-first tech that I like in theory has never gotten traction. Like, either you need the server or you don’t. Either you need the server, and you run on the user’s cell phone that’s always connected, or you run on their tablet/ laptop and they only pull you out when there’s Wi-Fi. (Or they use your phone as a mobile hotspot.)
This is the best theo. The educator with a great tone and not sounding pompous like in some videos.
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.
Wow this is so interesting, things are getting more fun and fun.
Let's goooo 🚀
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.
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.
Stop making sense. If we made web development solved and boring, how could we talk about the new mistak-- err... "technology" of the week?
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.
@@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.
@@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.
Nice. I don't know how much of this PHP is suited for, but I agree this is presented excellently.
PHP is suited for anything on the server-side. In the end you are just sending some plain html to a client.
Well, this is definitely the push I needed to check out Elixir/Phoenix. This looks really impressive.
Been using it for 5+ years now. Getting better all the time.
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.
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.
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.
So wait, server side includes were the way to go all along? I was about 11 or 12 when they were the standard way to include dynamic content in static pages so my memory and understanding may be off, but I swear that at least conceptually it's roughly the same idea
People love to rediscover shit in this industry and then pitch it as a gospel
5 years from now on the view independent APIs will be all the fashion again
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.
How does this compare to what Blazor does with Websockets?
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.
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.
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
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)
It is not. It will suck with poor network exactly the same way as Blazor.
@@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
@@hauleth Same goes for blazor btw, and idk why you think blazor sucks lol
@@dahahaka I didn't said that Blazor nor LiveView sucks. Just both technologies will suck when there is poor connection between server and client.
What field is this?
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.
imagine someone editing a big form and out of nowhere it change
Lol with great power comes great responsibility
Keeping realtime web socket connection comes with lots of issues
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.
Not a lot of issues, no, just some issues like anything in tech.
- 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.
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.
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.
@@lastrae8129 and noobs
Nobody is rewriting anything lol. This is just the infinite content mill going
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
Grandpa PHP has that "Told you so" face rn
Awesome
The end result (demoed in the intro) reminds me of how cool it was to work with Meteor ~10 years ago.
How is offline support?
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
"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?
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.
Let me guess: a gambling site?
@@ironhammer4095 Not that shady, but close 😅
It's so fucking cool!
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!
Drawers and stuff are things that JS does good. You don't need liveview for that
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
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.
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).
@@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.
@@Robert-zc8hrwell thats why you dont keep permissions in JWT.
@Duconi yeah I also have no idea how they are going edge cache their stuff given they serve everything over websockets
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
But not auth what was his main concern
@@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.
What drawing tool is Theo using at 21:14?
I think one of the overlooked advantages of the LiveView approach is how it simplifies things that used to take multiple solutions down to a single answer.
Want to send push notifications to a connected user when they get a message? Just send a message to the liveview process.
Want to have long-running asynchronous processes on the server that get killed when the user leaves? Just spawn a process off the liveview.
Want to track user presence? Have the liveview process handle it.
These are all things that used to require separate pub-sub systems and lots of code on the front end. Now, they are all handled with one solution.
I'm Brazilian, Elixir was developed by a Brazilian coincidence? I have been programming elixir for over years
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.
Can we do offline first PWA apps with live view? Seems limiting...
No lol
@@t3dotgg that's a huge load of functionality just boom, poof, gone..
@@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.
😂
@@t3dotgg liveview-svelte-pwa I am not sure is it a "offline first PWA apps with live view"...
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
Can someone explain to me why people prefer to use k8s and react for all these?
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
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? 🤔
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...
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.
@@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
So many vibes I wonder how long before we get a based reactivity updates
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.
I love Elixir and Phoenix so much
No, thank you. Isn't that what Blazor Server is already doing?
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.
Yes, and it comes with a bunch of issues.
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"?
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).
@@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.
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.
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.
brother it can scale to 1m websocket connections its all REAL-TIME. Quik does not even compare in the slightest
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.
I continue using react for react native, and for static sites, only use elixir for admin dashboards and graphql apis
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
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.
Why does he keep looking to the right side of the camera? Is he looking at his captors?
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.
You mean high latency? Because low latency is good as it's measured in seconds (or milliseconds).
I meant high
All these frameworks tend to make things really slow, development is slow, compiling is slow, browsing the result is slow. Misunderstand me correctly, we need development and new tech but many of the current technologies seem like worse versions of what we already had. Use the potential of Javascript correctly, do more clientside, minimize backend communication, try to deliver as much of the data as possible up front and only dynamically load that which can not be loaded up front. When I see APIs loading lists of 10-15 of something simple using JSON I want to go on a rampage.
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
Can’t wait till SPAs are the hot shit again in a few years 😂😂
Obv this breaks down for things which need frequent rerenders. Like a game for example
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 :)
Even react shits the bed for anything that is real-time. Canvas with WebGL/WebGPU is the only way to go.
Pease make a little course about phoenix :)
Damn, I guess I'm going back to Elixir... Even suspense is there now...
Every release makes me want to leave React. Only the food on the table makes me stay.
I'm making great money writing Elixir at work. Just keep an eye out :)
@@samjohns8381 may i know what kinds of web app ur company is building that requirs elixir as solution ?
It's exactly like hotwire for rails
Oh my, I hate you now.. You make me feel the URGE to come back to Elixir 😂😂
Thanks Theo, amazing awesome!!!! Gosh darn Theo finally speaking my language,, JSON oh man nuts, gRPC? brew your own?... toss around 60K lines of JSON... each call.. huh? Download the entire SPA just to get started.. huh? RAM is cheap Theo!
ELIXIR MENTIONED
oh
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.
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.
@@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...
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?
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.
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)
Using liveview in production for years and I didn’t have any problem with it
Can we use this with a templating language that is not horrible ?
Could be worse. It could use JSX 🤢
Is "basically just HTML" terrible?
This is all fun and games until every UI interaction takes 2 seconds to react because the server is overloaded.
Good luck overloading beam to an unresponsive state.
Google 1m websockets elixir chat. Still
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.
Hmm. This is possible without the framework. It does sound like a better way of doing websockets so i am curious about implementing this.
this is possible not only because of the framework, but also because of the language and virtual machine that handles the connections.
@@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.
HTMX ftw. Our JS devs love Go/Templ. No JS, yay! :)
the more the server does the more it cost to scale the application. A server should do the bare minimum in my opinion. The cost of going from 550 milisecond initial load to 50ms initial load is not worth in my opinion
Theorethically true, but - the BEAM processes are so lightweight that you can run millions of them on a single Raspberry Pi. OTP's horizontal scaling capabilities make it super easy to build a network of servers. Metal is cheaper than Functions when active runtime is above 67%. You also don't have additional costs related to in-memory stores, queues. Finally, and most importantly, unless you are running Google, developer time costs you significantly more than servers, and Elixir is famous for the ease of development it allows.
@@MrManafon I had some experiences with elixir and might be my typescript brain giving me headaches tbh (some pleroma and akkoma stuff for testing my own fedi software)
The Liveview runtime, the BEAM is a battle-tested beast. It was designed 40 years ago to handle concurrency and Fault-tolerance from the ground up. Way ahead of it's time. Look up Erlang-OTP.
@@MrManafon You won't be running "millions" of LiveView processes on a RPi, but it will be a long time before you need to go past 1 server.
LiveView payloads are usually smaller than the equivalent JSON payloads would be. Also LiveView has no problems scaling. It will be a long time before you need more than 1 server to handle the load.
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?
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.
@@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
@@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.
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
Elixir does have HTTP/gRPC APIs as well, if that is what you meant.
Or maybe in 1000 years or so HATEOAS became a real thing and it will make parsing everything way easier.
@@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
aha, ruby moneky patching in real time for server frontend application lol sounds really cool though
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