3 ms·
I never understood the vehemence against inline javascript. From the article, how is this: <button id="my_btn" onclick="doThis();">Submit</button> Supposed
by scottfr 14y ago
I never understood the vehemence against inline javascript. From the article, how is this:
<button id="my_btn" onclick="doThis();">Submit</button>
Supposed to be worse than:
<button type="button" id="my_btn">Submit</button>
combined with (usually located in a different file or several hundred lines away):
document.getElementById("my_btn").addEventListener("click", doThis);
It seems like the latter is much more difficult to maintain. Sure inlining much more than a simple function call get's hairy, but for a simple action inlining always seemed much cleaner and easier to maintain to me. It's much nicer than a whole bunch of addEventListener's or bind calls in your JS.
- unwiredben 14y agoThere are major HTML platforms, like Windows 8 applications and the new Chrome apps, where inline event handlers are verboten because of the potential for allowing XSS attacks on applications from external content. Giving only JS code the ability to register more JS code removes this attack surface.
- apsurd 14y agoI personally don't like javascript in my HTML, and vice versa.
- mechanical_fish 14y agoThe 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.
- Smudge 14y agoI like being able to change the behavior of my application without having to make changes in the markup (some of which can even ripple out into the stylesheets). Things just scale more cleanly as the app's complexity increases, and the separation of concerns feels much more productive than having to search through hundreds of lines of HTML for in-lined function calls.
- ssttoo 14y agoWhat if you want to load JS asynchronously? How do you know that `doThis()` is defined?
- guilloche 14y agoI also believe that inline js code is cleaner and easier to find.
- mattmanser 14y agoTo add to the other reasons, It's a right pain in the ass when automating browsers to test your app as you can't click an anchor (it's a security thing). So this will cause problems, which MS used to use all the time in their frameworks: <a href="javascript:CantClickMeWithCode();">thing</a> MS have even come up with a term for not doing it 'unobtrusive javascript'. It doesn't really seem to be catching on as I've not seen anyone but the ASP.Net team use it.