I like to use these things so I don't have to use JS for business and server-side logic, so I don't have to replicate certain things on both ends, and so I don't have to write myself a web API just so two applications I control can talk to each other. I have no problem writing JS for more complex UI stuff which is what I originally learned JS to do, and I enjoy it (though I enjoy the outcome more than the language). I know I'm not the only one who feels this way but I'm probably a minority.in
Well, React markets itself as a library and not a framework. This implies there is some overhead of using a framework. There isn't really - you really can just use what you need from a framework like Phoenix and ship it. The parts you don't need, you don't usually have to learn.
What does React provide for the use case of clicking on things and submitting forms, and having the feedback update in place instead of a full page reload? For me it's worse than vanilla js unless I use uncontrolled components, which isn't suggested by the React docs. https://dev.to/kevinkh89/how-to-solve-input-delay-lagging-in...
That's a conflation. I'm certain for at least some, the choice is more about using a single language than avoiding JS. I'm sure there are people using htmx who use a JS backend. That there are at least 5 LiveView clones for JS also are evidence that there's a desire to use JS for both front and back end for dynamic websites: https://github.com/liveviews/liveviews#javascripttypescript
Not only has it been an option for a long time, it’s also popular. Next.js on Vercel is more or less a goto these days. I don’t see a trend of people avoiding JS, much the opposite
Exactly. So if JS has been able to do something for a long time, why would someone create new tools in different languages that do similar things? Because they don't want to write JS...
Nope. What I'm saying is entirely compatible with my earlier statement.
More specifically they want to use one language for the front and back end
What I mean here is exactly what I mean. Excuse the tautology because I don't think I can express it any clearer. It was in contrast to this:
I believe it's pretty clear that htmx (and Phoenix) exist (at least in part) because people specifically _do not_ want to use Javascript.
Taking your example, Phoenix Liveview exists because Elixir developers want to use the same language across the stack. This might be because they are unfamiliar with JS, and learning a new language might be a pain. Or perhaps they are familiar with JS, but the context switch to another language still presents enough friction to avoid it. Choosing a single-language stack doesn't imply an aversion to JS in particular.
~60 pages on a 1920/1080 monitor, and looks to first example, with stuff like this.
Finally the forth function render/1 receives the assigns argument which contains the :val state and renders the template using the @val template variable.
The render/1 function renders the template included in the function. The ~H""" syntax just means "treat this multiline string as a LiveView template" The ~H sigil is a macro included when the use Phoenix.LiveView is invoked at the top of the file.
The resource looks excellent, but I think it demonstrates that this is more complex than the equivalent Rails.
Which is not even a criticism of Phoenix - it obviously has a lot of power, and "scales right up TM". But I wouldn't think it was a "just do this" kind of a thing.
Comments
“Just”? It is a decent learning curve. Might as well say “why not just use React”.
I believe it's pretty clear that htmx (and Phoenix) exist (at least in part) because people specifically _do not_ want to use Javascript.
Instead they'll write element attribute monstrosities. We've been here at least twice in history already.
I like to use these things so I don't have to use JS for business and server-side logic, so I don't have to replicate certain things on both ends, and so I don't have to write myself a web API just so two applications I control can talk to each other. I have no problem writing JS for more complex UI stuff which is what I originally learned JS to do, and I enjoy it (though I enjoy the outcome more than the language). I know I'm not the only one who feels this way but I'm probably a minority.in
My point is that in terms of complexity and amount to learn, I bet Phoenix would be equal to React. Regardless of other reasons for choosing either.
Therefore "Just use Phoenix". It's like saying manual transmission cars suck, just learn to fly a plane.
I find Phoenix way more complicated than React and I don't think it's even close
Well, React markets itself as a library and not a framework. This implies there is some overhead of using a framework. There isn't really - you really can just use what you need from a framework like Phoenix and ship it. The parts you don't need, you don't usually have to learn.
What does React provide for the use case of clicking on things and submitting forms, and having the feedback update in place instead of a full page reload? For me it's worse than vanilla js unless I use uncontrolled components, which isn't suggested by the React docs. https://dev.to/kevinkh89/how-to-solve-input-delay-lagging-in...
More specifically they want to use one language for the front and back end
Well…yes, and that they don’t want that language to be JavaScript.
That's a conflation. I'm certain for at least some, the choice is more about using a single language than avoiding JS. I'm sure there are people using htmx who use a JS backend. That there are at least 5 LiveView clones for JS also are evidence that there's a desire to use JS for both front and back end for dynamic websites: https://github.com/liveviews/liveviews#javascripttypescript
You’ve been able to do this in JS for over a decade now. So…
Not only has it been an option for a long time, it’s also popular. Next.js on Vercel is more or less a goto these days. I don’t see a trend of people avoiding JS, much the opposite
Exactly. So if JS has been able to do something for a long time, why would someone create new tools in different languages that do similar things? Because they don't want to write JS...
It's like you forgot what we were discussing?
Nope. What I'm saying is entirely compatible with my earlier statement.
What I mean here is exactly what I mean. Excuse the tautology because I don't think I can express it any clearer. It was in contrast to this:
Taking your example, Phoenix Liveview exists because Elixir developers want to use the same language across the stack. This might be because they are unfamiliar with JS, and learning a new language might be a pain. Or perhaps they are familiar with JS, but the context switch to another language still presents enough friction to avoid it. Choosing a single-language stack doesn't imply an aversion to JS in particular.
And the developers didn't want to use JS...
But yeah I'll bail here. Best of luck.
Here's a tutorial and the docs of forms: https://github.com/dwyl/phoenix-liveview-counter-tutorial https://hexdocs.pm/phoenix_live_view/form-bindings.html
I think the learning curve is not all that steep.
~60 pages on a 1920/1080 monitor, and looks to first example, with stuff like this.
The resource looks excellent, but I think it demonstrates that this is more complex than the equivalent Rails.Which is not even a criticism of Phoenix - it obviously has a lot of power, and "scales right up TM". But I wouldn't think it was a "just do this" kind of a thing.