We Keep Coding

Using jQuery widget in Dojo

My web app mainly uses Dojo and I'm trying to implement jQuery's select2 (https://select2.github.io/). I read this and I know that it's possible to mix the two together but in my case, everything's built on top of Dojo and it's already a rather large web app. So is it still possible to implement a single jQuery widget into my Dojo based web app?
If not, would I have to go through the source code for select2 and convert into Dojo form?

I don't see why it wouldn't work. As long as there aren't any conflicts, you can use other libraries in conjunction with dojo. Now it may not be built with the AMD like everything else in dojo but it will still work fine.

Creating and reusing custom elements with jQuery vs Polymer vs Dust.js

I've written some widgets to use in my web app, and I'd like to be able to plug these widgets in throughout the app without pasting big chunks of widget code. So far I've been writing custom HTML tags and using jQuery selectors and CSS to populate and style my tags. The end result allows me to write <myTag></myTag> anywhere on a page, and have my custom widget appear.
Recently, I've learned about Dust JS and Google's Polymer Project. My understanding is that Dust would allow me to write a template and "swap out" parts of the template with my content, while Polymer would allow me to create custom HTML tags as I've been trying to do and place them wherever I'd like.
Would it benefit me to use Dust or Polymer? What is the difference between those two options and simply using jQuery to select my tags and plug in my widget/styles? Obviously these are three drastically different libraries/frameworks, but it seems to me that there is some overlap when it comes to my use case. Please correct me if I'm wrong.
Edit: Say I have a plain old HTML page. The question I'm getting at is what would prevent me from using {myCustomWidget} in Dust to "plug in" my widget throughout the app, other than the fact that this may not be standard usage? Similarly, why would I use Polymer to create "shortcuts" for my widgets over using a jQuery selector?
Thanks!

I don't know a ton about Dust, but I've made fairly heavy use of both jQuery and Polymer. Someone with more Dust experience should totally weigh in. It looks like one of the main advantages of Dust is that it's designed for efficient server-side rendering. It's also format agnostic whereas jQuery and Polymer are both specialized for HTML.
Polymer is designed for the use case of creating encapsulated widgets that can be easily reused. It's got a few advantages over rolling your own system with jQuery:
A Polymer element can be imported with one line, and the import will pull in its html, js, and css, and it will register the element within the page.
Polymer has support for data binding, meaning that you typically don't have to write code to ensure that the widget is updated after some data changes. When the data changes, all of the widgets that are interacting with that respond immediately and automatically.
Polymer interops really well with jQuery, so if you've got a site that's doing a lot of jQuery style interaction today you can gradually introduce Polymer elements and they'll play well with the rest of your page. e.g.
$('<my-slider>').appendTo('body') // append the slider widget to the page
$('my-slider').attr('value') // get the current value of the slider
$('my-slider').attr('value', 100) // set the value of all sliders
etc
The styling of a polymer element is encapsulated, meaning that a widget will not mess up the rest of the page with its CSS, and the enclosing page won't mess up the styling of the widget (though the enclosing page can style the widget it has to be fairly intentional, just setting something like * { padding: 5px; } won't throw everything off).
There's great docs at http://www.polymer-project.org/ (and after getting started, I strongly recommend the API docs, they're quite complete and informative: http://www.polymer-project.org/docs/polymer/polymer.html )

I've not used Polymer before but I've used Dust and jQuery extensively.
Dust is simply a template library, just like Handlebars,Mustache, Twig and the myriad of other template libraries out there. It's written in javascript and can be used with NodeJS or can easily run in the browser if you're building client side applications.
Both Dust and jQuery can be used together. Dust would render your HTML templates and as always, jQuery would be used to manipulate them and do whatever else you normally do with jQuery such as listen to events and handle them accordingly.
It's important to note that the two aren't alternatives but rather they work together. Dust cannot do the things that jQuery does and is not meant to. Dust works very well when you have large templates that require partials and blocks.

At its core, Polymer is a platform of polyfills for the current implementation of the WC3 web component recommendation as well as some aspects of ECMA 6 such as Object.observe() and WeakMap. Included in the Platform are the libraries NodeBind and TemplateBinding which enable observable (two-way) custom element data-binding.
Dustjs is an asynchronous logic-less templating engine for client-side and server-side(Nodejs)
rendering. There is no native concept of an observable in Dustjs(as is the case for most template engines), meaning two-way data-binding is outside the scope of the project. However, the PayPal roadmap for Dustjs indicates two-way data-binding may receive official support by the end of 2014.
That being said, NodeBind and observe-js are separate repos not necessarily tied to the Polymer custom element implementation, meaning you can use them in your own projects--which is exactly what I did.
My biggest criticism of client-side rendering frameworks like Polymer (and in some respects, angularjs), is that they are not SEO compatible. So I actually combined NodeBind with Dustjs to make my own two-way data-bound custom element implementation derived from the Polymer platform. The idea is that Dustjs renders the template server-side(or even client-side, if SPA) and then upon rendering, you bind the Dust context to an observable and then parse the template fragment for attributes and keys, binding them to a path observer which maps to the observable. So, the bulk of the task is to write your own parser. The good news is that you can use the Dust parser to help your code. The bad news is that if you want to support arbitrary depths, it is far from a simple task(involves quite a bit of recursion). The other non-trivial task is to support path observer rebinding in the event of model list additions and subtractions.
A final note: Dustjs inheritance offers a superior way to reference your custom elements without relying on HTML Imports and ajax like Polymer.
You can do something like this:
{>my-element}
simply as a partial. And in my-element.html
<my-element>
<ui-template id="my-element-frag">...</ui-template>
</my-element>
this does require a second-step in your build process(grunt or gulp) that requires you to not only compile the external files but to parse your external files for your "template tags" and compile those as separate templates, which can then be referenced by, say, the id attribute(as the template name).

Using a Helper in a Vendor - CakePHP

In my CakePHP app, I am defining a Wizard vendor that outputs the HTML for a multistep Wizard type plugin, along with its relevant Javascript code. I'm wanting to use the JsHelper so that I can buffer my code to the bottom of the page.
Everything else is working, including my Javascript code if I just output it directly with the HTML. I just can't quite figure out how to use the JsHelper. Do I use a App:Uses or App:Import statement? When using it in a View, I can just define it on the controller level, but that doesn't work here.
$this->Js->buffer("
$('.mws-wizard').wizard({
buttonContainerClass: 'mws-button-row',
orientation: '$orientation',
forwardOnly: $forwardOnly
});
");

If you are developing this 'vendor' package yourself, you should not develop it as a 'vendor', but as a plugin.
The vendor folders are meant for including third-party libraries that are not developed with CakePHP in mind (for example to use parts of the Zend Framework in your application).
From the manual:
Note: Loading vendors usually means you are loading packages that do not follow conventions. For most vendor packages using App::import() is recommended.
Create a plugin not a vendor
To develop re-usable code that can be used with different projects/applications, develop your code as a Plugin. Plugins are basically 'mini CakePHP applications'. Classes from a plugin can be used inside your application and vice-versa; a plugin can use CakePHP helpers the same way as you use them in your application.
See Creating Your Own Plugins
Regarding the JsHelper
Contrary to the comment placed by Sam Delaney, your usage of the JsHelper looks fine to me. Adding some script to the Js buffer to output it in the layout seems useful. Just don't try to use it for extended blocks of JavaScript; that should be put in external .js files.
I do recommend to write the JavaScript code yourself and not have the JsHelper generate the code for you (e.g. Don't use $this->Js->get('#foo')->event('click', $eventCode);). This may be personal, but IMO this makes it harder to track/debug your JavaScript and isn't any more readable than just $('#foo').click('event code');

I've personally never found any use for the JavaScript helper in CakePHP as if you're not careful, you end with getting <script> tags littering your markup, which sometimes makes it quite difficult to debug. From what you describe, you have the JavaScript aggregated and appended at the bottom of your HTML so it isn't as bad as the situation I highlight previously.
Is it not possible to relocate all your JavaScript to .js files to encapsulate all the function for your wizard plugin/vendor? If you could do this, it would be in keeping with MVC principles where you could logically separate the view markup and presentation logic.

Using ScriptSharp to code YUI controls

I am in the process of choosing ScriptSharp for coding all my javascripts. I already use JQuery and it is great that there is built-in support for this.
But what about YUI? I need it in particular for the editor control..
How can I code the part for the editor control within Script# framework? Is there a place to enter custom javascript when a certain library is not supported or something similar?
Are there any future plans to add YUI to ScriptSharp?

It would be interesting to have YUI support, but there aren't specific plans to add support for it right now, at least not at the top of the priority list.
However, if folks in the community want to get it going and contribute, I can help with questions that come up.
The general idea is you create an import library (there is an Import Library project template when you install Script#), which defines a c# API corresponding to the OM that you program against. The C# API consists of classes and stub methods that define the signatures (think of this as a header file of sorts). There are a few metadata attributes to customize generation of script that references those APIs to get various transforms to happen ... so you can create a working, and often times more natural c# interface that then maps to runtime script constructs and APIs you are targeting.
When I see the sample at http://yuilibrary.com/ I see a bunch of parallels to jQuery, so I imagine building support for it is likely possible at a technical level.
The best way to understand how to do this would be to look at the sources of mscorlib.dll (represents the core script objects) Script.Web.dll (represents the DOM) and Script.jQuery.dll (represents core jQuery API). All of these are in the Script# repository on github ... https://github.com/nikhilk/scriptsharp ... if you haven't already seen them.

We are creating an import library for OpenLayers (http://openlayers.org) and I can say it is incredible easy to do. We started just doing what NikhilK says, inspecting the source code. The results are just great. YUI is a very well designed and documented api, so I think it would be stratightforward. You could just create the import clases you need for your project.

Can jQuery be used with Ext.js?

After reading some of the jQuery vs ext js questions here and google search result, my understanding is that ext js is a UI building library and jQuery is a more fundamental javascript framework. I've used jQuery for a while now. It's pretty cool but in general a better (much better) javascript.
So my question is: how easy is it to use jQuery for DOM navigation/manipulation and Ext.js for UI in the same project?
There is a page on jQuery website. But the demo is too simple and the external links to Ext.js are all dead.
I'm sure it's possible, but what sort of problems and challenges would I be facing?
You might be wondering why I want to do this. Well, the Ext.js set of UI just looks much better/more polished/more feature rich then jQuery UI. I'm particularly interested in the grid.
Thanks!

Using both libraries side by side is not an issue in the technical way (just add the jquery within a script-tag, that's it!). However, you should not use jQuery for ExtJS' stuff or vice versa. Well, unless you know exactly what you do.
The actual issue can be DOM manipulations (jQuery or ExtJS Core) outside of an ExtJS component that affect an existing component.
So, in a nutshell: You can use DOM manipulations when it will not affect the ExtJS components. Otherwise use the proper way within the component itself.

Well you dont need both the libraries to live together.. Extjs has DOM manipulation api too probably not as vast as jquery but it does have the basic stuff.
Coming to Jquery, jquery has UI building APIs too if not rolled into the library there are vast no of extensions for all kinds of problems. Just try googling whatever UI you are building now with respect to jquery and you will find a library for sure.. There is jquery templates too that lets you generate HTML markup from a template defined by you and applying data objects (json) to it.. Jquery has a vast community too so most of your questios or concerns will be addressed by the community almost instantly..
So yea my suggestion would be to choose one library and stick to it and contribute to the library if there are many missing features..
Lastly I would suggest you choose Jquery.. It rocks.. period..

I think you would have no problem do this stuff... Make Ext.js your main jQuery library and jQuery as the data manipulation library for the DOM.
There would be no problem or conflicts because jQuery is compatible with other javascript libraries.