CODEWITHSUNDEEP
javascriptjqueryclient-side
retrodrone
retrodrone

Reputation: 5920

What are best practices to maintain separation of concerns when building HTML with JavaScript?

I'm currently learning jQuery by reading jQuery in Action.

The book discusses separation of concerns by using 'Unobtrusive JavaScript.' I grok that keeping behavior specified by JavaScript out of the <body> tree is good form and goes a long way toward maintainability.

However, the benefits of using that approach seems to be negated when looking at dynamic HTML generation with jQuery, such as this example:

$('<img>',
{
  src: 'images/little.bear.png',
  alt: 'Little Bear',
  title:'I woof in your general direction',
  click: function(){
    alert($(this).attr('title'));
  }
})
.css({
  cursor: 'pointer',
  border: '1px solid black',
  padding: '12px 12px 20px 12px',
  backgroundColor: 'white'
})
.appendTo('body');

Here, we're mixing structure (the new <img> element), style (with the call to css()), and behavior (by setting the click attribute value.) So, we no longer have separation of concerns, even though this block is placed in the <head> of the document.

Is my understanding correct? What are best practices to mitigate this? Is it common to refer to external .css and .js resources when doing this type of HTML generation in practice?

Upvotes: 7

Views: 2299

Answers (5)

ezmilhouse
ezmilhouse

Reputation: 9131

Speaking from my experience with jQuery separation is the best way to keep maintainable code and also keep design, content and functionality separate.

Markup

Refering to your example - in most cases markup comes with your html file or is requested by ajax calls.

CSS

jQuery's css functionalities are mostly used in case of onpage manipulation, the original css properties still come via css files.

Events

Usually you maintain a 'bind-section' within your script, where you define all your bind/live events:

$( '.clickable' ).live('click', function(){
   // do something if clicked ...
});

Upvotes: 1

Matt Howell
Matt Howell

Reputation: 15966

The big picture of separating HTML, CSS and JS is that you want your site to be usable (and navigable) if CSS and JS are not available.

For example, if your site depends on JS to load content -- without any kind of "fallback" -- it's broken for anyone who doesn't have JS enabled.

It's perfectly possible to have a full-featured site that uses all the benefits of CSS and JS, but getting them to work together so that the site fails gracefully if your CSS or JS isn't loaded, is a goal worth achieving.

Upvotes: 2

neeebzz
neeebzz

Reputation: 11538

Your missing the point here.

With unobstrusive Javascript the main aim is that in case if Javascript fails to load or execute, how will your application respond? That's the key thing as people have Javascript disabled in many pages, so will your application show any content and respond in a normal fashion or would just go dead?

You can't really separate the View from the Controller but unobstrusive Javascript helps in that direction. But the real benefit is resilience.

Also if you want good abstraction, use KnockoutJS. I cannot really emphasize any less and I can't imagine creating huge websites with great client-side code without a similar library.

Upvotes: 2

Code Maverick
Code Maverick

Reputation: 20415

I think the best practice would be to use classes in jQuery and keep your css in a separate style sheet.

EDIT:

I would also add that learning straight from the horse's mouth works for me. I use http://api.jquery.com/ for almost everything I really need to understand jQuery related.

Upvotes: 3

Zirak
Zirak

Reputation: 39828

Best practice is to use a templating engine (like Mustache.js or jQuery's built in templating engine) and classes, via .addClass.

But at the end, you just can't completely separate the V from the C (View from Controller - MVC), especially in html.

Upvotes: 4

Related Questions