Stimulus.js 2.0(discourse.stimulusjs.org)
discourse.stimulusjs.org
Stimulus.js 2.0
https://discourse.stimulusjs.org/t/announcing-stimulus-2-0/1482
139 comments
> "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.
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.
Have you checked out Surface [1]? In a recent interview [2] Chris McCord hinted at merging at least some of Surface into LiveView.
[1] http://surface-demo.msaraiva.io
[2] https://thinkingelixir.com/podcast-episodes/024-liveview-upl...
[1] http://surface-demo.msaraiva.io
[2] https://thinkingelixir.com/podcast-episodes/024-liveview-upl...
I love where surface is going but its not ready for general use yet. last I checked, it was pinned to an older fork of liveview.
Look again - the current Surface release is pinned to the current LiveView release, 0.15.
https://github.com/msaraiva/surface/blob/master/CHANGELOG.md
https://github.com/msaraiva/surface/blob/master/CHANGELOG.md
thanks for the heads up, gonna try integrating this today and see what happens
> Any other suggestion for lightweight rich JS components that do not require one to buy into Vue, React or other "full-stack" JS libraries?
Depending on your needs, you can sort of use Alpine + server-side templating to achieve this. While Alpine itself has no concept of components, you can define a template fragment that consists solely of the “component” for basically the same effect. Because the x-data directive is freshly evaluated each time it appears, you can include a fragment multiple times and get isolated “instances”.
YMMV though, I eventually found that because templating is much more simplistic than a real tree of components as you would get with Vue or React, things started getting hard to follow, especially when my “components” were nested, or involved approximating slots.
Ultimately I converted to Inertia.js, which is a very small glue library that lets me write the whole front end in Vue (or React, or Svelte) while keeping a more traditional Laravel (or Rails) backend.
Depending on your needs, you can sort of use Alpine + server-side templating to achieve this. While Alpine itself has no concept of components, you can define a template fragment that consists solely of the “component” for basically the same effect. Because the x-data directive is freshly evaluated each time it appears, you can include a fragment multiple times and get isolated “instances”.
YMMV though, I eventually found that because templating is much more simplistic than a real tree of components as you would get with Vue or React, things started getting hard to follow, especially when my “components” were nested, or involved approximating slots.
Ultimately I converted to Inertia.js, which is a very small glue library that lets me write the whole front end in Vue (or React, or Svelte) while keeping a more traditional Laravel (or Rails) backend.
Shadow dom is optional for web components, web components are still useful without it, so I hardly see how that could be a reason for "failed piece of technology".
Also, did you try with pure JS ? no lit ? I just removed StencilJS from my component to go pure-JS and it turns out I really prefer it that way, maybe it would suit you too to do WC without any additional JS lib ?
Also, did you try with pure JS ? no lit ? I just removed StencilJS from my component to go pure-JS and it turns out I really prefer it that way, maybe it would suit you too to do WC without any additional JS lib ?
lit-element is a very light wrapper on top of the native API. The problem isn't lit-element, the problem is the native API is not that good, not ergonomic, still incomplete and so far removed from the modern way of building reactive websites, i.e. view = render(state)
You need some abstraction on top of the native API, working directly with it is even more painful. The fact I'm using lit-element is because many WC libraries force shadom DOM upon you, and only some make it optional (Stencil is one of those few, but the TS requirement is a no-go for my use case)
You need some abstraction on top of the native API, working directly with it is even more painful. The fact I'm using lit-element is because many WC libraries force shadom DOM upon you, and only some make it optional (Stencil is one of those few, but the TS requirement is a no-go for my use case)
> Shadow dom is optional for web components
Not the OP, but slots are part of the shadow DOM spec, so if you don’t want isolated styles, you have to forego slots.
I tend to build my app scaffolding with wrapper components that provide layout and/or functionality to their child components via slots, so as much as I like the idea of WebComponents they’re a complete non-starter for me.
Not the OP, but slots are part of the shadow DOM spec, so if you don’t want isolated styles, you have to forego slots.
I tend to build my app scaffolding with wrapper components that provide layout and/or functionality to their child components via slots, so as much as I like the idea of WebComponents they’re a complete non-starter for me.
[deleted]
In the above stack LiveView doesn’t play that well with web components that render their own children, as it will remove those children when it rerenders. So you do kind of need shadow DOM.
Actually LV can play nice with them if you add the phx-ignore attribute on the component itself
Consider redom, mithril, snabbdom, riot.js, lighterhtml or even svelte.
React is great though, why not just use that?
React is great if all your frontend is React. Using it to create reusable components to sprinkle in your static HTML is overkill, and anyway it does not work with LiveView and LiveView is pretty cool.
IMO React has a good data model and solid foundation, but the whole ecosystem it's relying upon is bad. I'm not a fan.
IMO React has a good data model and solid foundation, but the whole ecosystem it's relying upon is bad. I'm not a fan.
True, that’s not its use case.
because then you need an api
React supports server side rendering.
Sure, but where is your data and business logic going to live? If the answer is "just write it in JS" then it's no longer a question of "just use React" but "let's replace our entire stack with Javascript".
Ya it really depends. I like redis and Postgres generally speaking for data, and Ruby on Rails generally for business logic. And you can certainly do universal rendering with that easily with react_on_rails. If you do end up needing more perf, maybe go would be interesting.
Yes but we're still going a long way from "just use React". One benefit of the "JS sprinkles" approach of Turbolinks+Stimulus is that you have a far simpler and more productive stack: Rails (or other framework) renders templates with some minimal JS on the frontend, as opposed to the inherent complexity of API + SSR + SPA. There are occasions when React is a good choice of course, but let's not underestimate the costs of the SPA architecture.
hey if stimulus and turbolinks are your jam then rock it!
I would at least give this a look though, it's super easy to use: https://github.com/shakacode/react_on_rails
I would at least give this a look though, it's super easy to use: https://github.com/shakacode/react_on_rails
Why would the entire stack be JS? Even in server side React, it can still fetch from APIs, so presumably you have a backend to fetch from, in whatever language and database you want.
So your system have two backends, the React backend and the api server? That does not sounds like a good investment.
Works fine, the NodeJS server simply builds the React page, nothing more. The API does all the heavy lifting of course.
yup, and if you want to really optimize it you could use functions as a service like lambda as your react rendering layer, which forwards to heroku or fargate or beanstalk or vanilla ec2 or whatever for your backend.
and if cloudflare workers ever support metered usage you could use that too for the react layer.
and if you want hyper performance you could use lambda@edge and intelligently route to your backend running on fly.io to minimize the distance. the somewhat unsolved problem there though is multi region master master replicated databases which are cost effective.
to my knowledge this is the current state of the art for that https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide...
problem is you have to pay for each region so it's not really cost effective.
and if cloudflare workers ever support metered usage you could use that too for the react layer.
and if you want hyper performance you could use lambda@edge and intelligently route to your backend running on fly.io to minimize the distance. the somewhat unsolved problem there though is multi region master master replicated databases which are cost effective.
to my knowledge this is the current state of the art for that https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide...
problem is you have to pay for each region so it's not really cost effective.
I thought you were making joke about complexity when I read the first line, but then in the end it's not a joke. Why don't you have 1 single backend peacefully. JS sprinkles for what it needs to be interactive. (I'm tired of "complex form " argument, jQuery turned out ok back then, so does Stimulus or whatever works with server rendered html (e.g. vue))
This sounds like madness. Not cost effective to deploy, nor cost effective at all to implement in the first place. It's literally setting money on fire.
What's the equivalent of Poe's law, but for software development?
What's the equivalent of Poe's law, but for software development?
That seems overly expensive compared to just keeping a build server
and then you need a nodejs server and sacrifices of kittens to webpack gods. Everything that libs like Stimulus aim to avoid.
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.
[1] https://tallstack.dev
[1] https://tallstack.dev
PETAL is a good name! I was calling it TAPE (Tailwind, Alpine.js, Phoenix, and Elixir) http://tapestack.party
Do you use Alpine with Turbolinks?
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.
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
Anything more complicated though, and you are better off with Vue, React, Etc
I am an experienced web dev and went into Stimulus excited to have something that seemed straightforward, but was disappointed. Vue has the flexibility to do SSR HTML with a bit of javascript for behavior way that works well for me.
Just being able to put
Just being able to put
<button @click.prevent="save(<%= id %>)">Save</button>
<button data-action="click->some--long--path-to#save" data-id="<%= id %>">Save</button>
save(event) {
event.preventDefault()
I've personally hit the point where I feel like React is my go to for anything - especially with Gatsby.
* If I'm keeping it simple, it's barely different than pure HTML. * Free templating * If I need Javascript (which I likely will), it's extremely easy to add anything I need.
* If I'm keeping it simple, it's barely different than pure HTML. * Free templating * If I need Javascript (which I likely will), it's extremely easy to add anything I need.
But you get blank page until js kicks in?
I haven't had a problem. In my experience, I can actually get content up more quickly than a traditional CMS-type system.
Gatsby does some intelligent bundling so each page is pretty much self-bundled.
* Root HTML file
* Core, common JS (cached after first load)
* Page specific JS (also cached on subsequent loads)
For me, this is 257 kB uncompressed - with most of that being the Root HTML file (I realized I don't have minification or Gzip on - which takes that down substantially). Not a tiny payload, but the content is all static so the response comes back extremely quickly.
Even at slow 3G speeds, I barely get a flash. The actual page loads just about as quickly as HN.
With modern internet, the load time is nearly instant AND is literally instant on subsequent page loads (since most of the payload is locally cached).
Gatsby does some intelligent bundling so each page is pretty much self-bundled.
* Root HTML file
* Core, common JS (cached after first load)
* Page specific JS (also cached on subsequent loads)
For me, this is 257 kB uncompressed - with most of that being the Root HTML file (I realized I don't have minification or Gzip on - which takes that down substantially). Not a tiny payload, but the content is all static so the response comes back extremely quickly.
Even at slow 3G speeds, I barely get a flash. The actual page loads just about as quickly as HN.
With modern internet, the load time is nearly instant AND is literally instant on subsequent page loads (since most of the payload is locally cached).
Not if you use Gatsby or NextJS and get server side rendering out of the box
Why backend of web development is narrow down to nodejs server? How about people who use Rust/Python/Ruby/Elixir/PHP?
It's not. If you're building a backend heavy use-case, there are plenty of good options.
Gatsby is geared towards building web pages, not web applications. If you're implementing Gatsby, you're building essentially HTML pages, possibly with some JS functionality.
Gatsby is geared towards building web pages, not web applications. If you're implementing Gatsby, you're building essentially HTML pages, possibly with some JS functionality.
It's interesting to me to explore this type of application that is interactive web page, but not web applications
Usually, the more interaction, the more likely it's application. The more it's just a page, the more it should be just HTML.
Usually, the more interaction, the more likely it's application. The more it's just a page, the more it should be just HTML.
I like React a lot and I sometimes use it for my own projects (e.g. I just finished https://techadequiz.com/)
However, I don't think React does "add some Javascript behavior to my Rails views (or backend framework equivalent)" very well (which is what I think Stimulus is trying to do). I mean you have solid support for React in the Rails ecosystem, but you turn your HTML-rendering responsibilities over to React Javascript functions.
However, I don't think React does "add some Javascript behavior to my Rails views (or backend framework equivalent)" very well (which is what I think Stimulus is trying to do). I mean you have solid support for React in the Rails ecosystem, but you turn your HTML-rendering responsibilities over to React Javascript functions.
Doesn’t vuejs require you to keep your state in a store object (data: {}) and render html via js though?
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.
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.
Thank you for saying this. I thought it but didn’t write it as I don’t want to offend.
The amount of extra work and complexity that a separate FE introduces requires serious benefits on the other side of the equation.
The amount of extra work and complexity that a separate FE introduces requires serious benefits on the other side of the equation.
Isn't Stimilus a JS framework?
StimulusJS is one step up from JQuery and formalizes a lot of jQuery patterns that I'd come across - data-target, data-event attributes, etc.
Not really. More like super simple and light helpers for dom manipulation - lets you add interactivity with minimal trouble.
[deleted]
Rails is dope. And it works really well with universal react rendering if you need that with react_on_rails.
Came to say the same. I've found it to be a really great productive combination. I can sprinkle in React components where the UI is especially rich and use Rails for everything else.
I've got even greater hopes for the NEW MAGIC that @dhh has been hinting about
Apparently Stimulus 2.0 is part of that directional change
Tweets: https://twitter.com/dhh/status/1334916143010680833?s=20
Apparently Stimulus 2.0 is part of that directional change
Tweets: https://twitter.com/dhh/status/1334916143010680833?s=20
SPA abuse is the predictable and highly unimaginative result of framework overuse. Hoping a different framework will somehow be a solution is exceedingly optimistic.
[deleted]
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?
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.
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.
I've found it works well with [ViewComponent](https://github.com/github/view_component) if you're in to that.
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.
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.
As another option, HAML lets you extract the attributes into a ruby helper method:
https://haml.info/docs/yardoc/file.REFERENCE.html#attribute-...
https://haml.info/docs/yardoc/file.REFERENCE.html#attribute-...
Same. I’ve been a happy user of Haml for about ten years, but I think that Tailwind and Stimulus will permanently force me back to ERB :(
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).
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).
What UI behaviors necessitated you to move beyond stimulus? Could you provide an example?
Sure!
One typical example is a component that collects (and displays) education history provided by the user. I'll list out just a few key UI behavior:
* A "read" view which represents a list of containers with titles that show each instance of a users answer (for example, if you provided 5 sets of answers, such as 5 universities you attended, we need to show those 5 in some sort of preview form on the page)
* A button that when clicked opens up a modal which contains multiple "steps" - each step is a small set of form inputs that range from simple ones like date to more complex ones involving search / autocomplete or file uploading.
* A button inside the modal that lets you navigate through the various steps / groups of form inputs.
* A "save" button inside the modal that persists your answers. This closes the modal and shows your set of answers as an instance in the list view (see the first bullet).
* In-line validation errors as the user is filling out each step of the modal
* Messages to notify the user that a modal needs to be opened and completed (Like if the user closed the modal before filling everything out, we want to let them know it's not fully completed).
Where some of the biggest complexity crop up:
* Form input data handling and general state management. As I mentioned, we can have upwards of maybe 20 controls in this component. At minimum, we need to write code to listen to input changes and make sure this new information is kept in sync with both internal component state and other parts of the UI. If you gave us a valid answer, we need to make sure to update the UI to show a checkmark (in the simple case). We also have controls that show or hide based on your answers to other form controls, so we'll need to handle inputs by potentially hiding or showing other inputs.
* Ok, so what if we need to write some UI updating code? Well, updating any part of the UI requires manual DOM manipulation. At minimum, this can be something simple like toggling visibility of an element by adding or removing a class. At worst, this involves appending html template strings (like if we need to show a list of errors on top of the modal) when the user attempts to save bad answers.
* Cross-component communication is difficult. Want to add a subcomponent? And it needs to communicate with the parent? For example, each step in our view is sort of a "sub form" and it needs to talk to the parent "modal" to keep global state - you'll need to roll some basic event handling code between the two.
* Testability. All these DOM changes - how do we test that our component is behaving? At the time we adopted stimulus, there wasn't a standard way of testing our stimulus controller so we've mostly leaned on (expensive) UI integration tests.
Some of this complexity is sort of inherent to forms - forms are complex UI components. There are hosts of libraries in other frameworks for dealing with form inputs alone (in order to cut down on the boilerplate you have to write). For example, formik in react helps cut down on a ton of boilerplate you have to write in order to wire the form control DOM state to react state.
Some of this complexity is also our own doing - we keep A LOT of state in the DOM. If a user blanks out an answer, we need to update the DOM with an additional form control whose value will get passed back to the backend to persist the change in the DB. Moving over to ReactJS won't help us here - this will require changes to our backend vs frontend API's.
However, having to handle the bulk of those DOM changes yourself requires a lot of code, is pretty error prone, and quite hard overall to maintain (as anyone who has rolled apps using vanilla javascript can attest to). StimulusJS doesn't offer many facilities for changing your UI in a declarative way.
Finally, cross-component communication is very common and while there is a number of ways to pass data back and form between stimulus controllers, there isn't really a nice way to do it outside of passing events. This is fine for simple cases, but error prone for our use cases. In reactjs, invoking callbacks that change parent state feels much more straightforward and has been easier to test.
Hope that helps
One typical example is a component that collects (and displays) education history provided by the user. I'll list out just a few key UI behavior:
* A "read" view which represents a list of containers with titles that show each instance of a users answer (for example, if you provided 5 sets of answers, such as 5 universities you attended, we need to show those 5 in some sort of preview form on the page)
* A button that when clicked opens up a modal which contains multiple "steps" - each step is a small set of form inputs that range from simple ones like date to more complex ones involving search / autocomplete or file uploading.
* A button inside the modal that lets you navigate through the various steps / groups of form inputs.
* A "save" button inside the modal that persists your answers. This closes the modal and shows your set of answers as an instance in the list view (see the first bullet).
* In-line validation errors as the user is filling out each step of the modal
* Messages to notify the user that a modal needs to be opened and completed (Like if the user closed the modal before filling everything out, we want to let them know it's not fully completed).
Where some of the biggest complexity crop up:
* Form input data handling and general state management. As I mentioned, we can have upwards of maybe 20 controls in this component. At minimum, we need to write code to listen to input changes and make sure this new information is kept in sync with both internal component state and other parts of the UI. If you gave us a valid answer, we need to make sure to update the UI to show a checkmark (in the simple case). We also have controls that show or hide based on your answers to other form controls, so we'll need to handle inputs by potentially hiding or showing other inputs.
* Ok, so what if we need to write some UI updating code? Well, updating any part of the UI requires manual DOM manipulation. At minimum, this can be something simple like toggling visibility of an element by adding or removing a class. At worst, this involves appending html template strings (like if we need to show a list of errors on top of the modal) when the user attempts to save bad answers.
* Cross-component communication is difficult. Want to add a subcomponent? And it needs to communicate with the parent? For example, each step in our view is sort of a "sub form" and it needs to talk to the parent "modal" to keep global state - you'll need to roll some basic event handling code between the two.
* Testability. All these DOM changes - how do we test that our component is behaving? At the time we adopted stimulus, there wasn't a standard way of testing our stimulus controller so we've mostly leaned on (expensive) UI integration tests.
Some of this complexity is sort of inherent to forms - forms are complex UI components. There are hosts of libraries in other frameworks for dealing with form inputs alone (in order to cut down on the boilerplate you have to write). For example, formik in react helps cut down on a ton of boilerplate you have to write in order to wire the form control DOM state to react state.
Some of this complexity is also our own doing - we keep A LOT of state in the DOM. If a user blanks out an answer, we need to update the DOM with an additional form control whose value will get passed back to the backend to persist the change in the DB. Moving over to ReactJS won't help us here - this will require changes to our backend vs frontend API's.
However, having to handle the bulk of those DOM changes yourself requires a lot of code, is pretty error prone, and quite hard overall to maintain (as anyone who has rolled apps using vanilla javascript can attest to). StimulusJS doesn't offer many facilities for changing your UI in a declarative way.
Finally, cross-component communication is very common and while there is a number of ways to pass data back and form between stimulus controllers, there isn't really a nice way to do it outside of passing events. This is fine for simple cases, but error prone for our use cases. In reactjs, invoking callbacks that change parent state feels much more straightforward and has been easier to test.
Hope that helps
Do you think Github.com UI is complex? They are using a very similar approach to Stimulusjs: https://github.github.io/catalyst/
And it's working great?
And it's working great?
I don't know enough about which parts of the site you're referring to to say for sure, but stimulus / stimulus-like approaches are perfectly fine for most display-only views even if they're fairly complex.
There are pages in our app where stimulus works great and the UI is fairly complex from a standpoint of the number of strictly user facing behavior (click this, show X, Y, and Z).
The complexity involved in handling form UI is just not very suitable for stimulus from my experience. That said, you can still do a lot in terms of following good programming practices to create something that looks and works great and is reasonably maintainable.
It ultimately comes down to your (and your teams) tolerance and business needs - there's no hard reason we need to stop using stimulus, we've just decided that there are parts of our app where we could make leaps in developer productivity by using something else.
There are pages in our app where stimulus works great and the UI is fairly complex from a standpoint of the number of strictly user facing behavior (click this, show X, Y, and Z).
The complexity involved in handling form UI is just not very suitable for stimulus from my experience. That said, you can still do a lot in terms of following good programming practices to create something that looks and works great and is reasonably maintainable.
It ultimately comes down to your (and your teams) tolerance and business needs - there's no hard reason we need to stop using stimulus, we've just decided that there are parts of our app where we could make leaps in developer productivity by using something else.
I built complex form before on financial platform where it contains complex investment details, different entities for different kind of offering .. with vanilla javascript. But that may sound grumpy old man in argument. Stimulus' weak point may be where it requires many DOM mutation per action, that's probably better use declarative way to re-render the whole thing in different way based on data.
Not at all - I still favor vanillajs if only to avoid the bloat of the whole modern js toolchain (webpack...babel...extra compile times)
There's also a big difference for us within the form world between forms with ephemeral state and forms that need to persist state through many interactions and sessions. The former is perfectly fine for us to handle with vanilla js, the latter just becomes easier for developers with a declarative model.
There's also a big difference for us within the form world between forms with ephemeral state and forms that need to persist state through many interactions and sessions. The former is perfectly fine for us to handle with vanilla js, the latter just becomes easier for developers with a declarative model.
Thank you for the detailed answer. I can definitely see you’ve crossed the line of adding subtle interactivity to the dom :)
The behaviors you describe are intricate and contain interconnected components which are probably managed by something like vuex (or the react equivalent)
The behaviors you describe are intricate and contain interconnected components which are probably managed by something like vuex (or the react equivalent)
Yeah, I also want to emphasize (again) that none of this is a criticism of stimulus - the key words / phrases they used two years ago and continue to use are things like "modest" and "augmenting html". Our needs were very different then. I'm not complaining that my hand saw isn't doing the same amount of work as a chain saw.
Awesome answer. I work a lot on business systems with complex forms and agree with everything you say.
We are still feeling our way for a solution as we don't want to move to a SPA (swapping one set of costs for another) but have outgrown our current SSR + hand-rolled JS + jQuery + Bootstrap JS mess.
We are still feeling our way for a solution as we don't want to move to a SPA (swapping one set of costs for another) but have outgrown our current SSR + hand-rolled JS + jQuery + Bootstrap JS mess.
I still have reservations about moving too heavily towards an SPA - we still mostly have server-side rendered pages that render with react components so we don't have to deal with things like client side routing. It's also still important for us we render most of the page server-side for performance reasons, but I'm not too informed about the specific trade-offs there in load times if we did push more rendering to the client.
I feel like there's some opportunity in the space to create a truly re-usable form library that can hook into your backend and be themed / customized to suite the look and feel of your app. There's some companies already in that space though, so I might take some time to check out some existing solutions and see if there's some kind of needs gap. What's challenging about this problem though (as I'm sure you're also aware) is that there are a ton of variability in requirements when it comes to forms - it's something I wish were more standardized but at times it feels like one of those bikeshedding topics where everyone has an opinion on how inputs show be displayed, how errors are shown, etc.
I feel like there's some opportunity in the space to create a truly re-usable form library that can hook into your backend and be themed / customized to suite the look and feel of your app. There's some companies already in that space though, so I might take some time to check out some existing solutions and see if there's some kind of needs gap. What's challenging about this problem though (as I'm sure you're also aware) is that there are a ton of variability in requirements when it comes to forms - it's something I wish were more standardized but at times it feels like one of those bikeshedding topics where everyone has an opinion on how inputs show be displayed, how errors are shown, etc.
> There's some companies already in that space though, so I might take some time to check out some existing solutions and see if there's some kind of needs gap.
Which companies are you thinking of? It's been too long since I looked beyond $dayjob and investigated what could be possible.
Which companies are you thinking of? It's been too long since I looked beyond $dayjob and investigated what could be possible.
https://formium.io/ is the company behind react's popular formik library
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.
My killer unpoly features:
* 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
* 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
I’m currently dealing with a modal issue within Svelte (pretty sure it’s due to createDispatch) and the Discord moves too fast to get help.
Gonna check this out in the AM.
EDIT: Couldn't sleep so checked it out now. Looking through the issues, there are a couple that are apparently "fixed in 1.0" but it doesn't look like 1.0 is coming anytime soon. Shame.
Gonna check this out in the AM.
EDIT: Couldn't sleep so checked it out now. Looking through the issues, there are a couple that are apparently "fixed in 1.0" but it doesn't look like 1.0 is coming anytime soon. Shame.
[deleted]
Happy unpoly user here too. I think it is way better than stimulus, turbolinks, htmlx, alpine, etc. Just doesn't have as good marketing as those.
> Just doesn't have as good marketing as those.
And maybe documentation too. Turbolinks has really good docs and conceptually it's pretty easy to get going (1 line of JS and learning a few event handlers). Alpine and StimulusJS have really good docs / guides and tons of practical examples if you Google for a specific problem you're trying to solve.
Unpoly's docs seem like it's mostly an HTML front-end to their API spec with very few examples. It's kind of difficult to figure out how to use most of what it does. There's also very little practical examples of using it if you Google around.
I've heard of it in the past but never got into it because of the above.
And maybe documentation too. Turbolinks has really good docs and conceptually it's pretty easy to get going (1 line of JS and learning a few event handlers). Alpine and StimulusJS have really good docs / guides and tons of practical examples if you Google for a specific problem you're trying to solve.
Unpoly's docs seem like it's mostly an HTML front-end to their API spec with very few examples. It's kind of difficult to figure out how to use most of what it does. There's also very little practical examples of using it if you Google around.
I've heard of it in the past but never got into it because of the above.
Unpoly is pretty good and complete. What I don't like is loading page specific JS/CSS via javascript. Turbolinks manages that for me and turbolink still executes inline JS.
Turbolinks falls short in providing a "framework" in how to use third party libraries - how to initialize them and how to tear them down. I finally glued together a mini-framework with hints from stack overflow, but Unpoly and their concept of compilers[1] is much more consistent.
[1] https://unpoly.com/up.compiler
Turbolinks falls short in providing a "framework" in how to use third party libraries - how to initialize them and how to tear them down. I finally glued together a mini-framework with hints from stack overflow, but Unpoly and their concept of compilers[1] is much more consistent.
[1] https://unpoly.com/up.compiler
Wow! Thanks, that looks quite useful. Especially that it can work with all kinds of back ends.
See also GitHub Catalyst
https://github.github.io/catalyst/
https://github.github.io/catalyst/
I love Stimulus and am super happy to see this update.
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.
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.
And just when Symfony announced their preferred way of doing frontend work is based on Stimulus, too. Great timing.
Given how over-engineered symfony is, that's not a good thing...
symfony4+ simplifies it's architecture
Stable, efficient and intuitive. Thank you to the stimulus team!
Now i am waiting for the next turbolinks release. Their hey.com service has some interesting turbolinks extensions: https://dev.to/borama/a-few-sneak-peeks-into-hey-com-technol... and following
Good timing. There was talk of a fork brewing...
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.
Wouldnt stimulus and turbolinks not work so great i would prefer using different libraries.
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/
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
I think the much touted "NEW MAGIC" will be the thing that does the automatic content refresh.
> I think the much touted "NEW MAGIC" will be the thing that does the automatic content refresh.
The StimulusJS handbook has an automatic content refresh example at https://stimulusjs.org/handbook/working-with-external-resour....
As for NEW MAGIC, DHH mentioned it will have a Rails server side aspect to it so I don't think we can compare these tools directly.
He did say other server side frameworks could implement similar behavior too but it would involve the framework having built-in support for websockets and job queues. This is based on a question I just asked him on Twitter at https://twitter.com/dhh/status/1334953167327547397.
So it sounds like NEW MAGIC will probably make it super easy to push / broadcast stuff from the server to the client, but to get everything working with a really nice API and it being seamless will require a substantial amount of work if you planned to re-invent it in another framework.
The StimulusJS handbook has an automatic content refresh example at https://stimulusjs.org/handbook/working-with-external-resour....
As for NEW MAGIC, DHH mentioned it will have a Rails server side aspect to it so I don't think we can compare these tools directly.
He did say other server side frameworks could implement similar behavior too but it would involve the framework having built-in support for websockets and job queues. This is based on a question I just asked him on Twitter at https://twitter.com/dhh/status/1334953167327547397.
So it sounds like NEW MAGIC will probably make it super easy to push / broadcast stuff from the server to the client, but to get everything working with a really nice API and it being seamless will require a substantial amount of work if you planned to re-invent it in another framework.
The new turbolinks they use on hey.com is using a concept named „portals“ so different parts of the web application can be refreshed independently. My linked inside hey.com articles are very interesting.
Yeah that's the interesting part. It sounds like maybe there will be some overlaps in Turbolinks 6 and NEW MAGIC when it comes to partial updates.
Maybe for basic partial page updates where you don't need to broadcast something to every connected client over websockets then Turbolinks 6 will be enough on it own. If that ends up being the case that's amazing because it'll be fully client side.
In any case the near future is looking to be the best its ever been for developing very nice feeling apps without going the SPA route with any back-end technology.
Maybe for basic partial page updates where you don't need to broadcast something to every connected client over websockets then Turbolinks 6 will be enough on it own. If that ends up being the case that's amazing because it'll be fully client side.
In any case the near future is looking to be the best its ever been for developing very nice feeling apps without going the SPA route with any back-end technology.
How does htmx fail?
Seriously!
I've been following them since the intercooler days and they've been great (functionally) although maybe a little drowned out by all the SPA chatter. Still a great library IMO.
I've been following them since the intercooler days and they've been great (functionally) although maybe a little drowned out by all the SPA chatter. Still a great library IMO.
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.
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?
It's easy to use with django, I use it with some side projects:
https://github.com/danjac/localhub
https://github.com/danjac/kando
https://github.com/danjac/django-saas-starter
https://github.com/danjac/localhub
https://github.com/danjac/kando
https://github.com/danjac/django-saas-starter
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.
StimulusReflex is a Rails thing that's much more involved than Stimulus.
Stimulus Reflex already have a Django counterpart that uses the Stimulus Relex js and conventions. The package is django-sockpuppet.
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...
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...
What you are describing seems similar to good old BackboneJS?
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.
One benefit is when combined with Turbolinks there is a need to bootstrap the Vue/React component. The Stimulus controllers respond to mutation observers and always work.
If a new HTML element is added to the DOM and has a controller, it just works and is now active. This might not be the case with React or Vue, as you'd have to then bootstrap the component.
This makes Stimulus a really good combo when used with Turbolinks or partial Javascript responses.
If a new HTML element is added to the DOM and has a controller, it just works and is now active. This might not be the case with React or Vue, as you'd have to then bootstrap the component.
This makes Stimulus a really good combo when used with Turbolinks or partial Javascript responses.
I switched from Stimulus to Vue and have had a much better experience so far. It is much easier for me to use and I still get the value of "sprinking"
Not sure about react-rails but using Stimulus as part of StimulusRelex[1] is super interesting to me.
1. https://docs.stimulusreflex.com/
1. https://docs.stimulusreflex.com/
Stimulus is paired with Turbolinks, which doesn't play well with almost anything in the JS ecosystem.
Stimulus has nothing to do with Turbolinks.
Is there a good comparison summary of the major JS frameworks available somewhere?
If anyone is interested in “the magic” DHH is talking about, this is a fantastic resource: https://dev.to/borama/a-few-sneak-peeks-into-hey-com-technol...
Is Stimulus 2.0 the NEW MAGIC DHH was referring to? I was expecting something much bigger.
No. I think that's the new turbolinks.
Nice to see that it keeps improving.
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?
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...
To understand their philosophy, see DHH's blog post announcing Stimulus 1.0, https://m.signalvnoise.com/stimulus-1-0--a-modest-javascript...
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).
[1] https://css-tricks.com/alpine-js-the-javascript-framework-th...
[2] https://thinkingelixir.com/podcast-episodes/021-tailwind-css...