36

I've always been told it's good practice (ala 'unobtrusive javascript') separate JavaScript from HTML markup. However, I've been seeing the opposite trend with a number of new and popular frameworks such as Bootstrap, Angular.js, and Ember.js. Can someone tell me why this isn't considered bad practice?

sdellis
  • 531
  • 4
  • 8
  • 3
    I agree with you and think that it is indeed bad practice. The same goes for most CSS "frameworks" that suggest using class names such as "left-col" "span-3" etc etc which are directly related to the design. jQuery Mobile is also bad in this aspect and requires you to use several data-attributes to style a button (for example). – powerbuoy Oct 19 '12 at 16:31
  • I tend to agree, but grid systems can be useful, and I don't see any way around those types of class names when using a grid. – sdellis Oct 19 '12 at 20:13
  • 1
    Bootstrap can be used as LESS and with LESS you can use the full grid system (and more) of Bootstrap without touching the markup. – Piedone Jul 13 '13 at 16:07

2 Answers2

27

Unobtrusive Javascript is a good practice for many places on the web. The frameworks you mentioned are often used for creating full-blown Javascript applications. In many of these apps, the experience without Javascript is often a blank page. In that environment, the value of separating your markup from Javascript is relatively low.

Luke Melia
  • 8,389
  • 33
  • 41
  • 2
    I think you've basically answered the question. Certainly some of the functionality I'm looking to build is simply not possible without Javascript, but that doesn't mean the site should not function with it disabled. Then again, I also need to determine the population of potential users who have javascript disabled to see if I should care -- screen readers can generally deal with Javascript pretty well these days, so it's not really an accessibility issue, but rather a preference. – sdellis Oct 19 '12 at 20:23
  • More generally, I think the idea is that code that is fundamental to the view can/should logically be included in the markup. So while you want to keep complex business logic out of the html, including javascript that declares how the interface itself functions makes sense. – Nathan Stretch Oct 26 '14 at 02:33
19

I'm asking the same question myself and have come to the following conclusion:

HTML is markup language for presenting documents. The semantics that everyone is referring all around is actually related to representing rich documents. This includes images and links that allow more richer experience. The same principles can be applied to Word documents, where instead of marking a specific text as red, you can mark it as emphasis and then style the emphasis as red, which will be semantically correct way to express the intend.

The problem arises because HTML actually includes elements that allow user interaction - forms . The initial design was to allow non professionals to create simple interactive UIs. When I checked different desktop GUI frameworks there is no such thing as separation between actual view and view logic, because when you build GUI you don't need that separation.

For me the importance is how much of what you writing is content based or GUI based. Because the HTML serves two purposes it's difficult to know what to serve from the server. Basically sites like Wikipedia, and even Stackoverflow are content oriented. This means that if they want to be accessible to broader range of clients, like bots and older browsers they should be able to stream pure html. I'm thinking of two possible strategies when you want to provide content and some richer UI experience, like the textare where I'm writing this comment. The one is to server the html and then initialize the GUI. This is also referred as unobtrusive javascript and semantical HTML. This is what most content oriented sites do. This is mostly to be able to benefit from browsers and bots that will allow their content to be more accessible. The other strategy will be to identify the type of client and serve different content, which can only be achieved reliably only on the client side, because in both cases html will be served. This is still close to the first stategy, because of the way HTML is used/abused as both content and GUI representation.

If you are writing an application that don't provide content but actual service/process then architecture like AngularJS and similar is suited better.

In my experience most business have to provide both. Let's say you have an app that uses HTML/Javascript to allow users to create drawings. This app doesn't need to follow any unobtrusive guidelines, but it won't be able to run on old browsers too. But if you provide a social sharing of the drawings between users, allowing comments and other content then it's better to write this part of the site in a way that bots and other clients can access the content easily.

edzhelyov
  • 399
  • 2
  • 6
  • 2
    Agreed! It's about Content Pages vs Interactive Apps. Content Pages should be unobtrusive so the content is immediately accessible (then enhanced by JS). Interactive Apps can be more tightly coupled as the 'App' must be fully loaded and interactive before it is useful (so, separation is not necessary). – Jess Telford Apr 29 '13 at 05:42
  • 2
    Actually, forms are also semantically meaningful. They represent an action or a query which an HTTP server will accept at a particular resource. The display of a form is presentation, but the markup is content. For instance, an application could be instructed read the form and submit it without understanding how a browser would display it graphically. This is one way of specifying an API over HTTP, and it's in the realm of hypermedia APIs. – Peeja May 25 '13 at 17:28