I’m pretty excited about LiveView as a way to sprinkle some interactivity on phoenix apps without having to venture out to JS land. Can see it being a pretty good way to enhance admin UIs and the likes.
In general I like the idea of enhancing server-side rendered HTML without writing JavaScript, and with narrowly defined roles for the framework JavaScript that’s currently needed for that to happen. But I think both this and Razor Components are wrong to tie that to a particular server-side language and framework.
May I point out Intercooler.js? It makes most reasonable uses of AJAX usable from declarative HTML attributes, and it doesn’t require architecting your server-side app around it.
One thing that intercooler approaches lack, and that requires a a clear server-side framework/library role is the fact that the LiveView components are stateful. It’s not only a matter of translating stateless HTTP requests to a server that patches parts of the page. Live views are processes on the server which hold state and can update the DOM at anytime, regardless of client events which may or may not be sent. This fact also allows us to do change tracking and send the minimal diffs on the wire that you see in the examples. That kind of optimization wouldn’t be possible without a stateful server.
Pardon my ignorance of Phoenix, but does this work by sticking a browser session to one server if the websocket connection drops, or does it rely on the transparent inter-server process communication in BEAM if you get a different server? Or does dropping the connection kill the component and you use error recovery to restart it on the new connection?
Phoenix websocket works horizontally. I believe it uses pg2 if I remember correctly to make sure messages are fanned out to connect servers. Though I may have that part wrong.
We don’t really know yet how well server-side Blazor (Razor Components) will scale with heavy use applications.
In principle, people could take this approach in other languages as well. But I think Elixir / Erlang are uniquely positioned to do it well, as LiveView is built on Phoenix Channels, which (because they use lightweight BEAM processes) can easily scale to keep server-side state for every visitor on your site: https://phoenixframework.org/blog/the-road-to-2-million-websocket-connections
On the other hand, the Elixir community is very friendly. :)
Is that comment supposed to contrast the friendly Elixir community with the JS community? Is the JS community considered unfriendly? It’s way, way bigger than the Elixir community, so there are bound to be some/more unfriendly people. Maybe it’s so big that the concept of a “JS community” doesn’t even make sense. It’s probably more like “Typescript community”, “React community”, “Node community”, etc… But there are a lot of friendly people and helpful resources out there in JS-land, in my experience. I hope others have found the same thing.
The Elixir community is still in the “we’re small and must be as nice as possible to new people so they’ll drink the koolaid” phase. The “community” such as it is is also heavily pulled from job shops and the conference circuit, so there’s a big factor too.
Past the hype it’s a good and servicable language, provided you don’t end up on a legacy codebase.
From bitter experience, I’d say it would be an Elixir codebase, written in the past 4 or 5 years, spanning multiple major releases of Ecto and Phoenix and the core language, having survived multiple attempts at CI and deployment, as well as hosting platforms. Oh, and database drivers of varying quality as Ecto got up to speed. Oh oh, and a data model that grew “organically” (read: wasn’t designed) from both an early attempt at Ecto as well as being made to work with non-Ecto-supported DB backends, resulting it truly delightful idioms and code smells.
Oh, and because it is turning a profit, features are important and spending time doing things that might break the codebase are somewhat discouraged.
Elixir for green-field projects is absolutely a joy…brown-field Elixir lets devs just do really terrible heinous shit.
Elixir for green-field projects is absolutely a joy…brown-field Elixir lets devs just do really terrible heinous shit.
Totally agree, but I would say that significantly more heinous shit is available to devs in Ruby or another dynamic imperative language. The Elixir compiler is generally stricter and more helpful, and most code is just structured as a series of function calls rather than as an agglomeration of assorted stateful objects.
The refactoring fear is real though. IMO the only effective salve for that sickness is strong typing (and no, Dialyzer doesn’t count).
I mean, it’s really quite good in a number of ways, and the tooling is really good. That said, there’s nothing by construction that will keep people from doing really unfortunate things.
😊 I can see how it sounded that way, but I didn’t mean to imply anything about anyone else. The parent post said the Elixir community is small, so I was responding to that concern.
I’m not what you mean by “trying to polemic”, that doesn’t make sense to me as a phrase, but it was a genuine question about whether the JS community is considered to be unfriendly. I’d be happy to be told that such a question is off-topic for the thread, and I certainly don’t want to start a flame war, but I didn’t bring up the friendliness of the community. I’m sure the author didn’t mean harm, but I read (perhaps incorrectly) that part of their reply as part of an argument for using Elixir over JS to solve a problem.
What I meant to say was: “If this looks like it could be a good fit for thing you want to do, but you’re daunted by the idea of learning Elixir, don’t worry! We are friendly.”
I meant starting a controversy, sorry for my poor English!
I’m sorry if it felt harsh, that wasn’t what I tried to share. I really thought your goal was to start this flame war.
Every community has good and bad actors. Some people praise a lot some communities, but I don’t think they mean the others aren’t nice either.
The only thing that I could think of is that smaller communities have to be very careful with newcomers, because it helps to grow the community. JS people don’t need to be nice with each other, the community and the project are way pas that need. So I guess you would find a colder welcome than with a tiny community.
I’m not ignorant (well I am, but not about this): polemic is indeed an English word, but it’s not a verb. The phrase “trying to polemic” doesn’t make sense in English, it requires interpretation, which makes the meaning unclear. I can think of two interpretations for “trying to polemic” (there may be others) in the context of the comment:
My comment was polemic
I was attempting to start a polemical comment thread, aka a flame war. With the later clarification that seems like what the author was thinking.
The thing is that not everyone is at your level of English proficiency. You’re having a discussion here with people from around the world, you’ll need to make a couple of adjustments for expected quality of English and try to get the rough meaning of what they’re saying, otherwise you’ll be stuck pointing out grammatical errors all day.
I wasn’t really trying to point out an English error, and perhaps I did a poor job of that. I stand by the claim that it is an English error though.
I work with non-native English speakers all day, I’m aware of the need to try and understand other people and to make sure we’re on the same page. I’ll give a lot of slack to anyone, native or non-native, who’s trying to express themselves. The problem with the phrase “I feel you’re just trying to polemic on the subject’ is that at least some of the interpretations change the meaning. On the one hand, it could be saying that my comment was polemic, on the other it could be saying that my comment was trying to start a polemical thread. It’s not the same thing. And, for what it’s worth, if you’re going to throw an uncommon (and quite strong) English word like “polemic” out there it’s best if you correctly understand the usage. If the author had accused me of trolling, which is I think what they meant, that would have been both clearer and more accurate (though my intent was not to troll)
I have never used Elixir or Phoenix myself but have used Clojure and Elixir looks like an alternative to it. About two weeks ago I posted a question in here asking how Phoenix.LiveView related to an Elixir library called Texas, unfortunately I pasted in the wrong link in the comment which made it look like a spam made by a bot.
Either way I’ll try to ask again now: Have you seen Texas and if so, how would you compare the two?
Just saw this. I have heard of Texas, but don’t know enough to compare it with LiveView. My understanding is that Texas was announced at the same conference where LiveView was announced. LiveView being the creation of Chris McCord (creator of Phoenix), I think it’s the more likely of the two to see wide adoption. But possibly there will be cross-pollination.
I’m pretty excited about LiveView as a way to sprinkle some interactivity on phoenix apps without having to venture out to JS land. Can see it being a pretty good way to enhance admin UIs and the likes.
In general I like the idea of enhancing server-side rendered HTML without writing JavaScript, and with narrowly defined roles for the framework JavaScript that’s currently needed for that to happen. But I think both this and Razor Components are wrong to tie that to a particular server-side language and framework.
May I point out Intercooler.js? It makes most reasonable uses of AJAX usable from declarative HTML attributes, and it doesn’t require architecting your server-side app around it.
One thing that intercooler approaches lack, and that requires a a clear server-side framework/library role is the fact that the LiveView components are stateful. It’s not only a matter of translating stateless HTTP requests to a server that patches parts of the page. Live views are processes on the server which hold state and can update the DOM at anytime, regardless of client events which may or may not be sent. This fact also allows us to do change tracking and send the minimal diffs on the wire that you see in the examples. That kind of optimization wouldn’t be possible without a stateful server.
Pardon my ignorance of Phoenix, but does this work by sticking a browser session to one server if the websocket connection drops, or does it rely on the transparent inter-server process communication in BEAM if you get a different server? Or does dropping the connection kill the component and you use error recovery to restart it on the new connection?
Phoenix websocket works horizontally. I believe it uses pg2 if I remember correctly to make sure messages are fanned out to connect servers. Though I may have that part wrong.
You don’t have to write JavaScript, you have to write Elixir - which has a much smaller community around it than JavaScript does.
This does look cool though, I just wish there were some live examples I could play with in my browser.
On the other hand, the Elixir community is very friendly. :)
Supposedly something like LiveView is coming to .NET - https://codedaze.io/introduction-to-server-side-blazor-aka-razor-components/ - but the post says:
In principle, people could take this approach in other languages as well. But I think Elixir / Erlang are uniquely positioned to do it well, as LiveView is built on Phoenix Channels, which (because they use lightweight BEAM processes) can easily scale to keep server-side state for every visitor on your site: https://phoenixframework.org/blog/the-road-to-2-million-websocket-connections
Is that comment supposed to contrast the friendly Elixir community with the JS community? Is the JS community considered unfriendly? It’s way, way bigger than the Elixir community, so there are bound to be some/more unfriendly people. Maybe it’s so big that the concept of a “JS community” doesn’t even make sense. It’s probably more like “Typescript community”, “React community”, “Node community”, etc… But there are a lot of friendly people and helpful resources out there in JS-land, in my experience. I hope others have found the same thing.
The Elixir community is still in the “we’re small and must be as nice as possible to new people so they’ll drink the koolaid” phase. The “community” such as it is is also heavily pulled from job shops and the conference circuit, so there’s a big factor too.
Past the hype it’s a good and servicable language, provided you don’t end up on a legacy codebase.
Sounds like Rails, all over again.
Who hurt you @friendlysock?
How would you define ‘legacy codebase’? I’m assuming it’s something other than ‘code that is being used to turn a profit’..
Ha, you’re not wrong! I like that definition.
From bitter experience, I’d say it would be an Elixir codebase, written in the past 4 or 5 years, spanning multiple major releases of Ecto and Phoenix and the core language, having survived multiple attempts at CI and deployment, as well as hosting platforms. Oh, and database drivers of varying quality as Ecto got up to speed. Oh oh, and a data model that grew “organically” (read: wasn’t designed) from both an early attempt at Ecto as well as being made to work with non-Ecto-supported DB backends, resulting it truly delightful idioms and code smells.
Oh, and because it is turning a profit, features are important and spending time doing things that might break the codebase are somewhat discouraged.
Elixir for green-field projects is absolutely a joy…brown-field Elixir lets devs just do really terrible heinous shit.
Totally agree, but I would say that significantly more heinous shit is available to devs in Ruby or another dynamic imperative language. The Elixir compiler is generally stricter and more helpful, and most code is just structured as a series of function calls rather than as an agglomeration of assorted stateful objects.
The refactoring fear is real though. IMO the only effective salve for that sickness is strong typing (and no, Dialyzer doesn’t count).
So you’re saying that Elixir is just another programming language? It’s not the Second Coming or anything?
I mean, it’s really quite good in a number of ways, and the tooling is really good. That said, there’s nothing by construction that will keep people from doing really unfortunate things.
So, um, I guess to answer your question: yep. :(
😊 I can see how it sounded that way, but I didn’t mean to imply anything about anyone else. The parent post said the Elixir community is small, so I was responding to that concern.
I feel you’re just trying to polemic on the subject… The author of this comment probably didn’t mean harm, don’t make it read like so.
I’m not what you mean by “trying to polemic”, that doesn’t make sense to me as a phrase, but it was a genuine question about whether the JS community is considered to be unfriendly. I’d be happy to be told that such a question is off-topic for the thread, and I certainly don’t want to start a flame war, but I didn’t bring up the friendliness of the community. I’m sure the author didn’t mean harm, but I read (perhaps incorrectly) that part of their reply as part of an argument for using Elixir over JS to solve a problem.
What I meant to say was: “If this looks like it could be a good fit for thing you want to do, but you’re daunted by the idea of learning Elixir, don’t worry! We are friendly.”
I meant starting a controversy, sorry for my poor English! I’m sorry if it felt harsh, that wasn’t what I tried to share. I really thought your goal was to start this flame war.
Every community has good and bad actors. Some people praise a lot some communities, but I don’t think they mean the others aren’t nice either.
The only thing that I could think of is that smaller communities have to be very careful with newcomers, because it helps to grow the community. JS people don’t need to be nice with each other, the community and the project are way pas that need. So I guess you would find a colder welcome than with a tiny community.
Hey there, polemic is a legit English word, so don’t be sorry for someone else’s ignorance! :)
I’m not ignorant (well I am, but not about this): polemic is indeed an English word, but it’s not a verb. The phrase “trying to polemic” doesn’t make sense in English, it requires interpretation, which makes the meaning unclear. I can think of two interpretations for “trying to polemic” (there may be others) in the context of the comment:
The thing is that not everyone is at your level of English proficiency. You’re having a discussion here with people from around the world, you’ll need to make a couple of adjustments for expected quality of English and try to get the rough meaning of what they’re saying, otherwise you’ll be stuck pointing out grammatical errors all day.
I wasn’t really trying to point out an English error, and perhaps I did a poor job of that. I stand by the claim that it is an English error though.
I work with non-native English speakers all day, I’m aware of the need to try and understand other people and to make sure we’re on the same page. I’ll give a lot of slack to anyone, native or non-native, who’s trying to express themselves. The problem with the phrase “I feel you’re just trying to polemic on the subject’ is that at least some of the interpretations change the meaning. On the one hand, it could be saying that my comment was polemic, on the other it could be saying that my comment was trying to start a polemical thread. It’s not the same thing. And, for what it’s worth, if you’re going to throw an uncommon (and quite strong) English word like “polemic” out there it’s best if you correctly understand the usage. If the author had accused me of trolling, which is I think what they meant, that would have been both clearer and more accurate (though my intent was not to troll)
I have never used Elixir or Phoenix myself but have used Clojure and Elixir looks like an alternative to it. About two weeks ago I posted a question in here asking how Phoenix.LiveView related to an Elixir library called Texas, unfortunately I pasted in the wrong link in the comment which made it look like a spam made by a bot.
Either way I’ll try to ask again now: Have you seen Texas and if so, how would you compare the two?
Just saw this. I have heard of Texas, but don’t know enough to compare it with LiveView. My understanding is that Texas was announced at the same conference where LiveView was announced. LiveView being the creation of Chris McCord (creator of Phoenix), I think it’s the more likely of the two to see wide adoption. But possibly there will be cross-pollination.
Huh, what a coincidence. Thanks!
[Comment removed by author]
[Comment removed by author]
[Comment removed by author]