Don't the data attribute options used in Bootstrap, Angular.js, and Ember.js conflict with Unobtrusive Javascript principles? [closed]

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.

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.