Today's reasonably-built JavaScript-based applications are built using HTML as templates. They don't use a <div> as a button, they use a <button> as a button. They don't invent navigation using JavaScript, they use <a> tags and a JavaScript-based router.
Take a look at discuss.emberjs.com, which uses Discourse (which is powered by Ember... INCEPTION):
On the front page, every navigation, including the links on top and the links to individual forum posts, are <a> tags with an href.
When you navigate to a forum post, the buttons to reply, flag, favorite, etc. are all <button> elements.
You definitely want to be (1) using a framework that encourages the use of HTML for the view layer, and (2) using a framework that makes URL-based navigation easy. There's nothing about JavaScript-based applications that make semantic markup and URLs impossible, and today's screen readers don't care whether your HTML was rendered using JavaScript or from the server.
I think you're jaded because the previous generation of frameworks (SproutCore, Capuccino, Ext.js) shunned HTML in favor of all-JavaScript UI toolkits, but that framework style has fallen out of favor. HTML is here to stay.
You're right to point out that the current best practice is to use HTML as intended, including semantic markup for links and buttons. Still, some developers attach mouse and/or touch events to semantically undistinguished elements without providing appropriate markup. For instance, the TodoMVC examples do this (including the Ember.js one). I guess it's time for me to start submitting pull requests.
It looks like the Ember one has three {{action}}s:
1) <button {{action "removeTodo"}} class="destroy"> (a button)
2) <button id="clear-completed" {{action "clearCompleted"}} {{bind-attr class="buttonClass:hidden"}}> (a button)
3) <label {{action "editTodo" on="doubleClick"}}>{{title}}</label> - not a button, but a requirement of TodoMVC. It would be nice if TodoMVC had a <button> marked edit that achieved the same goal.
There is also a subclass of <input>, which:
1) Automatically focuses on insertion (native focuses are properly handled by screen readers)
2) Clears out the Todo if the text becomes empty and the user hits return (somewhat screen-reader friendly, and a requirement of TodoMVC)
Take a look at discuss.emberjs.com, which uses Discourse (which is powered by Ember... INCEPTION):
On the front page, every navigation, including the links on top and the links to individual forum posts, are <a> tags with an href. When you navigate to a forum post, the buttons to reply, flag, favorite, etc. are all <button> elements.
You definitely want to be (1) using a framework that encourages the use of HTML for the view layer, and (2) using a framework that makes URL-based navigation easy. There's nothing about JavaScript-based applications that make semantic markup and URLs impossible, and today's screen readers don't care whether your HTML was rendered using JavaScript or from the server.
I think you're jaded because the previous generation of frameworks (SproutCore, Capuccino, Ext.js) shunned HTML in favor of all-JavaScript UI toolkits, but that framework style has fallen out of favor. HTML is here to stay.