Hacker News Reader

Comment by scarface74 | Hacker News Reader

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.

View on HN

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

At some point, you have to stop following that advice or you end up on Lotus Notes and Tivoli. Which is entirely relevant to this discussion.

And I bet you the people who were consultants for those implementations never got fired because they chose them.

Yep, I'd fire the CTO.

Not if the CTO said he chose Lotus Notes and Tivoli because they were in Gartner's magic quadrant based on the long gone consultants he hired.

Yes, I know it's a circular argument, but that's how corporate America works.

The mediocre kind sure. But they'd get sacked at a tech company easily.

If your primary metric is "do established companies use / support this", you're already well served by React / Angular, which are supported by Facebook and Google respectively.

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 don't have to use the most popular framework, but that is a consideration, but if I am going to use something that is less popular and as foundational as a framework, it has to be either somewhat popular or from a company with a pedigree.

Nomad is nowhere near as popular as Kubernetes, but Consul has been around for awhile as has Hashicorp's dev ops tools (Vagrant, Packer, and Terraform) and are all reasonable popular. You can tell people for everything except Nomad - go watch a PluralSight video.

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

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

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.

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.

I believe this section attempts to answer that question:

https://github.com/stimulusjs/stimulus/blob/master/ORIGIN.md...

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

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.

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

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

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.

> It bothers me a bit that it feels intentionally dismissive of (or oblivious to) the current state-of-the-art of JavaScript frameworks.

This is definitely not software for you then.

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.

"tenet" (principle), not "tenant" (occupant of a dwelling)

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.

What does ES6, Jquery, Handlebars, Bootstrap and Angular 2 buy you ?

Better built ins and direct style, standardised DOM before it existed, grid layouts before they existed and widgets, a virtual DOM which updates when your data does. What's your point?

For me they just get in the way, they add unnecessary hurdles to dev and slows down the page performance and load time. I currently work with dev-ops and is always interested to hear about peoples pain-points and try to figure out how to solve them in a more lean way.

Well yes, since except templating and data binding they're all included out of the box now. But the ones that aren't are useful.

ES6 - The standard version of JavaScript that all browsers support/will support.

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.

Reply on news.ycombinator.com