Live data from Hacker News

Stimulus.js 2.0

discourse.stimulusjs.org

21–30 of 140 posts

Re: Stimulus.js 2.0

#21

Is there a convincing Stimulus vs. React-Rails post anywhere?

Stimulus is paired with Turbolinks, which doesn't play well with almost anything in the JS ecosystem.

This used to be accurate in the days of auto initializing jquery plugins, but probably isn’t the case today if you’re actually using stimulus.

Re: Stimulus.js 2.0

#22

Alpine.js is worth a look as well [1]. I've been working with it as part of the newly christened "PETAL stack" [2] of Phoenix, Elixir, Tailwind, Alpine.js, and LiveView. [1] https://css-tricks.com/alpine-js-the-javascript-framework-th... [2] https://thinkingelixir.com/podcast-episodes/021-tailwind-css...

Do you use Alpine with Turbolinks?

Re: Stimulus.js 2.0

#23
post #9
post #7

Earlier quoted context omitted.

I like these libraries but have the same concerns. One alternative that might be worth a look is htmx (the new library based on intercooler.js): https://htmx.org/

Htmx is more like all „we try to solve everything for you but fail“ solutions. The good part of stimulus is that it is only a binding library, no automatic content refetch etc. solution

How does htmx fail?

Re: Stimulus.js 2.0

#24

Is there a convincing Stimulus vs. React-Rails post anywhere?

They are both JS frameworks, but they are fundamentally different approaches.

React (and React-rails) moves rendering / state / logic clientside. You can use tools like react-rails to more easily pass data from your Rails controller to your react components (basically conveniences to create props from instance variables).

Stimulus doesn't handle rendering at all. It's intended to be used for small little "sprinkles" of JavaScript (think things like: showing / hiding content, toggling classes, basic event handlers). If you used to write jQuery snippets to wire up a click event to run ~5-10 lines of JS, then you might look at Stimulus as a more modern implementation (es6, mutationobserver, etc). Stimulus plays nicely with Turbolinks since it needs existing HTML (servered rendered from normal Rails views) to attach to.

You're basically looking at two diverging paths: do you go down a JS-driven SPA application with React (or some kind of hybrid where you have React do parts of the page) or do you opt for Basecamp's "I cant belive its not a SPA" approach with Turbolinks, server-rendered HTML, and Stimulus for small interactivity.

Here's a talk I gave at the London Ruby meetup about Stimulus and in what contexts you might want to use (or not use it): https://assets.lrug.org/videos/2020/september/matt-swanson-s...

Re: Stimulus.js 2.0

#26

A modest JavaScript framework for the HTML you already have Are they implying one shouldn't use it if you don't have any HTML already?

Yes. It is for "JS Sprinkles" on your existing HTML. This makes it "modest" compared to something like React that would typically generate HTML/DOM for you.

To understand their philosophy, see DHH's blog post announcing Stimulus 1.0, https://m.signalvnoise.com/stimulus-1-0--a-modest-javascript...

Re: Stimulus.js 2.0

#27
post #3

Stimulus has a very small surface area, but I find it really enjoyable to use when combined with Turbolinks. My only complaint/comment is that some of the HTML that I need to generate ends up being littered with so many data attributes, especially when combining multiple Stimulus controllers/behaviors. Has anybody found a clean way around that in Rails templates?

I share some of the same issues, I have found that ERB templates work better than HAML for lots of data attributes.

Basecamp seems to use liberal newlines / spacing when creating html tags (like one line per attribute) so that might help.

Server-side "component partials" still don't have a great story, but view_component is one emerging option.

Re: Stimulus.js 2.0

#28
post #3

Stimulus has a very small surface area, but I find it really enjoyable to use when combined with Turbolinks. My only complaint/comment is that some of the HTML that I need to generate ends up being littered with so many data attributes, especially when combining multiple Stimulus controllers/behaviors. Has anybody found a clean way around that in Rails templates?

Same advice as when using Tailwind CSS, or anything of this sort: refactor your application-specific front-end parts at the point of generation, into purposefully named units. For Rails, that means shifting your boilerplate into helpers, partials, and partial layouts. If you're ready for a sharper leading edge, look at ViewComponent.

Once the boundaries of your server-side parts for something are congruent to the client-side parts, you have reached the nirvana state of wondering, "can I extract & package these into a library and share it?".

This is general advice for all development but particularly and specifically true for Rails devs.

Re: Stimulus.js 2.0

#29

A modest JavaScript framework for the HTML you already have Are they implying one shouldn't use it if you don't have any HTML already?

The idea is you render the html as is. The data attributes take care of the interactive parts, with the js scripts loaded after the page renders (as opposed to render html within js that executes on load with, the reactjs render() call).

Re: Stimulus.js 2.0

#30

Alpine.js is worth a look as well [1]. I've been working with it as part of the newly christened "PETAL stack" [2] of Phoenix, Elixir, Tailwind, Alpine.js, and LiveView. [1] https://css-tricks.com/alpine-js-the-javascript-framework-th... [2] https://thinkingelixir.com/podcast-episodes/021-tailwind-css...

I was thinking that Alpine here was referring to Alpine Linux, which I found strange in the context because often these sorts of acronyms (LAMP, MEAN, etc etc) don’t mention specific distros and I also would not expect CSS-Tricks.com to write about Linux distros. But the answer of course was that it’s not Alpine Linux, it’s something called Alpine.js.
Post reply on HN