4 ms·

AJAX developers continue migrating to unobtrusive JavaScript

15 points by ajbatac 18y ago

deleted 18y ago
[deleted]
wenbert 18y ago
jQuery FTW
- axod 18y ago
  Do it yourself FTW
  - DanHulton 18y ago
    Man, YOU write jQuery's selectors yourself. Maybe you even could, but why would you want to? jQuery's the most excellent basic "toolkit" javascript product I rely on.
    - axod 18y ago
      Why do you need selectors like that? just give things IDs if you need to reference them... Oh well :) Maybe I'll try a javascript library properly one day.
      - DanHulton 18y ago
        What if you wanted to get an array of all the table cells in a particular table? $('#tbl-order td') versus - Getting the table - Getting the table body - Getting each row - Getting each cell Much simpler. It's cool though, I dismissed it until I tried it too. It's a real eye-opener how much easier things are using jQuery's selectors.
        axod 18y ago
        If you want to get an array of all the table cells in a table, you're probably using the DOM to store data, instead of display data, which is bad IMHO. I prefer having the data in js, pointing to nodes in the DOM, or containing IDs that may need adjustment, updating.
        DanHulton 18y ago
        Or you're adding rollover events to the table, or styles to the table. Also, the DOM's not a bad place to store data. Why duplicate it elsewhere if it's already in-place in a table? This allows you to say, gracefully upgrade your simple HTML table to a YUI DataTable if your user has javascript enabled.
        axod 18y ago
        That's like using a video cards display ram to do inter process communication, or store other program data. Sure though, if you want to add things to a table once loaded to be unobtrusive I can see that use. Although then I'd say just give them sane IDs, and have a js array with the IDs you need to update.
- riklomas 18y ago
  You can make just as obtrusive Javascript using jQuery as much as you can with any JS library, the point is that you should be doing unobtrusive Javascript. If you don't know how to do unobtrusive JS, I would recommend DOM Scripting by Jeremy Keith: http://www.amazon.co.uk/DOM-Scripting-Design-JavaScript-Document/dp/1590595335/ http://www.amazon.co.uk/DOM-Scripting-Design-JavaScript-Docu...
mojuba 18y ago
It's not obvious at all that "unobtrusive" coding has advantages. First of all, the line between HTML and what they call "behavior" is vague: many, if not all, presentation elements contain built-in behavior of some or other form, for example take any form element. JavaScript code that we write extends or customizes this behavior, rather than creates it from scratch. Second, when we read raw HTML it's better to see explicitly that the behavior of a given element is customized. Even a small hint of customization in a form of a function call from within onClick, for example, would be a sign that a given element is different from the standard one. Finally, less code always means easier to understand and easier to debug. There is no excuse for writing more, no matter how you call your technique, if there exists a simpler and clearly more concise way of implementing the same functionality.
- DanHulton 18y ago
  Damnit, there's no reason to downvote this man. He may not be right, but he's not detracting from the conversation. A rebuttal: Unobtrusive coding has many clear advantages - not the least of which is the fact that your js files can be cached, increasing the loading speed of your app. And more code in, say, a library can mean less domain-specific code that has to be maintained, making your app easier to understand and debug. I use YUI, jQuery, and the module pattern to create surprisingly concise and easy to understand js files. They're pretty much all cacheable, they're easy to read, and most importantly, related things are all in the same place. This is actually kind of key for debugging. If you want to find out where the function call attached to a dropdown's onChange event, you check the YAHOO.Company.page.init() function. That's just where it is. You don't have to sort through reams of HTML to find the dropdown. This is better still if you have a function that prints multiple instances of that dropdown - the events are all attached, line-after-another in the js file, not hidden in a function somewhere in a different language. Certainly there's downsides to it, but there's a lot to gain.
  - mojuba 18y ago
    I should have made myself clear: I'm not against moving JS code to a separate file and I understand the benefits of caching. My point is, some hint of change for a given element must be given where it's declared, for example as a function call in onChange. This function itself can be defined anywhere, preferably in a separate file. Why - because when building a web app you usually look at the page and decide to modify the behavior of an element. In a good WYSWYG editor it's just one click, and you see that there's custom code attached to one of the events of that element. With "unobtrusive" style it's not obvious at design time whether an element has standard behavior or not, unless you know the code well, I mean, every bit of code in all modules.

15 points by ajbatac 18y ago

deleted 18y ago

[deleted]

wenbert 18y ago

jQuery FTW

axod 18y ago
Do it yourself FTW
- DanHulton 18y ago
  Man, YOU write jQuery's selectors yourself. Maybe you even could, but why would you want to? jQuery's the most excellent basic "toolkit" javascript product I rely on.
  - axod 18y ago
    Why do you need selectors like that? just give things IDs if you need to reference them... Oh well :) Maybe I'll try a javascript library properly one day.
    - DanHulton 18y ago
      What if you wanted to get an array of all the table cells in a particular table? $('#tbl-order td') versus - Getting the table - Getting the table body - Getting each row - Getting each cell Much simpler. It's cool though, I dismissed it until I tried it too. It's a real eye-opener how much easier things are using jQuery's selectors.
      - axod 18y ago
        If you want to get an array of all the table cells in a table, you're probably using the DOM to store data, instead of display data, which is bad IMHO. I prefer having the data in js, pointing to nodes in the DOM, or containing IDs that may need adjustment, updating.
        DanHulton 18y ago
        Or you're adding rollover events to the table, or styles to the table. Also, the DOM's not a bad place to store data. Why duplicate it elsewhere if it's already in-place in a table? This allows you to say, gracefully upgrade your simple HTML table to a YUI DataTable if your user has javascript enabled.
        axod 18y ago
        That's like using a video cards display ram to do inter process communication, or store other program data. Sure though, if you want to add things to a table once loaded to be unobtrusive I can see that use. Although then I'd say just give them sane IDs, and have a js array with the IDs you need to update.
riklomas 18y ago
You can make just as obtrusive Javascript using jQuery as much as you can with any JS library, the point is that you should be doing unobtrusive Javascript. If you don't know how to do unobtrusive JS, I would recommend DOM Scripting by Jeremy Keith: http://www.amazon.co.uk/DOM-Scripting-Design-JavaScript-Document/dp/1590595335/ http://www.amazon.co.uk/DOM-Scripting-Design-JavaScript-Docu...

mojuba 18y ago

It's not obvious at all that "unobtrusive" coding has advantages. First of all, the line between HTML and what they call "behavior" is vague: many, if not all, presentation elements contain built-in behavior of some or other form, for example take any form element. JavaScript code that we write extends or customizes this behavior, rather than creates it from scratch. Second, when we read raw HTML it's better to see explicitly that the behavior of a given element is customized. Even a small hint of customization in a form of a function call from within onClick, for example, would be a sign that a given element is different from the standard one. Finally, less code always means easier to understand and easier to debug. There is no excuse for writing more, no matter how you call your technique, if there exists a simpler and clearly more concise way of implementing the same functionality.

DanHulton 18y ago
Damnit, there's no reason to downvote this man. He may not be right, but he's not detracting from the conversation. A rebuttal: Unobtrusive coding has many clear advantages - not the least of which is the fact that your js files can be cached, increasing the loading speed of your app. And more code in, say, a library can mean less domain-specific code that has to be maintained, making your app easier to understand and debug. I use YUI, jQuery, and the module pattern to create surprisingly concise and easy to understand js files. They're pretty much all cacheable, they're easy to read, and most importantly, related things are all in the same place. This is actually kind of key for debugging. If you want to find out where the function call attached to a dropdown's onChange event, you check the YAHOO.Company.page.init() function. That's just where it is. You don't have to sort through reams of HTML to find the dropdown. This is better still if you have a function that prints multiple instances of that dropdown - the events are all attached, line-after-another in the js file, not hidden in a function somewhere in a different language. Certainly there's downsides to it, but there's a lot to gain.
- mojuba 18y ago
  I should have made myself clear: I'm not against moving JS code to a separate file and I understand the benefits of caching. My point is, some hint of change for a given element must be given where it's declared, for example as a function call in onChange. This function itself can be defined anywhere, preferably in a separate file. Why - because when building a web app you usually look at the page and decide to modify the behavior of an element. In a good WYSWYG editor it's just one click, and you see that there's custom code attached to one of the events of that element. With "unobtrusive" style it's not obvious at design time whether an element has standard behavior or not, unless you know the code well, I mean, every bit of code in all modules.