I'm so excited for Phoenix 1.6. I think Phoenix was almost onto gold with LiveView when introduced, but it was still a little rough around the edges. But Phoenix 1.6 should sand away all the roughness, and we'll be in an awesome place.
Basically, the issue before, IMO, was kind of a tension between "live controllers" and (they call them "dead" but I prefer "static") static controllers. You couldn't necessarily interleave them super well, and factored templates had issues when used in one place or another. (I'm not an expert here, this was just from some testing and dabbling.)
But now (or well, soon), there's going to be a unified "heex" format which works in both. You write components almost like React components, their structure is parsed to some extent to catch simple typos and bugs, and can pass in "props" as arguments. And said components can be re-used in both live and static controllers.
Basically, channels were Phoenix's killer feature, LiveView sort of abused them to show a promising new way of developing web apps, and now I'm hopeful we're just about at a point where Phoenix can settle down into a new normal with function components on hex.pm and easy and pervasive LiveView pages and widgets, added in easily to your existing, standard Phoenix apps.
And, combined with the recent announcement of the removal of node+npm+webpack by default, in favor of esbuild, I think Phoenix 1.6 is going to be a no-brainer choice for any new web apps going forward.
They're also separating out Phoenix.View so there will be less dependencies on using Phoenix view rendered templates for things like email or PDF generation outside of a web layer.
This is great news for me! Around 8 months ago I built a chess website using Phoenix (heavily using LiveView) and TailwindCSS. My two biggest complaints were exactly what you said:
1. LiveViews were kind of weird to fit in, as they were a separate format
2. Webpack was the bain of my existence, it was slow and hard to figure out as a first time webdev
Glad to hear this is being fixed! Looks like I'm going to have to go back and update the site
Wow, this is great news! I had not heard about that, but making live and static controllers work together has always been a pain point for me. Even with that pain point Phoenix has been my go to. But fixing that will be huge.
I haven't use LiveView since the introduction of components, it'll be a good occasion to try it again.
But to be honest about the "no-brainer" part, I'll probably stick to using Phoenix for apis and websockets because I'm personally firm on not using a framework that use the (IMHO) outdated layout->view model for displaying HTML.
perhaps you could have a glance at "surface" and see if it's what you want? I think the new .heex format also gives the basis to build what you want even if surface isn't the answer for you?
For those coming into this that aren't of an Elixir background, here's some of the things that make BEAM (Erlang VM that Elixir is built on) interesting for soft real-time features:
* BEAM provides out-of-the-box capability to network nodes together. This is extremely important in real-time flows because server A may originate a message that needs to get pushed to a user connected to server B + C (2 tabs open). The capability to both connect + send messages between nodes is built in.
* The process model in the BEAM provides a really natural fit for WebSocket connections. Each connection is its own process, and other processes are spawned off of that for various needs. The benefit here is that a failure in one process (connection drop, code error, crash, etc) won't affect other users. It's not an issue of whether the code is written well to prevent it, it's just intrinsic to the runtime. State is also stored per-process, which is convenient when it comes to writing your application.
Phoenix itself has a really nice abstraction over WebSockets (Channels, which this post goes in depth on). I won't say too much since the article does, but it's just really enjoyable to work with. Also, Phoenix LiveView is built on channels, so knowing channels provides some benefit there.
Yes, that's a fair point. I should have written BEAM/OTP because they're separate things. BEAM enables the process model, but the implementation of things like networking is in OTP. I'm not sure how far deep the actual process implementation goes, (is it in BEAM or OTP?) I think it's BEAM but I could be wrong. I'm not really going that low in the stack.
It's neat to see channels getting some love here! They were the main reason I started Phoenix seven or so years ago, and they were the first major feature to land in the framework. I'm happy to answer any questions here about channels or Phoenix in general.
Apparently I'm out of the loop, but it took a fair amount of reading to discover that Phoenix is a framework for Elixir. It's only mentioned in passing on the Phoenix project's homepage, very easy to miss.
Just strikes me as odd and makes it less approachable. Most other projects I've encountered present themselves as a part of the language's ecosystem where it seems like it's assumed here. E.g. React calls itself a JavaScript library.
This powers the realtime sync at my startup. its the closests thing Ive ever found to "just drop it in and it just works" for self hosted websocket systems.
Have you looked at Pushpin [1]? (disclosure: I'm the lead dev). The goal is to be able to add it to anything, rather than requiring a certain language.
I haven't, thanks for the pointer! However, the main reason I chose Elixir/Phoenix for this project was not for the language itself, but for the runtime/VM (BEAM), which is battle-tested for such use cases.
Whenever a client connects (whether the first time, or on reconnect) or sends a message, Pushpin sends an HTTP request to a configured backend to retrieve WebSocket messages to be delivered to the client. This can be used to restore state on reconnect.
If you mean how is reconnection handled on the client side, that's up to the client. Pushpin is a server-side component with no client library. But the client could use a WebSocket library with reconnection ability, like reconnecting-websocket.
> "just drop it in and it just works" for self hosted websocket systems
I was also been underwhelmed by options in this area, so I've been working on a Rust library called Jamsocket[1]. The idea is that all you need to do is implement a trait, overload the functions for the events you want to handle (new connection, message, etc.) and deploy it.
I still need to work on production aspects of it, but it's in a state where you can play with it for local development, so I figured I'd share it here in case any Rust developers want to tinker with it.
Same here. It was a breeze to build a scalable, real-time auction system with Phoenix Channels at the previous startup I was working at. There are definitely "devil in the details" corner cases, but for the most part it works beautifully without much effort :)
That said, phoenix/elixir's live view accomplishes the same thing in a database agnostic way. its sync system is built on channels and scales WAY better than meteor ever could.
try phoenix's liveview. Beam is built for scaling thousands to millions of stateful processes on a cluster. That at its core was the biggest bottleneck for meteor and for elixir, its more or less a solved problem unless you're talking about google or amazon levels of traffic
it means the infrastructure for doing a thing is hosted on your machine as oppossed to being served by a third party vendor on their servers. Think pusher or pubnub for instance.
I normally don't like complaining about terminology but "real time" means something: deadlines. If you don't have a deadline, you don't have a real time system. The coopting of the word is making it more difficult to find and list resources if you don't already know how to prefix it with "soft" or "hard."
Wow, I'd never heard this terminology before but I just spent an unnecessary length of time reading the Wikipedia page on "Real-time computation" and it's interesting set of technical considerations I hadn't thought much about before. Thanks for making me aware of this.
I've been really interested in Phoenix since seeing some of those 1 million simultaneous connections demos, but I also know that it's possible to build unrealistic demos that produce great statistics.
So, I'm really curious if there are any people here who are able to get such significant performance benefits from the framework for "real" scenarios - high distributed traffic with occasional writes and lots of cached database reads, game lobbies, etc. - stuff that simply wouldn't be possible with another framework like Spring or Flask. Is the hype worth it?
This podcast episode[1] is about exactly this, scaling live chat to a few 100k users, on a small number of machines in a real word scenario where the users are all signing on in a short time span to live screen a film and chat about it.
I'm not a seasoned Elixir dev but I wrote an article some months ago about how I used many Elixir & Phoenix features (including Channels & PubSub) for a new feature on my side project : https://conradfr.github.io/ProgRadio/
Tl;dr: Apparently Phoenix is an Erlang / Elixir thing, and something for those of us not on Erlang to pay no slight attention to.
It would have been better to put that in the first paragraph, or even the title, so we would not need to scroll past reams of breathless hype trying to discover any single thing that we might have some use for someday.
A million connections on one server is no great trick today. It's table stakes.
What protocol is this "channel" thing using behind? Because I went through the documentation and they don't mention anything of it. I can't understand why.
Basically, the issue before, IMO, was kind of a tension between "live controllers" and (they call them "dead" but I prefer "static") static controllers. You couldn't necessarily interleave them super well, and factored templates had issues when used in one place or another. (I'm not an expert here, this was just from some testing and dabbling.)
But now (or well, soon), there's going to be a unified "heex" format which works in both. You write components almost like React components, their structure is parsed to some extent to catch simple typos and bugs, and can pass in "props" as arguments. And said components can be re-used in both live and static controllers.
Basically, channels were Phoenix's killer feature, LiveView sort of abused them to show a promising new way of developing web apps, and now I'm hopeful we're just about at a point where Phoenix can settle down into a new normal with function components on hex.pm and easy and pervasive LiveView pages and widgets, added in easily to your existing, standard Phoenix apps.
And, combined with the recent announcement of the removal of node+npm+webpack by default, in favor of esbuild, I think Phoenix 1.6 is going to be a no-brainer choice for any new web apps going forward.