top | item 16052105

Stimulus: A modest JavaScript framework for the HTML you already have

298 points| tmlee | 8 years ago |github.com | reply

108 comments

order
[+] sheraz|8 years ago|reply
I think this, along with its sibling Turbolinks [1], is filling a much needed gap with regards to complexity in these javascript frameworks. Myself, I've been playing with intercoolerjs [2] for a few weeks, and it is quite refreshing.

These are great libraries for small full-stack teams who do not want to get lost in the complexity of front-end stuff like react, webpack, etc.

[1] - https://github.com/turbolinks/turbolinks

[2] - http://intercoolerjs.org/

[+] JoshMnem|8 years ago|reply
Turbolinks are not good for usability.

They appear to make the pages painfully slow on slower connections.

They add a loading bar across the top which can have different meanings depending on the site and browser:

- some browsers add a bar across the top to indicate page loading progress (example: Firefox for Android)

- some websites add a bar across the top to indicate how far you've read in an article

- turbolinks adds yet another bar across the top to also indicate page loading progress

I'm sure that using turbolinks is fine for people with fast Internet connections and certain types of websites/browsers, but it's terrible for usability in some scenarios.

(`rails new app --skip-turbolinks`)

[+] aaron-lebo|8 years ago|reply
Frontend stuff doesn't have to be complex. The idea behind React is very simple and it's really something every front end dev should know. You need to understand the why of DOM diffing. It is not complicated. If a frontend dev doesn't want to learn that then they will be out of a job in a decade. It transfers, too. React, Vue, Elm, Reagent, etc, they are all doing this, because it is good, and none of them in isolation are complex. Mithril is actually smaller than Intercooler and is everything included, so there's no need to put together a stack if you don't feel like it.

The stack you are offering is great, and it's great in the right situation, but I just wanted to push back against the "complexity" argument because it happens a lot and it makes me afraid that it is pushing devs into more familiar but less capable stacks. Your React/Vue stack might be a little more setup, but it's also going to scale. The Turbolinks/Intercooler approaches seem to be managing state with the DOM, and as someone who has spent the last six months pulling the state out of the DOM from a jQuery app, it does not scale. But anyone who has used both approaches in a moderately sized app can tell you this, it's why stuff like React exist at all.

[+] triskweline|8 years ago|reply
If you enjoy working with intercooler.js but are looking for a bit more power, check out Unpoly [1].

[1]: https://unpoly.com

[+] jdc0589|8 years ago|reply
its not "cool" anymore, but I always thought knockout was pretty simple, worked well, and fulfilled a lot of this use-case.

I built a couple knockout based apps that worked phenomenally well across lots of platforms, and were pretty lightweight dependency wise. Organization and convention was paramount to keep consistent since it doesn't enforce a bunch of best practices like a larger framework would; but, looks like all of these sit in basically that same space.

[+] bruncun|8 years ago|reply
To anyone wondering why they should care about Stimulus, I offer this TLDR, straight from DHH himself:

"Above all, it’s a toolkit for small teams who want to compete on fidelity and reach with much larger teams using more laborious, mainstream approaches."

Give it a whirl, I'm sure you'll find it delightful. But if you're looking for the next Big Thing™, I'm afraid you might be sorely disappointed.

[+] jaredcwhite|8 years ago|reply
As a Rails dev, I find this very interesting. I've already jumped on the Vue bandwagon and have had a pretty good time using it. That being said, I recently started a new small-ish Rails project and loaded Vue in via 5.1's Webpack integration...and ended up just hacking together some jQuery stuff for minor front-end dynamism. It just was easier/faster for me to do that in this particular context.

However, I could definitely see myself using Stimulus instead because it's just so incredibly simple to "sprinkle" (DHH's word) some JS onto the page and get dynamism quickly. I look forward to putting Stimulus through its paces and see if it is a good option for projects where Vue is overkill.

[+] bphogan|8 years ago|reply
This has been my experience on the last two small things I built. I just reached for the jquery (or even just regular JS) because I didn't need that much.

Isn't it cool to have choices? I don't care if it's not cool to use jquery anymore. I shipped stuff and I'm not even sorry.

[+] crescentfresh|8 years ago|reply
> Vue is overkill

The number of projects where something as small and simple as Vue could be considered overkill has to be remarkably small, I feel. I've used Vue in single pages (i.e. a single page of a large application) inside a single div as needed. In my case attaching behavior inside a modal dialog (ie the modal was managed by some other framework). It is very small and lean as is.

[+] andrei_says_|8 years ago|reply
Speaking of rails and Vue, how do you manage authentication? Can you point me to an example of a Vue-powered page in a larger rails app consumes json data after authentication?
[+] scarface74|8 years ago|reply
For context, I'm in no way, shape, or form a modern front end maestro. I'm good with ES6, Jquery, Handlebars, and Bootstrap. I've done a little with the Angular 2.

From that perspective....

What does this buy me over the other more popular frameworks? What are the chances that this won't be abandoned if it doesn't gain traction? It's also easier to recruit developers if you say your stack is built on the more popular frameworks.

On the other hand, even though I've never used Ruby on Rails, this is written by BaseCamp so I do give them a slight benefit of a doubt. Just like I would give Kotlin the benefit of a doubt based on my experience with JetBrains' products.

[+] scarface74|8 years ago|reply
(I don't like adding to a response once it's been commented on)

My other rule of thumb when choosing a framework is what would happen if things go south, will I be asked by management why I chose X? The old "no one ever got fired for buying IBM". With a pedigree like BaseCamp has, I could justify it by saying it came from them. Just like I justified using Hashicorp's Nomad, even though no one had ever heard of it before I introduced it.

[+] z3t4|8 years ago|reply
What does ES6, Jquery, Handlebars, Bootstrap and Angular 2 buy you ?
[+] fiatjaf|8 years ago|reply
"A modest JavaScript framework for the HTML you already have" is a great headline. I haven't read anything and love this already.
[+] maxehmookau|8 years ago|reply
This feels like it has a whif of Angular about it. Controllers in HTML attributes...

Are we likely to see this in Rails 6? I'm a full-time Rails dev these days and I struggle to keep up with all the new things that are coming through that I'm not using day-to-day on older apps! Webpacker, Action Cable, just to name a couple.

[+] bruncun|8 years ago|reply
Reminds me too of AngularJS. Rails has dramatically changed how it handles front-end, but it would be tough to compete without doing so.
[+] Touche|8 years ago|reply
I don't understand the example. How does:

  // hello_controller.js
  import { Controller } from "stimulus"

  export default class extends Controller {
    greet() {
      console.log(`Hello, ${this.name}!`)
    }

    get name() {
      return this.targets.find("name").value
    }
  }
get connected to the <div data-controller="hello"> element? I would expect something like `stimulus.register("hello", HelloController)`...
[+] edwinyzh|8 years ago|reply
yes, I had that question when I first read it - it's not obvious enough.
[+] ghostbust555|8 years ago|reply
So... knockout?
[+] bruncun|8 years ago|reply
Damn, they're actually a lot alike. The differences I see are subtle - Stimulus seems simpler in practice, scopes controllers, state stored in document, uses native APIs, etc. but there's definite overlap.
[+] startupdiscuss|8 years ago|reply
I said the same thing and noticed you had said it 4 hours earlier.

Whatever happened to knockout? If it failed, why?

[+] gedy|8 years ago|reply
Yeah was my initial thought. I suppose Knockout is perceived by many to be old/legacy, though. On the up side Stimulus might help Rails apps minimize adding piles of jQuery.
[+] Tloewald|8 years ago|reply
I do like the brief and to-the-point introduction. Stimulus seems somewhat similar, or at least similarly motivated, to a framework I've been creating as I go -- https://bindinator.com/

(It's gotten quite a bit bigger than stimulus as it's been used. Such is life.)

[+] weego|8 years ago|reply
This has alot of similarities with Lift snippets, part of a Scala web framework (https://liftweb.net), which has been a goto of my company for many years
[+] sparaker|8 years ago|reply
Looks simple and self explaining framework. Would work well for legacy and small projects that don't need a lot of state to work with.
[+] sadiqmmm|8 years ago|reply
stimulusJS looks really awesome framework :) Thanks Basecamp and DHH.
[+] xrd|8 years ago|reply
What's the testing story here? Anyone know?
[+] amorphid|8 years ago|reply
For a quick & dirty look, I did `git grep test`. In there, I noticed circle.yml in the root directory, which I'm guessing is for testing on Circle CI.

From this...

https://github.com/stimulusjs/stimulus/blob/master/circle.ym...

Until you have a better idea of how to proceed, try this:

$ curl -o- -L https://yarnpkg.com/install.sh | bash

$ yarn

$ yarn test

I'm completely guessing here. I've never used Yarn before just now, but I suspect you'll find some of your answers in there.

[+] holydude|8 years ago|reply
It is becoming more and more apparent that with every piece of technology that is not really turn on/turn off you have to justify the investment.I get that this is an opinionated piece of software and solves basecamp's kind of issues but I do not see it being widely adopted.

That said I wish people behind RoR would actually work on better integration with things like React and Vue.

[+] itwy|8 years ago|reply
In essence, Basecamp has a well-maintained legacy system that they keep patching up because it doesn't make sense businesswise to rewrite it from scratch using modern methodologies. Good for them, I do that myself but be careful going down that path if you are starting a new project and you have the resources/experience to have a more solid/correct foundation with proper separation of concerns.
[+] meesterdude|8 years ago|reply
Just because they have different ideas and opinions than yours, does not make them in any way wrong or legacy, or unsolid or incorrect.

Also, basecamp has been rewritten 3 times.

[+] simple_sally|8 years ago|reply
Hmm not so sure. I may be wrong but I am pretty sure every major version of Basecamp has been a ground-up re-write of the app.