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.
Thank you for the kind words about intercooler.js. :)
If you are interested in some reading on the theory behind it, I recommend these two blog posts that explain how HTML and REST/HATEOAS hang together better than Javascript with JSON:
intercooler should work in any browser that your chosen version of jquery or zepto works in.
If you want to see if a particular browser is compatible with a particular version of intercooler + (jquery || zepto), the unit tests are linked off the release page:
This will run all tests for intercooler 1.2.1 using jQuery3 as the underlying library. Be sure to let the window retain focus or a few tests will fail.
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.
Don't throw the baby out with the bathwater maybe? Here's a fixed version of your statement:
"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.
I haven't tried out Turbolinks yet, however wouldn't the developer implementing Turbolinks make sure they don't have a progress bar along the top for another purpose first?
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.
I've used turbolinks in production and it is great. The progress bar is clunky, but it is optional, and not needed anyway if your pages render in a reasonable amount of time (100ms to 200ms is "instant" to most people). I can't really fathom how the parent to your post saw a slowdown using turbolinks - because the server doesn't know the difference, and the client does less work.
Turbolinks is often a terrible user experience. The user doesn't measure page load in seconds, but in the perceived load in seconds. Turbolinks on slow connections feels painful, including on big sites with fast servers, like YouTube and Github.
My comment above mentions that. It's about perceived page load time. There are small tricks that sites do to make UIs appear faster, even if they aren't really faster. Turbolinks has the opposite effect, making the loading appear to be worse on bad connections or when there are other rendering problems.
I doubt that people think much when they implement Turbolinks. It's built into rails by default so you have to go out of your way to disable it (--skip-turbolinks).
I think that a loading bar across the top of a web page shouldn't have multiple meanings. For consistent signaling to the user about what the browser is doing, the browser should take care of telling the user what action is being performed (loading).
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.
> The Turbolinks/Intercooler approaches seem to be managing state with the DOM,
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.
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.
> 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 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.
I'd be careful with predictions wrt JavaScript frameworks. Though I personally like React, just two or three years ago Angular was the framework of choice for many (I've never been a fan of it). Front end framework churn seems inherently cyclic in nature, where a new minor generation breaks with tools of the slightly older generation to define itself on the marketplace.
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.
React isn't complex, but pretending JS supports immutable structures makes it hard to use. I have some pretty deeply nested json structs and it looks like a i have to flatten them out to use react. I suppose mobx might be a better way to handle this.
Thanks for the heads up. I've worked with Intercooler before and while it is a really nice framework, I've always felt it was missing a few critical things. Unpoly looks cool. Do you know if it has a dependency on jQuery still, like Intercooler does? Or does it run independently?
Hello, I've been watching intercoolerjs also, and thinking of using it in a future project. What are the few critical things missing have you experienced ?
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.
I'm one of the knockout core developers. Just a heads up, knockout 3.5 just went into beta, and 4.0 is in alpha.
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.
Very cool; I'm super glad to hear its still going strong.
My last full stack project where I touched the front-end was 100% knockout + some custom routing + commonjs module organization, and I still have fond memories of it relative to most other front-end experiences pre-2014.
re router: I think having an option for a built in 1st class router would be nice. My hacked up quick ~75 line solution was essentially just using the dom as an event bus with custom (consistent) payloads to control state change/ notifications/etc... works great for small stuff, but would probably break down in a huge application.
If I get back to the front-end any time soon, I'll definitely be looking back at ko.
I double that knockout is amazing (and never targeted "true" frontend space, like routing), but from my point of view, it is targeted towards more "rich" applications.
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.
> and never targeted "true" frontend space, like routing
that was why it didn't catch on as much as it could have, in my opinion. The thing is, it was SO easy to rig routing together quickly yourself; I ended up doing dom event based routing for a lot of stuff. If you actually took the time to throw a real/reusable hash or pushstate based router on it would be pretty damn good....
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.
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.
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.
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.
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.
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?
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.
(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.
> "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.
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.
> 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();
})
}
})
> "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).
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.
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.
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.
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.
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#)
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.
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.
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.
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.
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) that is supposed to bring Knockout up to date with ES6, a better plugin API, and other nice stuff.
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.
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.)
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
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.
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.
They have improved the integration with Webpacker, but also bear in mind if you don't use the HTML/UI type functionality in Rails, it's a lot less compelling.
I'm assuming DHH/RoR is sensitive to that hence these solutions like TurboLinks, Stimulus, etc that still use server rendered HTML.
Definitely agree. What would be really great is an easy way to symc the status between client and server, with generators for the api and a client library to manage the status which could then be used with react or any other similar front end framework.
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.
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?
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/