The article provides Argument A against inline JS: "Show me all the dynamic JS that gets loaded for this page" is a more important case to optimize for than "sh

The article provides Argument A against inline JS: "Show me all the dynamic JS that gets loaded for this page" is a more important case to optimize for than "show me exactly which JS statement is tied to this button". This is particularly true because, in your example, having onclick="doThis();" in the HTML isn't all that helpful if you need to know exactly what doThis(); is doing. You'll still have to go find the actual block of JS that's defining doThis(), and that will still be someplace else. Yes, it might be nice to have that short descriptive name associated with the button, but that's what class="does-this" is for. Other arguments against inline JS: It's harder to test the case where JS is turned off. It's harder to ensure that all buttons of class "play" have the "playMe()" function attached. Doing it one button at a time is very un-DRY; you are going to miss one during some edit or other. Similarly, if you decide that buttons should call playMeLoudly() instead of playMe(), you have a lot more lines of code to change. With inline JS you are always one missing quote character away from a security incident. As I know from having played the awesome Stripe-CTF game, <script> tags are not your friend! They are very scary and should be very boring and kept away from your markup and edited as little as possible, and script-tags-in-disguise like "onclick" attributes should be regarded with suspicion.