Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've been reading articles such as this one that indicates web development has evolved to use JS frameworks. Where I work, we have a massive website with many existing web applications that are already established and are server side heavy.

One article I read said that the DOM manipulation/jQuery method leads to unmaintanable spaghetti code, and that you should strive to use a JS MV* framework. However, sometimes I just have a fairly simple list of items generated from the server; something like:

<div class=shower data-id=1>show</div>
<ul><li class=hider data-id=1>one</li></ul>
$(".shower").on("click", function () {
    $(".hider[data-id=" + $(this).data("id") + "]").show();

...and that would pretty much be the extend of the JS on that page. According to the MV* framework disciples, the need to reference specific classes or attributes in the JS is a problem and models should be used instead. However, it seems like overkill to include a massive library for creating rich applications to handle some fairly trivial DOM manipulation and animations.

Is there a JS framework in existence that bridges the gap between complete front-end stack frameworks and tightly coupled HTML/JS? If not, how could I write such code to avoid this coupling?

Additionally is there any reason to push strongly for making the switch to such a framework for established server-heavy applications (especially in cases where we have to support JavaScript being turned off)?

share|improve this question

closed as not constructive by gnat, Dynamic, Yusubov, MichaelT, Kilian Foth Jun 12 '13 at 6:22

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

up vote 2 down vote accepted

The author of the article you linked seems to have forgotten about server-side HTML generation completely. You don't need all that JS ceremony to create a data-driven web page; the JS is there to augment the page, not generate it.

That said, none of these JS frameworks is all that large. "Massive library" is a mischaracterization. I suspect that if you make the attempt to write such code to avoid tight coupling, you'll be reinventing Backbone/Ember/Angular anyway.

If you're genuinely worried about the library size, use Resig's Micro-Templating, which weighs in at about thirty lines of javascript. Alternatively, you can get a custom-tailored recommendation for a JS framework at one of the links below.

See Also

share|improve this answer
So you think it would be worth investing in choosing and using a particular framework consistently even in trivial cases above? I have read tutorials who assert that such would be overkill for an application that's already server-heavy. – Explosion Pills Jun 11 '13 at 21:11
I essentially made the same assertion in the first paragraph of my answer. – Robert Harvey Jun 11 '13 at 21:12
So when you are writing JS-augmenting code rather than actual HTML generation/data-bindings is it okay to have a coupling of DOM and JS symbols or should it still be avoided (or can it?) – Explosion Pills Jun 11 '13 at 21:13
That coupling is sort of the raison d'etre of Javascript, is it not? Unless you're trying to build a generalized JS library, I wouldn't be too worried about coupling JS with the DOM. Actually, the way you avoid tight coupling is by referring to CSS classes instead of specific DIV's. – Robert Harvey Jun 11 '13 at 21:16

Not the answer you're looking for? Browse other questions tagged or ask your own question.