Golem should discourage the use of raw JS on shiny elements and/or point to safe alternatives

[daattali]

(This is regarding both golem and its "engineering shiny" book - because the book is listed in the README as "The book" for golem, I thought it's appropriate to open the issue here)

I think Golem does a fantastic job at prividing and explaining a practical useful framework for building shiny apps.

I do have some worries however about the javascript guidelines that golem/the book provides. Teaching the basics of javascript to the average R user is not an easy task, and you've done this very well. But writing robust javascript code that interacts with shiny is not a trivial task, and I think golem/the book does a disservice to shiny devs by recommending the use of .show() .hide() etc. in custom javascript code or recommending the use of golem's javascript functions. There are several issues with this approach, such as the fact that shiny won't know about the inputs being shown/hidden so it will not render them efficiently, and if the uer wants to hide an input then they'll have a very hard time figuring out the correct selector. Because these are common and useful things to want to do, there is a package dedicated to exactly that - shinyjs (disclaimer: it's my package). And it also provides a mechanism similar to what golem tries to achieve with invoke_js. I feel that the strength of goelm is in providing the framework for a shiny app, and the javascript bits are a bit out of scope for golem's missions and they feel like reinventing the wheel when there is a much better solution already.

I realize this may seem as biased and self-interested because of my package - but I truly believe the golem/book guidelines are not in the best interest of users.

[VincentGuyader]

Hi Dean Thanks for your message! We well know {shinyjs}, and invoke_js try to help people to use java script in shiny (from beginner with prebuilded js function to expert..), like shinyjs.. One of the main reason why we worked on javascript inside golem is because of licence issue with {shinyjs} (it was asked by some of our customer to remove shinyjs, to have a commercial-proof shiny application).

Regards

[daattali]

Oh, interesting! Thanks for letting me know. This was the nudge I needed to remvoe the license. I completely agree with your assessment that the whole workflow should be completely FOSS.

I added it initially because big companies were asking me for a license and this was the easiest way for them to use the package, but it seems to cause a lot of headaches to everyone else, so I just removed the license. I've been thinking about it for a long time and needed a tiny push to see how restrictive it is! License is gone :)

[ColinFay]

Hey,

(Doing some issue triage this week before a new release that will come in a few days, so I'm posting an update about this).

That's very cool for {shinyjs}, I'm glad to hear that 🎉 (I can see it's been on CRAN for ~ 10 days, that's fantastic). As Vincent said we had issue incorporating {shinyjs} in projects because of the old commercial licence.

I don't think we'll remove the invoke_js() and add_js_file() functions from {golem} — I feel like {golem}'s goal is to provide a coherent (structure-wise) way to build the infrastructure, hence adding JavaScript file in the correct folder to allow to write and call your own JS is in scope (as is writing your own CSS) if you know how to do it (for example I write a lot of custom handler myself), or as is writing a Dockerfile for heroku: small portion of the users will benefit from it, but that's still useful for medium/advanced users.

When it comes to the book, I've written a new Prelude to the JavaScript chapter that advices against writing your own JavaScript if you're getting started with JS, and to go for a safer alternatives. It's been sitting on my laptop for a couple of weeks, I'll put is below this comment so that you can have a look at it before it's online :). Regarding the rest of the content of this chapter, I still think it's relevant: one has to start somewhere learning JavaScript, and if we want to see more people being good at JavaScript in {shiny}, I'm all up for giving them some help getting started :)

That being said, now that {shinyjs} is fully MIT, I feel like we can safely deprecate the JavaScript built-in functions from {golem}, which basically overlap with what {shinyjs} does better. That will be too late for the next release, but let's deprecate this for the version after that.

I'm opening another issue to plan that for golem 0.4.0.

Cheers, Colin

Ps: preview of the Prelude of the JS chapter

Prelude {-}

Note that you can build successful, production-grade {shiny}[@R-shiny] application without ever writing a single line of JavaScript code. Even more when you can use a lot of tools that already bundle JavaScript functionalities: a great example of that being {shinyjs}[@R-shinyjs], which allows to interact with your application using JavaScript, without writing a single line of JavaScript.

We chose to include this chapter in this book as it will help you get a better understanding on how {shiny} works at its core, and that getting at ease with JavaScript can help you get better at building web applications using R on the long run. It can also help extending {shiny} with other JavaScript libraries, for example using {htmlwidgets}[@R-htmlwidgets], when you get better at writing JavaScript.

That being said, note also that every inclusion of external JavaScript code or library can present a security risk for your application, so don't include code you don't know/understand in your application unless you are sure of what you are doing. As a rule of thumb, always go for an existing and tested solution when need JavaScript widgets/functionalities, instead of trying to implement them yourself.