Javascript in Quire Projects

[egardner]

Hi @geealbers and Quire team! I hope things are going well.

I wanted to throw an idea your way regarding how to handle javascript in Quire projects. Apologies in advance if an issue thread is not the best forum for this kind of discussion.

Quire strives for a high level of accessibility and progressive enhancement in the publications it creates, goals which too many web projects feel free to disregard. But at the same time Quire is also designed to offer some pretty high-level features in JS (full-text client side search, various multi-media components like maps, videos/etc, and an elegant UI).

In the JS world, there is often a tension between tools like React or Vue (which let developers write well-structured, easy-to-read code but force an all-or-nothing approach on the users), or older tools like jQuery or plain DOM scripting (which are more amenable to progressive enhancement but can make code organization much more difficult once things go beyond a basic level of complexity).

I recently came across Stimulus.js in my own work, and I think that it could be very useful in this project. It is developed by the same people behind Ruby on Rails, and embraces progressive enhancement as a philosophy. It is explicitly not a single-page-app framework. There is also a well-written guide.

Stimulus is a JavaScript framework with modest ambitions. Unlike other frameworks, Stimulus doesn’t take over your application’s entire front-end. Rather, it’s designed to augment your HTML by connecting elements to JavaScript objects automatically.

Using Stimulus would be a departure from the way we have organized JS in Quire projects in the past, but I think it would enable us to greatly simplify the JS we ship to users in the starter kit. It could even be used without a build system if you want to move away from doing so much with Webpack by default.

If this is something you want to consider, I could open a pull request in the starter-theme that shows how to use Stimulus for search functionality; that would probably be enough of an example to extrapolate from elsewhere. Happy to discuss further if there is interest.

[geealbers]

Hey @fchasen, @mantasandri and @naeluh, would love for you to take a look and weigh in on Eric's idea here. It sounds like a nice approach, but just as with any other new tool or methodology like this, to adopt it for Quire, I'd want it to be two things:

1. a relatively seamless and/or useful addition to Getty Digital's current internal expertise and tools
2. a notable improvement for the Quire user (whether for the reader of a Quire book, or for a future internal or external developer working on a new Quire theme)

What do you think?

[naeluh]

We did discuss this a bit today, and as there are a lot of pluses to using a library like stimulus.js. The documentation does not seem to want to support older browsers.

Stimulus is known to support Internet Explorer 11+ and Safari 9+ using these polyfills from the core-js and element-closest packages.

Stimulus uses modern javascript tools to get performant results which from dev standpoint is helpful. I feel as though this might be for a another phase though. Since accessibility is a priority this could drop off support for a decent number of users browser experience. Modifying the code to use this library might help the developer but maybe not the end user so much. However as support improves across browsers and older browsers depreciate, I think quire would get more out of adopting a library like this.

We could look at some metrics and end of life dates and choose the best time to add something like this. Does quire want support older than Internet Explorer 11+ and Safari 9+? Let me know if you have any questions or if I can clarify in any way.

Thanks!

[egardner]

The question about browser support is an important one – personally I see anything older than the latest version of IE as a lost cause (MS doesn't even support that browser any more), but every organization will have different needs here.

As far as the benefits/drawbacks of using a more modern JS framework, I'd say the biggest benefit (which will ultimately make a difference to end users) is that it will become faster/easier for developers to add interactive features to Quire projects. A modern framework will make it much easier to build out features as small modules that manage their state locally.

In other projects, I've found that using tools like Vue.js makes building a rich user interface fast and straightforward (and easy to reason about/debug). But that requires going "all in" on JS in a way that I agree is not appropriate for Quire given the project's goals. I do think that Stimulus is interesting because it may be able to deliver the best of both worlds – the benefits of a modern JS workflow along with the better accessibility/browser support from a classic progressive enhancement approach.