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

What is the browser support for intercoolerjs?

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.

Moreover, it must be said that neither React nor Angular are front end libraries in itself; they merely organize DOM manipulation and event handling in a more or less bureaucratic way.

I won't speak for turbolinks, but with intercooler the idea is to return to a stateless architecture, the second aspect of the REST-ful architecture[1]. State, as such, is stored on the server, not on the client.

It has scaled quite well in my applications: browsers are very fast at swapping new HTML into a page. The downsides can be additional chattiness with a server and a lack of interactivity if you are building a fancy (or fancy part of an) application, such as a game. In those cases, intercooler is not a good choice.

[1] - https://en.wikipedia.org/wiki/Representational_state_transfe...

You are always going to have a hard time convincing others when you speak in absolutes while invalidating all other cases.

To me these non-full stack frameworks actually meets a totally neglected market full of people that come from jQuery before even learning vanilla Javascript.

Different strokes for different folks, and that goes for how perception of complexity is interpreted. Someone knee depth into React/Redux will not be able to walk in the shoes of someone just exploring or even experienced developers looking for something more simple and easier to get into.

So while it is possible to use it the same way as Turbolinks (or React), it is kind of between, which makes it is harder to justify.

However, it works perfect. So, if you read this, and you have it in your project, don't rush to replace with shiny new stuff.

I spoke the other day with another core developer, Ryan Niemeyer, and he noted that ko is still a good fit for quick and lightweight dynamics, but with good conventions a solid foundation for really complex Web apps. It's still very solid, and the API largely unchanged since IE6 was around.

Tko, the monorepo for ko 4+, will hopefully make it easier to build frameworks out of the knockout code, so things like routers can be easier to tack on (if we don't build one in).

Incidentally I've just set up a patreon for tko/ko 4 in particular at patreon.com/brianmhunt- it'd be great to be able to have more time to hack at it.

I think users would understand it is a loading bar and not a reading progress bar if it only appears after a link is clicked.

Also, if Turbolinks is implemented will Firefox on Android still display a second progress bar?

I ask these questions as I'm thinking of using Turbolinks myself and your comment does make me doubt.

"The default Turbolinks progress bar that can be removed with one line of CSS gives the impression that things are slow on slow connections."

Turbolinks is not perfect and has some drawbacks, but it also makes things faster in 99% (100%?) cases in my experience for almost 0 development effort.

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();
      })
    }
  })

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#)

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 think the companies who built a framework can be instructive though. Frameworks and libraries tend to reflect the companies who created them. In React / Angular's case, the frameworks are built to work well for large teams that deal with many moving pieces. Basecamp has always been a comparatively small team who values simplicity when appropriate, which I think this tool reflects.

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. :-)

JQuery - a simplified syntax to access the DOM, do ajax, and add events to elements.

HandleBars - if you don't want a heavyweight framework but you do want a simplified templating system. Handlebars is simpler.

My usual MO for front end development when I don't want to implement a full SPA framework:

1. Create a template with Handlebars

2. Use Ajax to get the model.

3. Render the template.

Or.

Create the view with Handlebars

Assign events using JQuery to the rendered elements.

Adjust the model based on the events.

Re-render the template based on the model.

But at some point, it makes sense to use a full fledged framework because at a certain level of complexity, you are reinventing the wheel. But even then, I can use Ember that uses Handlebars.

But it doesn't make sense to use Handlebars and Angular.

Bootstrap is for layout whether you use Handlebars or Angular.

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