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.
> "PETAL stack" of Phoenix, Elixir, Tailwind, Alpine.js, and LiveView
Oh, finally a hipster stack after my own heart. My initial stack used Web Components instead of Alpine.js, but after one year trying to make it work (using lit-element) I'm battered, bruised and I declare Web Components a failed piece of technology [1].
Alpine is interesting, but not powerful enough for my use case, which is encapsulating common UI behaviours in reusable packages. Stimulus seem to be the missing ingredient in the mix for me. Any other suggestion for lightweight rich JS components that do not require one to buy into Vue, React or other "full-stack" JS libraries?
Also, I wholeheartedly recommend Unpoly as well, fits nicely in the PETAL stack.
1: shadow DOM isn't great on your OWN components, styling isn't fun paired with global CSS/tailwind, dealing with properties/attributes/observables/reactivity in general is an absolute pain in the buttocks, good luck wrapping an <input> in a web component.
I've also been playing with Alpine, but on the also-newly-christened "TALL stack" [1] of Tailwind, Alpine.js, Laravel, and LiveWire. It's also worth a look.
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.
I worked with Stimulus for about a month and found it to be frustrating:
1. There is not a lot of documentation
2. They don't provide any testing guidelines, the best I've found is hand-wavy test-with-a-browser stuff
3. Everything is essentially global
4. Functions are disconnected from their parameters, i.e. I can't tell which bits of data a function is using without digging through a bunch of code.
5. Putting state in your HTML is tricky if you also want to modify the DOM.
6. Their naming scheme is cumbersome, e.g. data-controller="using-a--sub-directory" and data-target="some--nested--target-has-a.function", that is, the fact that everything is location-in-your-code-file-structure based.
And a lot of other small things.
Ironically, using Stimulus convinced me to switch to Vue because I liked their value proposition of "Javascript sprinkles for your HTML", which Vue lets me do, but more intuitively.
Ditto. I think if you are an experienced web app dev, understand the pros and cons of something like Stimulus, and set out from the beginning of your project to make PRODUCT decisions within the constraints of something like Stimulus and being more SSR. Then it is a great tool.
Anything more complicated though, and you are better off with Vue, React, Etc
I have great hopes that Stimulus 2.0 and Ruby 3.0 will put Rails back in the spotlight as the sane alternative to SPA abuse. Ruby and Rails have some really talented people on their teams and there's something special about the Ruby language which makes it such a fertile environment for innovation. Only Clojure compares in this respect.
Rails is already the sane alternative. Any full stack framework is. DotNet, Laravel, Django, Rails...
If you think you need a JS framework to handle your UI, you've already lost, and you're doomed to reinventing wheels that these technologies have already perfected.
SPA abuse is the predictable and highly unimaginative result of framework overuse. Hoping a different framework will somehow be a solution is exceedingly optimistic.
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.
We adopted stimulusjs a couple of years ago for adding some basic interactivity on our pages and it was a decent tool, but we quickly grew out of it once we started adding more complex (form based) front-end behavior involving lots of state changes. We're currently trying to migrate a significant amount of stimulus code over to react.
Not knocking on stimulusjs, but just be wary that it does not grow well with increasing client side complexity. You'll end up writing a lot of javascript boilerplate / DOM manipulation code / custom state management components. From my experience, it's a nice lightweight tool for when you:
1. Just need to add some light interactivity (toggling visibility of components, any basic view filtering) that do not involve a lot of logic
2. Don't need j.s unit tests (stimulus has not been the most testable tool - we lean mostly on integration tests).
Unpoly https://unpoly.com is also worth a look if you are interested in these things. It combines Turbolinks and Stimulus functionality in a very usable way.
Yeah. This is happening with all libraries by basecamp: They release something, they don‘t work on it for months (no commits, many open pull requests) and people believe it‘s dead. Then one day (today) they out of the blue release a new version which nobody was expecting.
Wouldnt stimulus and turbolinks not work so great i would prefer using different libraries.
This is good news. I work for 6 months with StimulusJS 1 and I'm very happy to use it. I use it mainly in a rails app combined with Turbolinks.
My original thought was to go for an SPA with a rails API backend. I tried out both React & Vue extensively but got stuck in a while. Since implementing Rails and plain 'vanilla' JS it went better. But with StimulusJS 1+ it went simply great.
Allready upgraded to 2.0 and it feels even more structured with the new features, like values and improved targets.
What's the difference between Pjax and Turbolinks? Just a generic version of the same thing? Could Stimulus [Reflex] be hacked to work with Django or does it have strong ties to Rails?
Stimulus doesn't care about your backend, it's pure client side JS. You just load it (Stimulus itself and your controllers) and it looks for Stimulus stuff inside your HTML.
StimulusReflex is a Rails thing that's much more involved than Stimulus.
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.
Or a convincing Stimulus vs. Vue post would be helpful too, since Vue is so simple to sprinkle in as well, and doesn't pollute the html with data attributes as much as Stimulus.
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.
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).
benzible|5 years ago
[1] https://css-tricks.com/alpine-js-the-javascript-framework-th...
[2] https://thinkingelixir.com/podcast-episodes/021-tailwind-css...
1_player|5 years ago
Oh, finally a hipster stack after my own heart. My initial stack used Web Components instead of Alpine.js, but after one year trying to make it work (using lit-element) I'm battered, bruised and I declare Web Components a failed piece of technology [1].
Alpine is interesting, but not powerful enough for my use case, which is encapsulating common UI behaviours in reusable packages. Stimulus seem to be the missing ingredient in the mix for me. Any other suggestion for lightweight rich JS components that do not require one to buy into Vue, React or other "full-stack" JS libraries?
Also, I wholeheartedly recommend Unpoly as well, fits nicely in the PETAL stack.
1: shadow DOM isn't great on your OWN components, styling isn't fun paired with global CSS/tailwind, dealing with properties/attributes/observables/reactivity in general is an absolute pain in the buttocks, good luck wrapping an <input> in a web component.
gjsman-1000|5 years ago
[1] https://tallstack.dev
fouc|5 years ago
pspeter3|5 years ago
codetrotter|5 years ago
phaedryx|5 years ago
1. There is not a lot of documentation
2. They don't provide any testing guidelines, the best I've found is hand-wavy test-with-a-browser stuff
3. Everything is essentially global
4. Functions are disconnected from their parameters, i.e. I can't tell which bits of data a function is using without digging through a bunch of code.
5. Putting state in your HTML is tricky if you also want to modify the DOM.
6. Their naming scheme is cumbersome, e.g. data-controller="using-a--sub-directory" and data-target="some--nested--target-has-a.function", that is, the fact that everything is location-in-your-code-file-structure based.
And a lot of other small things.
Ironically, using Stimulus convinced me to switch to Vue because I liked their value proposition of "Javascript sprinkles for your HTML", which Vue lets me do, but more intuitively.
hfourm|5 years ago
Anything more complicated though, and you are better off with Vue, React, Etc
andrei_says_|5 years ago
RedShift1|5 years ago
cutler|5 years ago
ljm|5 years ago
If you think you need a JS framework to handle your UI, you've already lost, and you're doomed to reinventing wheels that these technologies have already perfected.
davidjnelson|5 years ago
jack_riminton|5 years ago
Apparently Stimulus 2.0 is part of that directional change
Tweets: https://twitter.com/dhh/status/1334916143010680833?s=20
austincheney|5 years ago
mike1o1|5 years ago
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?
inopinatus|5 years ago
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.
jyunderwood|5 years ago
swanson|5 years ago
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.
catwind7|5 years ago
Not knocking on stimulusjs, but just be wary that it does not grow well with increasing client side complexity. You'll end up writing a lot of javascript boilerplate / DOM manipulation code / custom state management components. From my experience, it's a nice lightweight tool for when you:
1. Just need to add some light interactivity (toggling visibility of components, any basic view filtering) that do not involve a lot of logic 2. Don't need j.s unit tests (stimulus has not been the most testable tool - we lean mostly on integration tests).
andrei_says_|5 years ago
justinko|5 years ago
gerry_shaw|5 years ago
sph|5 years ago
* easy AJAX loading like turbolinks (<a href="?page=2" up-target=".content">)
* easy AJAX modal (<a href="/users/new" up-modal="form">)
* submit a form whenever any input changes (<input type="search" up-autosubmit up-delay="500">)
* respects the way HTML is intended to be used, so the page still works even when JS is disabled
midrus|5 years ago
prox|5 years ago
dang|5 years ago
2018 https://news.ycombinator.com/item?id=16052105
2018 https://news.ycombinator.com/item?id=16443860
2018 https://news.ycombinator.com/item?id=17834514
vmsp|5 years ago
https://github.github.io/catalyst/
stepbeek|5 years ago
It’s encoding conventions that we’ve fallen into using it for the last year. The callbacks in value changes are going to make my life much easier.
lostfocus|5 years ago
throw_m239339|5 years ago
correlator|5 years ago
tpetry|5 years ago
obiefernandez|5 years ago
tpetry|5 years ago
Wouldnt stimulus and turbolinks not work so great i would prefer using different libraries.
osxman|5 years ago
My original thought was to go for an SPA with a rails API backend. I tried out both React & Vue extensively but got stuck in a while. Since implementing Rails and plain 'vanilla' JS it went better. But with StimulusJS 1+ it went simply great.
Allready upgraded to 2.0 and it feels even more structured with the new features, like values and improved targets.
cutler|5 years ago
danjac|5 years ago
https://github.com/danjac/localhub
https://github.com/danjac/kando
https://github.com/danjac/django-saas-starter
Toutouxc|5 years ago
StimulusReflex is a Rails thing that's much more involved than Stimulus.
raihansaputra|5 years ago
shay_ker|5 years ago
swanson|5 years ago
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...
newsbinator|5 years ago
Lio|5 years ago
1. https://docs.stimulusreflex.com/
Scarbutt|5 years ago
yborg|5 years ago
dsego|5 years ago
jdhornby|5 years ago
ksec|5 years ago
noneeeed|5 years ago
ssaunier_|5 years ago
Drakula2k|5 years ago
Scarbutt|5 years ago
Are they implying one shouldn't use it if you don't have any HTML already?
ansonhoyt|5 years ago
To understand their philosophy, see DHH's blog post announcing Stimulus 1.0, https://m.signalvnoise.com/stimulus-1-0--a-modest-javascript...
hirako2000|5 years ago