Indeed, that is actually how my project (strut.io) does it.
IMO you'd get a better reaction if you put a large chunk of your Plugins page on your main page. The "plugins" page better illustrates the purpose and vision of OJJS. The example on the main page is so low level it turns people off.
That being said, I still think the bulk of the "markup" should be in markup and reside as a template for your "plugin" or component to use.
So you have an EmailView component but with an EmailView template file as well. The EmailView is instantiated and manipulated in Javascript but it still has the benefits of markup via its template file.
Thanks for the suggestion about the plugins. I think you are right they aren't emphasized enough=).
As for separating templating from the View it is a good point. In OJ you can use functions to create templates (or partials) since everything is just code.
I did find the unification of structure (HTML) and code (JS event bindings) quite helpful because this way the code that needs to find the HTML to bind an event is the very same code that created it. This removes the need to have class names / ids just so you can refer across HTML/CSS/JS boundaries.
IMO you'd get a better reaction if you put a large chunk of your Plugins page on your main page. The "plugins" page better illustrates the purpose and vision of OJJS. The example on the main page is so low level it turns people off.
That being said, I still think the bulk of the "markup" should be in markup and reside as a template for your "plugin" or component to use.
So you have an EmailView component but with an EmailView template file as well. The EmailView is instantiated and manipulated in Javascript but it still has the benefits of markup via its template file.
Concrete example: Template: https://github.com/tantaman/Strut/blob/master/app/bundles/ap... Component: https://github.com/tantaman/Strut/blob/master/app/bundles/ap...