4 ms·

> My dream stack that I am using for my business is Phoenix, Live View and Stimulus.js with Tailwind. I am curious, why both LiveView and Stimulus.js? Why and

> My dream stack that I am using for my business is Phoenix, Live View and Stimulus.js with Tailwind. I am curious, why both LiveView and Stimulus.js? Why and how are you combining the two together?

sph 3y ago
For very small interactions, there is no need for a round trip and state held on the server. Imagine a disappearing burger menu, or a tooltip widget, or a "click here to copy to clipboard" link. For those sprinkles of interactivity, you need JS and Stimulus is ideal for that use case. I just have my Live View process render <input type="text" data-controller="copy-on-click" value="..." /> which is easy to understand and plays great with Live View's model. Don't forget that JS was born for this goal: small snippets of interactive behaviour; it was never meant to be the entire system.
- clessg 3y ago
  Oh wow that's brilliant, I hadn't ever considered combining LiveView and Stimulus.js. If you don't mind me asking, what is the benefit over using `phx-hook`? Portability/interop with RoR, or? Either way, I'm shipping it to production immediately!
  - sph 3y ago
    phx-hook is a nice convenience that works only with Live View. It seems to me a better investment of my time to learn a solution that's just as lightweight, but I can use everywhere (i.e. in other projects, or in static non-Liveview pages)
    - clessg 3y ago
      Makes a lot of sense, thank you! I'm not much into Rails these days, but that's one thing I really appreciate about RoR's "frontend" efforts - their work tends to be quite reusable across ecosystems, e.g. Stimulus, Turbo, and apparently even Hotwire itself [0]. Heck, that even seems to apply to a lot of their non-frontend stuff, such as MRSK [1]. [0] https://www.akshaykhot.com/using-hotwire-without-rails/ https://www.akshaykhot.com/using-hotwire-without-rails/ [1] https://mrsk.dev/ https://mrsk.dev/
      - sph 3y ago
        Yeah RoR with those libraries are also moving towards the "as little JS as possible" approach as well. Client-side logic makes sense in a vacuum, but then your crappy React app is in fact a distributed system, with all the complexity that entails. The radical idea of Liveview and similar efforts is that it's better just to return to basics and keep the logic on the server. It would be lunacy to try and build a distributed system with Javascript, yet that's the direction the SPA world is/was taking us.
- brainbag 3y ago
  I've seen alpinejs mentioned alongside LiveView, what benefits do you see to Stimulus over alpine?
  - sph 3y ago
    I've never used alpine, so I'm not the one to ask. I've just given it a cursory look a couple years ago. I do not like how it's trying to fit logic in custom HTML attributes. Doesn't look great to me, and would pollute my Liveview templates with a matryoshka doll of nested logic: There's a top-level Elixir module, which contains a HEEX string that creates HTML, which itself contains Alpine.js logic as an attribute. Feels cleaner to me to just create a new .js file that exports a controller, and just instantiate it from LiveView (which still pollutes the HTML, but much less than Alpine does) That said, there is no good or bad answer. Alpine or Stimulus are certainly better than instantiating Vue or React. HTMX could fit very nicely as well. Use what you're comfortable with.
  - AlchemistCamp 3y ago
    I always avoided Alpine because it required allowing “unsafe-eval” in the Content Security Policy headers, which defeats a lot of the purpose.
- pbowyer 3y ago
  Thanks for the info, most examples I'd seen of Stimulus.js used it for making server requests which seemed to double up with LiveView. Am I right that its main distinguisher over other JS frameworks is using controllers, and loading and initialising those on-demand?
- AlchemistCamp 3y ago
  LiveView.JS was added a few minor versions ago to handle most of those needs without hooks or extra 3rd-party deps: https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.JS.html https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.JS.htm...

> My dream stack that I am using for my business is Phoenix, Live View and Stimulus.js with Tailwind. I am curious, why both LiveView and Stimulus.js? Why and how are you combining the two together?

sph 3y ago

For very small interactions, there is no need for a round trip and state held on the server. Imagine a disappearing burger menu, or a tooltip widget, or a "click here to copy to clipboard" link. For those sprinkles of interactivity, you need JS and Stimulus is ideal for that use case. I just have my Live View process render <input type="text" data-controller="copy-on-click" value="..." /> which is easy to understand and plays great with Live View's model. Don't forget that JS was born for this goal: small snippets of interactive behaviour; it was never meant to be the entire system.

clessg 3y ago
Oh wow that's brilliant, I hadn't ever considered combining LiveView and Stimulus.js. If you don't mind me asking, what is the benefit over using `phx-hook`? Portability/interop with RoR, or? Either way, I'm shipping it to production immediately!
- sph 3y ago
  phx-hook is a nice convenience that works only with Live View. It seems to me a better investment of my time to learn a solution that's just as lightweight, but I can use everywhere (i.e. in other projects, or in static non-Liveview pages)
  - clessg 3y ago
    Makes a lot of sense, thank you! I'm not much into Rails these days, but that's one thing I really appreciate about RoR's "frontend" efforts - their work tends to be quite reusable across ecosystems, e.g. Stimulus, Turbo, and apparently even Hotwire itself [0]. Heck, that even seems to apply to a lot of their non-frontend stuff, such as MRSK [1]. [0] https://www.akshaykhot.com/using-hotwire-without-rails/ https://www.akshaykhot.com/using-hotwire-without-rails/ [1] https://mrsk.dev/ https://mrsk.dev/
    - sph 3y ago
      Yeah RoR with those libraries are also moving towards the "as little JS as possible" approach as well. Client-side logic makes sense in a vacuum, but then your crappy React app is in fact a distributed system, with all the complexity that entails. The radical idea of Liveview and similar efforts is that it's better just to return to basics and keep the logic on the server. It would be lunacy to try and build a distributed system with Javascript, yet that's the direction the SPA world is/was taking us.
brainbag 3y ago
I've seen alpinejs mentioned alongside LiveView, what benefits do you see to Stimulus over alpine?
- sph 3y ago
  I've never used alpine, so I'm not the one to ask. I've just given it a cursory look a couple years ago. I do not like how it's trying to fit logic in custom HTML attributes. Doesn't look great to me, and would pollute my Liveview templates with a matryoshka doll of nested logic: There's a top-level Elixir module, which contains a HEEX string that creates HTML, which itself contains Alpine.js logic as an attribute. Feels cleaner to me to just create a new .js file that exports a controller, and just instantiate it from LiveView (which still pollutes the HTML, but much less than Alpine does) That said, there is no good or bad answer. Alpine or Stimulus are certainly better than instantiating Vue or React. HTMX could fit very nicely as well. Use what you're comfortable with.
- AlchemistCamp 3y ago
  I always avoided Alpine because it required allowing “unsafe-eval” in the Content Security Policy headers, which defeats a lot of the purpose.
pbowyer 3y ago
Thanks for the info, most examples I'd seen of Stimulus.js used it for making server requests which seemed to double up with LiveView. Am I right that its main distinguisher over other JS frameworks is using controllers, and loading and initialising those on-demand?
AlchemistCamp 3y ago
LiveView.JS was added a few minor versions ago to handle most of those needs without hooks or extra 3rd-party deps: https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.JS.html https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.JS.htm...