> Stimulus also differs on the question of state. Most frameworks have ways of maintaining state within JavaScript objects, and then render HTML based on that state. Stimulus is the exact opposite. State is stored in the HTML, so that controllers can be discarded between page changes, but still reinitialize as they were when the cached HTML appears again. It really is a remarkably different paradigm. One that I’m sure many veteran JavaScript developers who’ve been used to work with contemporary frameworks will scoff at. And hey, scoff away. If you’re happy with the complexity and effort it takes to maintain an application within the maelstrom of, say, React + Redux, then Turbolinks + Stimulus will not appeal to you.
The complexity of React + Redux is completely orthogonal to having a virtual DOM. Ractive, vue, and the like are similarly easy as Stimulus.
Making state management easier is a matter of having simpler APIs, not moving state into HTML.
Quick Ractive version (at work so just ad-libbing):
new Ractive({
el: '.greeter-ui',
template: `
<div>
<input value="{{ name }}>
<button class="greet">Greet</button>
</div>
`,
data: {
name: 'Alex'
},
oncomplete: function(){
var Greeter = this;
var greetButton = document.querySelector('button.greet')
document.addEventListener(greetButton, 'click', function(event){
var name = Greeter.get('name')
console.log(name)
event.preventDefault();
})
}
})
> "You can read that and have a pretty good idea of what’s going on. Even without knowing anything about Stimulus or looking at the controller code itself. It’s almost like pseudocode. That’s very different from reading a slice of HTML that has an external JavaScript file apply event handlers to it. It also maintains the separation of concerns that has been lost in many contemporary JavaScript frameworks." [source](https://github.com/stimulusjs/stimulus/blob/master/ORIGIN.md)
This might be a subjective matter of taste, but I find the React solution much uglier, harder to read, and less intuitive despite the fact that I've been writing React for a while now, and have never written Stimulus.
Here's my guess on why: React syntax has to be able to simultaneously account for JS syntax, HTML syntax, and its own API - all within one syntax that can't be optimized for any one of those use cases. Stimulus allows (forces?) you to leverage more focused HTML syntax where applicable, and javascript syntax where applicable while also letting you leverage your preferred flavors as you see fit (say HAML and CoffeeScript).
I think what StimulusJS is supposed to bring to the table is that it watches the DOM for you, so you don't have to manage the integration or setup of the interactivity/app framework, providing a very easy way to integrate StimulusJS with your current Turbolinks setup.
That being said, I do have to worry about memory leaks.
It watches the DOM for you, since that's where state is, but every other thing watches the JS for you, because that's where the state is. I don't see the advantage.
If you watch the DOM then it might be more compatible with things like jQuery plugins, which operate directly on the DOM instead of your JS object in memory somewhere.
It bothers me a bit that it feels intentionally dismissive of (or oblivious to) the current state-of-the-art of JavaScript frameworks.
None of the criticism mentioned feel like an honest reflection of my last two years working with React (4 years total). Universal rendering is mainstream, there are plenty of options for vastly simplifying initial setup and overall complexity (eg Next.js). From what I understand, similar is true of Vue and Ember.
I can genuinely see the value in tech like Stimulus and Pjax as a way of augmenting an existing traditionally-coded app without needing a total rewrite. But this document seems to be arguing for its place in the world of 2-3 years ago, rather than the present-day.
I don’t follow, most of the things it complains about aren’t current problems, they’re historical. The cutting-edgeness is irrelevant (and I suspect we mean different things by it anyway). The problem is that the document is arguing against an inaccurate caricature of other technologies
> Universal rendering is mainstream, there are plenty of options for vastly simplifying initial setup and overall complexity
> arguing for its place in the world of 2-3 years ago, rather than the present-day.
Basecamp pays particular focus to productivity, developer happiness, and staying small. It is through these tenants that they use tools and develop new ones. They are dismissive of frontend JS frameworks because they run counter to their tenants. They embrace the fact that with the web, there are a multitude of ways to deliver a webapp - there is no linear progress but simply an increase in options to suit needs.
I pick my stack based on the same principles. The reason why I was so excited about React, GraphQL etc was that I felt it was finally realistic for me to be able to work solo on my side projects.
Thanks for that. I just looked up the referenced TurboLink package. I'm not very opinionated on whether it makes more sense to render on the server or client. I can go either way depending on context.
But, if I were to do another project where server side rendering made more sense, I would definitely do a proof of concept with Stimulus + TurboLinks.
Right now, my preferred light weight solution is JQuery+Handlebars+WebAPI (c#)
The complexity of React + Redux is completely orthogonal to having a virtual DOM. Ractive, vue, and the like are similarly easy as Stimulus.
Making state management easier is a matter of having simpler APIs, not moving state into HTML.
Quick Ractive version (at work so just ad-libbing):