
Stimulus: A modest JavaScript framework for the HTML you already have - tmlee
https://github.com/stimulusjs/stimulus/
======
sheraz
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](https://github.com/turbolinks/turbolinks)

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

~~~
aaron-lebo
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.

~~~
bphogan
Front-end stuff doesn't have to be complex, but it is. For example, a lot of
places using React think they need Redux too. And React-router. And many other
components. React itself is quite simple. But the architectures that
developers build are often incredibly complex.

This was the case with jQuery, Angular, and things that came before.

I see two main problems in software development, especially on the front-end.
First, developers jump on brand-new ground-breaking frameworks and use them in
production, learning how they work as they go. This results in brittle
systems. That's not necessarily bad, but it's not always great from a
maintenance perspective. React is hot right now. But there are a ton of in-
production Angular 1.x apps out there because that was what was hot when those
projects started.

That brings me to the second problem in tech - developers doing the "hot new
thing" displaying a ton of hubris. It's "easy" and "straightforward", implying
that anyone who doesn't get it just isn't smart or will be obsolete soon.

I'd worry more about losing my job due to not keeping up with machine learning
rather than not learning whatever new JS framework people think is hot right
now.

Here's the deal - web developers figured out server-side rendering 20 years
ago, and managed to make turning databases into web pages easy about 12 years
ago. It's possible to create applications that people love using a lot of that
technology, with some JS on top. It's certainly faster to go to market with
something that way.

Not every app is Facebook. A lot of the stuff people work on outside of HN
fall into one of two categories:

1\. Apps that are behind a firewall - internal in nature, used by a handful of
enterprise users. 2\. Apps that won't be around in 3 years from now because
the company will shift focus/replace it with an off-the-shelf product/company
gets acquired.

In both those cases, I'd look for the simplest approach to get something
running, and simplest to maintain.

Bottom line: it's easier to leverage existing skill-sets than it is to ask
people to learn a whole new thing all the time.

Anyway, at the end of the day, I don't really get too worked up about how
another person chooses to solve the "make the browser display a web app."
Every situation is different. React can be simple. So can server-side
rendering with some Knockout/Stimulus/Intercooler/jQuery sprinkled around.

Maintainable quality code that makes money wins in the long run. Whatever you
implement it in.

------
bruncun
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
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.

~~~
crescentfresh
> 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.

~~~
jaredcwhite
I should have worded that better...in this context, it's not that Vue the
library is overkill, but the overall paradigm. Vue's not well-suited to
server-rendered HTML that has some dynamic features after the fact.

------
scarface74
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
(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.

~~~
lostphilosopher
> "It allows us to party with productivity like days of yore. A throwback to
> when a single programmer could make rapacious progress without getting stuck
> in layers of indirection or distributed systems.
> [source]([https://github.com/stimulusjs/stimulus/blob/master/ORIGIN.md...](https://github.com/stimulusjs/stimulus/blob/master/ORIGIN.md\)")

I suspect if you're in a situation where you need bureaucratic approval or
"CYA" you don't have one of the main problems stimulus is trying to solve -
helping small teams or single developers create apps that can keep up with
apps written by larger teams with more specialities/ists.

Doesn't mean you can't or shouldn't use it, but it does mean you've got
options others might not. I do freelance development from time to time by
myself. There's a limit to how big/complex of a stack I can be responsible
for. Rails has been a great tool for me even though in my "real" job we use a
much more robust toolset - in my real job I work with a team. I'm pretty
excited about what I (by myself) could do with stimulus. :-)

~~~
scarface74
I am the architect for a small development shop. Upper management has never in
the past year said no to my decisions. I built our dev shop from scratch -
environments, procedures, trainings, dev ops, and many of the hires.

I'm very cognizant though if things went south because of major architectural
decisions I made - not minor code bugs - or that they didn't give the
scaleability, reliability, Security, etc. that was required it would be a
major blow to my reputation.

From a more practical standpoint, I'm hiring mostly contractors. Good
contractors want to gain skills that will help them on their next gig. It's a
lot easier to recruit people when I can tell them we are using the latest,
greatest, stable technology (mostly backend work). Also, as a developer, I
always "keep my running shoes around my neck". So I balance my decisions on
what's the best for the company (highest priority) and what's best for my own
career for my next job.

~~~
lostphilosopher
I don't disagree with anything you're saying. You're working in a specific
context that affords you a set of options different from the sets of options
available in different contexts. My read of Stimulus is that it's geared for
contexts other than yours. However, it could still be one of your options.

Which brings us to - "scaleability, reliability, Security, etc." \- valid
concerns! Depending on your context's risk tolerance brand new technology
might not be an option at all, ever. You've already pointed out elsewhere the
reasons to give Stimulus "the benefit of the doubt." So maybe it's within your
context's tolerance? Maybe not.

But here's two distinctions I think are important. First, for many businesses
and applications the biggest risk vector isn't scalability, or reliability, or
even security - it's existence and viability. Can this be made (within X
constraints) and do people want it? Will they pay for it? Will it turn a
profit? If the answers are "no" no amount of technology will help. Rails (and
Turbolinks and Stimulus, etc.) should certainly allow your app to be scalable
(etc), but are optimized for the productivity needed to answer those questions
- including on limited time with a tight budget. My freelance rep depends just
as much on my abilities in that domain as it does on my more technical chops
(a somewhat unintuitive realization for a developer). The second distinction
is most important, and the piece I often think is missing - just because X
technology is scalable, reliable, and secure doesn't mean any implementation
of it is. What's cool about the "Rails/Basecamp way" is that it puts
scalability, reliability, security, performance, etc. within reach for a wider
range of people/teams. Stimulus seems like another step in that direction.

------
dsego
I think this is the library mentioned in the recent rails podcast.

Relevant HN discussion:
[https://news.ycombinator.com/item?id=16021808](https://news.ycombinator.com/item?id=16021808)

------
fiatjaf
"A modest JavaScript framework for the HTML you already have" is a great
headline. I haven't read anything and love this already.

------
maxehmookau
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
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
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)`...

~~~
Touche
Ah, nevermind, this goes over that:
[https://github.com/stimulusjs/stimulus/blob/master/INSTALLIN...](https://github.com/stimulusjs/stimulus/blob/master/INSTALLING.md)

------
ghostbust555
So... knockout?

~~~
startupdiscuss
I said the same thing and noticed you had said it 4 hours earlier.

Whatever happened to knockout? If it failed, why?

~~~
titusjohnson
It's not dead, it still receives updates (as recent as 4 days ago). There's an
overhaul in progress called TKO
([https://github.com/knockout/tko](https://github.com/knockout/tko)) that is
supposed to bring Knockout up to date with ES6, a better plugin API, and other
nice stuff.

------
Tloewald
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/](https://bindinator.com/)

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

------
startupdiscuss
This reminds me of knockout.

[http://knockoutjs.com/](http://knockoutjs.com/)

Whatever happened to knockout?

~~~
philippnagel
The devs seem to be mainly working on an updated version without a lot of the
legacy code:
[https://github.com/knockout/tko](https://github.com/knockout/tko)

~~~
startupdiscuss
Thanks.

A better home page? How could they possibly improve on that homepage. It is
the envy of front-end JS package homepages.

------
weego
This has alot of similarities with Lift snippets, part of a Scala web
framework ([https://liftweb.net](https://liftweb.net)), which has been a goto
of my company for many years

------
sparaker
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
stimulusJS looks really awesome framework :) Thanks Basecamp and DHH.

------
xrd
What's the testing story here? Anyone know?

~~~
amorphid
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...](https://github.com/stimulusjs/stimulus/blob/master/circle.yml)

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

$ curl -o- -L [https://yarnpkg.com/install.sh](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
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.

~~~
meesterdude
Rails is an open source web development framework that excels in productivity
by coming with smart defaults for people to use to get up and running quickly.

Rails already integrates with webpack, and you can certainly implement your
own integrations to further advance things - and you can turn around and make
this a gem for others to use, or contribute it to core if its something more
fundamental.

But for the most part, the people behind RoR are pretty happy using RoR for
their development, and don't need to use React or Vue for a majority of what
they do.

~~~
bromuro
React and vue are great for creating interactive widgets (no flash anymore).
it doesnt’t mean necessarily to change how we code :)

------
itwy
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
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.

~~~
itwy
Try to discuss the idea not my personal opinion.

~~~
learc83
The central argument of your post appears to be based solely on personal
opinion because you provided no evidence to back it up.

meesterdude provided evidence that runs counter to that opinion. I'm not sure
what you're complaining about.

~~~
itwy
He's parroting what they said. "rewritten"... more like revamped.

~~~
learc83
You're not really responding to my argument, which I'll state again: Your
argument and your opinion are indistinguishable because you haven't supported
your argument with anything other than opinion.

"rewritten"... more like revamped.

You still haven't supported this. Why do you believe it was "revamped" instead
of "rewritten"? What are you basing this on?

