The Origin of Stimulus JavaScript Framework | Hacker News Reader

The Origin of Stimulus JavaScript Framework

stimulusjs.org

101 points_quhg29 comments

I've been using Stimulus in a couple of projects render HTML server-side and use Turbolinks.

It makes JS enhancements/sprinkles so much easier to implement. Stimulus is a step in the right direction from jQuery hell but not a fully loaded client-side rendering framework.

I've done a lot of React/Angular/Vue in the past. Stimulus is a much more light handed approach that I really appreciate as a developer -- less duplicated logic and common sense defaults. Dead simple to pick up.

For content based sites, Stimulus is a much better tool IMHO.

How easy is it to use it outside of Rails, e.g. in Django?

Stimulus is not bound to Rails in any way. It‘s just an NPM package which can be used whereever you have a JavaScript bundler setup (e.g., Webpack). I‘m not sure whether there is a build that can be embedded directly with a <script> tag.

It's a matter of including a <script> tag and then reading the caveats. Very likely to work for a traditional server-rendered app.

This is exactly where my company was headed. We had a JS framework that creeped closer and closer to a full-blown data-attribute controlled environment. We use a ton of SSR to serve the views, and it is fast on every device and system. It's easy to iterate and add features and with very low overhead.

But... it hit a point where Vue.js was just so far superior to our own inhouse framework, that any interface that needs highly interactive component get's Vue now. Since Vue can run as a script file (hoping it gets the full ES module treatment soon) then we can splash it around anywhere in the interface we want, just like jQuery and our custom framework.

Now our system is like this: SSR > Full page > Vue app/vanilla js tweaks.

Updates are: AJAX/fetch a block of HTML into an element, and it can be a full Vue app, or just a block of content.

It's interesting to see that Basecamp ran into the same problems we did and didn't find that the full-on SPAs everywhere was the right solution for them. It's a nice bit of confirmation that there are many different ways to solve a problem that are valid.

As antagonistic as this Stimulus site seems to be towards React, it can be used similarly and you can tell it was built that way by Facebook who used it to replace a lot of bespoke jQuery slowly over time rather than write everything from scratch from day one. Contrary to some opinions, it's more than possible to have React handle only a small portion of a site incrementally, React itself isn't really a "SPA framework" out of the box. (It's the ecosystem of tools like react-router that make it a SPA.)

There are indeed many different ways to solve these problems. My biggest criticism with the Stimulus documentation here is that it feels so disparaging of other people's solutions.

>it feels so disparaging of other people's solutions

In many ways, I wouldn't expect less from Basecamp. Superiority and self-righteousness seems ingrained into basecamp's culture.

You should experience Railsconf once. For all of DHH's pompousness, he gets taken down a peg every year by Aaron Patterson's closing keynote.

This year he raged against the Twitter war that was waged on Foo, Bar and Baz

https://m.youtube.com/watch?v=cBFuZivrdT0

Lots of DHH ideas are take or leave. The consensus seems to be that you need to wait a while before embracing new features in Rails, because they are often released half-baked and frequently no good until the second try. (Take credentials for example, or turbolinks.)

That being said I am really interested in Stimulus, as based on the promotional pages at least, it seems like it is not very big and it would be hard to do wrong. I haven't "bit" for any JavaScript framework yet since jQuery, and consequently all my JavaScript is pretty terribly disorganized. It is very encouraging that this has made it to 1.1 without any apparent major overhauls!

Including nearly 600kb of JavaScript for something that doesn't need it is insane.

I just went looking for a minimal react install and found this:

https://github.com/krasimir/react-bare-minimum

When I was able to get it working, it came out to 880kb. That's more than (nearly) 600kb! I thought you were exaggerating.

The stimulus umd.js by comparison is 60kb uncompressed.

ReactDom is the actual culprit. Preact [1] is a great ~4kb alternative, though it's still on the v15 API.

React makes sense for something like Facebook/Instagram web where users interact with the app hundreds of times in a single session, but we can't fall into the trap of treating it like jQuery and hitting every nail we come across with it.

I'm hopeful that like jQuery, whatever features that make ReactDom et al. so large will eventually make their way upstream and be codified as browser specs.

[1] https://github.com/developit/preact

I've heard of preact! Thanks for reminding me of this

That "bare minimum" repo is including a lot of Babel polyfills. You could use Typescript instead of Babel, and shave off a bunch of polyfills in the process.

Comparing apples more to apples, while the react-dom.development.js is indeed ~600 kbs. The minified production build of react-dom is only ~70 kbs [1], which is is smaller than jQuery minified (but not gzipped) [2].

It's not necessarily React itself that is bloating these project sizes.

[1] https://github.com/facebook/react/releases [2] https://mathiasbynens.be/demo/jquery-size

This looks like a great step forward for that jQuery style of frontend, but after using React I'm never going back. I favor Rails rendering most things and React for the highly interactive parts. I can see myself switching over to SPA eventually, but I'm waiting for the ecosystems to settle down and reach the same ease of use as Rails.

I've been interested in learning about Stimulus since it was quietly announced, as a way for my team (Rails developers) to keep our JavaScript organized and let it leave a minimal footprint.

That being said, I think I've seen this before... is it being posted today because it's interesting, or because something is new about it?

edit: ah... linked from the front page[1]

v1.1.0 - @sstephenson sstephenson released this 19 hours ago

[1] https://github.com/stimulusjs/stimulus/releases/tag/v1.1.0

> No, the reason is that CSS and JavaScript has to be reinitialized and reapplied to the page again.

Glad to see this mentioned.

Hopefully legions of devs can least now UNDERSTAND why SPA can be faster & what makes it so.

I don't understand what you are getting at.

In all the articles written about SPAs being faster, 99% of them miss the mark when it comes to the why - namely the above.

I can't remember ever seeing one of the fundamental reasons explicitly being called out..leading to vast amounts of devs never truly grasping the why of 'why are SPAs faster'.

Ah.

The article was about not doing a SPA, so I was confused.

Yes, they found a way to extract the part that makes SPAs fast and applied it to their legacy code-base.

My idea of SPAs performance gain was mainly that they didn't send HTML, but JSON, which I cosindered vastly smaller.

The problem is that the first load can absolutely kill everything and having second request served faster won't help.

(e.g. me opening GMail in Indonesia and never being able to load it)

I dislike the general SPAs are faster "truth". They might, they might not and the initial load can be just too much. You can sure spend time to optimize SPA to perform well though. Btw Turbolinks tries to solve this "do not parse JS again" thing and it's where the speed comes from.

> As though we had followed the herd

Tad condescending there...

The herd is real though, and it's often headed in bad directions. Content-based sites should be server-rendered.

> Content-based sites should be server-rendered.

Why?

The anti-herd is real.

You'd think it ideal for them to be served static.

This seems to be very similar to KnockoutJS http://knockoutjs.com/examples/helloWorld.html

I've experimented with a similar approach before. I like the idea, but does it really necessitate a framework?

Yes, it's well documented and pretty easy-to-learn, prevents you from reinventing the wheel, and provides simple conventions for your team :)

Yes, if you can't predict what web browsers your audience has, and if you don't have time to write a test suite for your own in-house solution. I don't know if StimulusJS has accessibility support but that's another reason to choose a framework.

Reply on news.ycombinator.com