Tight Coupling Between Javascript, HTML, and CSS: A More Modern Approach?

Question

It's very common to see Javascript bound to certain selectors to find elements, store data, and listen for events. It's also common to see these same selectors used for styling.

jQuery (and its selector engine Sizzle) support and promote this by referencing elements with CSS-type syntax. As such, this technique is particularly difficult to 'unlearn' (or refactor) when building out projects.

I've come to understand that this is a result of the history of HTML and Javascript development, and that browsers have been built to efficiently consume / parse / and render this sort of coupling. But as websites become increasingly complex, this reality can introduce difficulties in organizing and maintaining these separate layers.

My question is: can and should this be avoided in modern websites?

If I'm new to front-end development, and I wish to learn things 'the right way,' is it worth learning to decouple and avoid such dependencies from the start? Does this mean avoiding jQuery in favor of a library that promotes a more decoupled structure?

Answer 1

There is no way to avoid that. They are coupled because they interact with each other. If your javascript intends on doing any kind of DOM manipulation, then it needs a way to reference the DOM.

There are various conventions for it.

The Level 2 DOM API provides the getElementById, getElementByTagName, and getElementsByName methods. To this day these are the workhorses of any kind of DOM traversal. All other fancier jQuery selectors resolve into a combination of these eventually, and/or straight up traversal of each DOM node (this was the way to do getByClassName).

There is no other shortcut. Javascript needs to know what to do and where. Typically, if an element has an id or class that is only relevant in scripting, a lot of people will prefix it with js- or some other obvious flag.

Another newer convention is the data-attribute selection.

<ul data-myapp-sortable="true">

jQuery('[data-myapp-sortable]').makeSortable();

The data-attribute is generally used for scripting purposes and selecting using that makes some sense. The drawback is that this is slower than using getElementById().

Another approach is the one used by angularJS, which creates a view-model. In this convention any kind of scripting functionality is specified by specially designated attributes like ng-disabled ng-href and many more. You don't add selectors in your javascript. The HTML document becomes the main authority on what is scripted and how, and the javascript works on it abstractly. It's a good approach, but obviously with a higher learning curve than the previous methods. And again, performance has to be considered.

But don't ever think that you can write interactive HTML and javascript, and somehow have both those parts not know about the other. It's more about how can you limit the references to dependencies.

Answer 2

If you're willing to forego the interactivity that you get, you can avoid Javascript entirely. Frameworks like ASP.NET MVC are very good at serving up pages that only contain HTML, CSS, and a SUBMIT button.

OK. Maybe that's a bit extreme.

Decoupling in a web application already occurs at many levels. REST applications allow you to define your application in terms of "web resources" that are associated with an URL. View Models allow you to present data to the UI that is decoupled from the domain model, but has the shape that you need to properly display it. Service layers allow one UI to be swapped for another, and so forth.

Historically, there's always been a tradeoff between interactivity and coupling. The more interactive your web page is, the more tightly-coupled to the application it's going to be. But the interactivity logic in the web page is confined to the web page itself; any coupling with the server is going to occur through either POST or AJAX. So I'm not sure you should be overly concerned with coupling at the Javascript level, other than paying attention to the way data packets are passed between the browser and the server.

The most "modern" approach (i.e. the flavor of the week) is probably SPA applications.

Answer 3

Martin Fowler describes one approach to this as the Segregated DOM, where you separate your DOM JavaScript from your page logic JavaScript.

Application Logic <----> DOM Manipulation <----> DOM / HTML

Answer 4

No, using class, element, and ID selectors client-side should not be avoided. The syntax is used because CSS selectors are very mature and well-established domain language, and having a common design makes it far easier to share a common logical model of a page between program and design, which is a very, very good thing.

While it is possible to mis-use this syntax and create a terrible and unmaintainable application, such is possible regardless of your language or toolset.

Answer 5

Someone needs to build a jQuery path manager interface for an indirection and cache layer to the dom.

pathMgr.register(name,selector [,isDynamic=false]);
pathMgr.get(name [,refresh]);

Then,

String.prototype.reg([isDynamic=false]);
String.prototype.get(name [,refresh]);

So,

// at init....
var pathMgr=new PathMgr();
'sidebar-links #sidebar a'.reg();// new registery of selector '#sidebar a' under name 'sidebar-links'
// more, more


// in code
'sidebar-links'.get().css(etc...);
//or
'sidebar-links'.addStyleRule({});