3

I get that inline onclick=…-style handlers are bad, but I appreciate how they are active right away.

Still, these are modern times, so let's move on. Now, where and when should I put my click handlers (added through element.addEventListener or jQuery's click)? I expect at the end of the body, but I'm not sure. I couldn't find a reputable source to school me!

Also, should I add them all in an inline script element, or perhaps should I put a singular function call (e.g., "setupEventHandlers") there, and define it in a js file? I want to use what's proper and common, so as to adhere to the Principle of Least Astonishment.

But what about slow loading pages? Should I just expect the user to wait for the buttons to start working? Users like clicking stuff! Especially bored users waiting for a slow website to load.

Protector one
  • 6,926
  • 5
  • 62
  • 86
  • 1
    They're not "bad". They, like everything, have their pros and cons. Some people just tend to see things in programming as moral absolutes. Don't let them limit you. Make intelligent/informed decisions and you'll be fine. –  Jun 06 '16 at 11:41
  • personally I like inline click handlers - what is really wrong with it? – mguijarr Jun 06 '16 at 11:42
  • Yes, yes, we all love them, but they're bad: http://stackoverflow.com/questions/5871640/why-is-using-onclick-in-html-a-bad-practice. I'm currently tripping over their reluctancy to stop bubbling up, even after calling `stopPropagation` on various objects. – Protector one Jun 06 '16 at 11:44
  • If you have a small script you can uglify it and put it in a `script` tag. When the page is loaded the script is executed immediately. – Ram Jun 06 '16 at 11:49
  • @Vohuman: Yes, but the whole point is to avoid ugly. Let's do it nice and proper for once! – Protector one Jun 06 '16 at 11:51
  • 1
    There's just nothing bad about them, and I don't particularly "love" them. People who use such language often are repeating something they heard on the internet. If you're having an issue with bubbling, ask about that. They're just event handlers, and you can stop propagation just as easily. –  Jun 06 '16 at 11:51
  • @Protectorone Well, I didn't mean creating an ugly script, I meant minimizing the final code, making it _smaller_ in size. I usually do this during a build process before deploying projects. I care about maintainability :) – Ram Jun 06 '16 at 11:53

1 Answers1

3

The argument about inline handlers being 'bad' stems from way back in the early days when web design started attracting programmers who weren't just designers with a bit of code. To those people, it was important to separate concerns, such as the user interface (HTML) and the logic (JS) - or in MVC terms, the View and Controller. In other words, the view should just worry about presenting stuff, and the controller should worry about handling behaviour.

The reality is that HTML tells the browser to trigger an event by placing an attribute on an element. Jquery just does this programmatically, but the result is the same as if you placed the attribute there yourself. So there is a lot of room for debate about best practice, and no one ever has to agree, which is great for parties, but bad for people who want to know the answer.

The benefits of keeping logic separate from the view are well documented (Google 'model-view-controller pattern').

I'd say we were getting to a point where separating out handlers was becoming accepted best practice. But frameworks like Angular have sent things into freefall, by allowing you to place not just event handlers in your HTML, but all kinds of logic, conditions and expressions.

So ultimately it comes down to a personal choice, which means you need to think through the pros and cons for your own situation. To help you, here are my own first thoughts on pros and cons.

PROs

  1. Makes it clearer what your HTML does to a designer
  2. Less code necessary

CONs

  1. Allows a designer to mess your program up just by tweaking the design
  2. You have to look in multiple places to understand what's going on
  3. More code required

For me personally, the first two cons are a big enough deal to make it a bad idea to place clicks inline...but your mileage may vary.

This leaves the question of where to place them. The options are

  1. In a <script> tag in the <head>
  2. In a <script> tag in the <body> - beginning or end.
  3. In a separate .js file which is reference in the same way as 1. or 2.

Again, it all comes down to personal choice. For me, if I was writing a prototype with 20 lines of code, I might just chuck it into a tag in the header. But once it starts to grow, I would almost certainly separate it into a .js file, allowing me to ignore the mark up and just concentrate on the code.

Finally, where to call your script? This AGAIN comes down to personal choice. You have already started to answer your own question - you want your page to be interactive as soon as they are displayed. That makes it a good idea to put your scripts at the top of the page - but that will slow rendering. Putting them at the end of the page would allow the user to see stuff quicker, but have to wait for functionality to be created.

So all this is really a long way to say - it depends. And to be honest, your question shows you already know a lot of the pros and cons, so I would say go with what works for you, and ignore anyone who ever tells you there is a rule.

Toby
  • 1,537
  • 10
  • 19
  • 1
    Funny thing is that people cite all the cons for inline handlers, but then they add classes just for JS to hook up the handler later, which suffers from all the same potential problems. I just don't see much difference between `onclick="foo(event)"` and `class="some_other_class foo_js"`. They both require maintenance to keep things coordinated. –  Jun 06 '16 at 11:59
  • Hold on—I could change my mind! My starting assumption is just that they're bad. If you can convince me they're great, then please! Convince me! – Protector one Jun 06 '16 at 12:03
  • @Protectorone: They're neither bad nor great. They just exist. Use them as you see fit. –  Jun 06 '16 at 12:03
  • 1
    @squint So what do you suggest/use? How do you select the target elements? – Ram Jun 06 '16 at 12:03
  • 1
    @Vohuman: I make decisions based on the situation. If I have a situation where zero latency is very important, I am very open to using inline handlers. My philosophy is don't throw away any tool and use the right tool for the job. –  Jun 06 '16 at 12:05
  • @squint - sorry was saving as I go in case I lost my typing. I've gone on to the question of where to place the code, but I think it's appropriate to start by challenging the original premise that there is an agreed 'best practice' at all. – Toby Jun 06 '16 at 12:07
  • Yep, saw your update, and you're right. Comes down to that the only true "best practice" is to be knowledgeable about the tools you have at your disposal. –  Jun 06 '16 at 12:11
  • @squint Of course, using inline handlers is not a sin. Programming should be flexible. To me, as one, using event attributes is the last possible option. – Ram Jun 06 '16 at 12:11
  • @Vohuman: Yep, everyone needs to set up their own practices that work for them. I too rarely use them, but do find them useful on occasion, and limit them to a single function call. Where they really become obtrusive IMO is when you try to code more complex logic into them. That's where I draw the line. –  Jun 06 '16 at 12:21