Is there a plan to permit or a way to make JQ accessible in UXP?
Fully aware it’s not currently supported
But it’s a very useful in a lot of situations.
What use cases do you have for it?
1 Like
I assume this:
Except it’s the other way around, IMHO - anything JS can do JQ can do
As I mentioned on that topic, it’s been ~10-15 years since I personally had a need for JQ 
Maybe there could be some edge cases, but most JQ functions can be done with vanilla JS functions or at least couple of lines. Much more lightweight that having JQ
For one I’d suggest trying a newer framework like Svelte, React, or Vue, but sure lots of people still use jQuery for various use cases, it’s been around forever.
I doubt it’s ever going to get full UXP support just like JS HTML DOM methods are never going to get full UXP support. It will probably be on a case by case basis, some functions will work, others won’t.
If you really want to use jQuery in UXP, maybe try it and see what breaks. If too much breaks and you really need it for your UIs, consider moving your UIs into a webview which has full web tech support.
1 Like
My only interest in it is concise and efficient code. I don’t believe JS alone offers the ability to generate DOM elements – where you apply attributes, properties, styling, listeners etc in one short block.
The equivalent in JS is always possible but more long-winded, particularly when it comes to attributes, properties, and css. JS requires a lot of repetition
element.className=“various classes”;
element.setAttribute(“placeholder”, “default text”);
element.style.width=a;
element.style.height=b
element.style.display=c;
where JQ takes a JSON objects:
$(“”)
.attr({class:“various classes”, placeholdr:“default text”})
.css({width:a, height:b, display:c})
Just there alone 5 longer lines of JS condenses to 3 lines of JQ. The details you add, the greater the savings.
Who knows. Maybe there are JS equivalents that are just as tight that I’m not aware of. If I find 'em I’ll gladly switch, but JQ is mighty swift.
The main need for Panel Extensions (and presumably UXP) is the rapid development of code. I work with large teams that need customized automation fast – build in the early morning, be in use by late morning, refine and improvise for a week, and remain stable over the coming weeks and months.
A typical system might log, even transcode, thousands of media items to a remote database and then make those lists available and interactive on the front end all from within Premiere. Whether that interactivity involves logging, click-to-play, click-to-assemble, writing metadata – whatever is needed in the moment.
React is less appealing to the extent it burdens the server. The goal of using JQ is to offload processing load to the front end. Happy to elaborate if it’s helpful, but JQ would be very much appreciated.
If you try to load JQ in UXP, it breaks completely. You get an error – a stack overflow. When loading JQ in an PPro Panel it works just fine.
How about…
Object.assign(element, {
className: 'various classes',
placeholder: 'default text',
style: "width: a; height: b; display: c;",
onclick: function () => alert('Clicked!')
})
Would that work?
2 Likes
Yea you’d need to drill down and figure out what method is missing not working right.
Have you tried Svelte, React, or Vue? I think you’d like it, makes things like this way more straightforward with less repetitive code to update values, styles, state.
I used jQuery for websites before but I don’t it fits well need you described. Once you get used to React (or Vue) you will not miss jQuery. The state management and component updates are much easier to do and maintain. But it needs more setup for sure than React.
You don’t need to have React on server. You can ship it with a panel. Make single page application.
E.g. you can check Alchemist GitHub - jardicc/alchemist: DevTool for plugin developers
Whole UI is written in it. (But it uses older class syntax and would deserve a clean up) 
Oh cool, that’s the kind of vanilla JS alternative I was half-dreaming might exist. Thank you for sharing! Will begin testing.
What about .animate? Is there something as clean in vanilla JS?
What’s great about JQ is it’s a simple library, no installation necessary.
What would be better still – per @Karmalakas – is full vanilla JS alts.
Per your suggestion I’ll check out React & Vue, if I’m ever am afforded the free time.
Not sure what’s .animate in this case 
This should work:
Object.assign(element.style, { opacity: 0 })
element.animate( [{ opacity: 1 }], { duration: 2500});
More info here
Just have to say, at least Photoshop UXP doesn’t support animations
1 Like
No such work is planned or scheduled.
Fascinating. @Karmalakas thanks again for sharing.
It looks like .animate is not available in Premiere as well.
From what I can tell so far vanilla JS approach is a little less elegant than JQ.
In JQ you can control just about every aspect of a DOM element using a succession of .dot methods – very clean, very efficient. The vanilla JS approach can’t quite achieve that because of anomalies associated with CSS, animate, and event bindings. It’s close but not quite there. Effectively JQ wraps those anomalies and says, here they are, tighter, more efficient.
I just did a little test to see how hard it might be to replicate that wrapping without JQ, and was surprised how few lines of code it took – about 36 to handle JQ’s .attr, .prop, .html and .css methods. Event handling and animation would be a little more involved. And in UXP animation doesn’t seem possible at all so…
… @bbb_999 feature request please consider adding support for JS .animate in UXP
Requesting support – or at least finding a way to permit developers to add it without the resulting error that currently triggers.
JQ is just a wrapper for already-existing JS commands, as opposed to libraries like React, Vue.js etc which are full blown libraries requiring installation. If need be I’ll re-write equivalents for missing JQ methods, but I’d prefer not to.
I’m aware of the cautionary Keep in mind that UXP is not a browser, but seems more accurate to describe it as a browser with various features turned off. Getting a better handle on what that means. The need for security I understand, but I’m seeing even is not exactly supported, which seems a bit OTT.
If your main goal is to cook as much plugins as quickly as possible and they are just simple single panel and single view, then probably it is efficient and best solution 
But I will still leave this nice and easy to consume comparisson here for you 
Not trying to convert you - I believe JQ still has its use cases, but I personally don’t feel it’s a good thing to sacrifice performance over development speed. Unless you don’t like your clients/users and never have to deal with them 
So here I’ll disagree with you. It depends on how you use the tools.
On the link you posted above, the characterizations in the JQ column are IMHO inaccurate.
Some examples:
-
“Manual updates to the DOM” - Not even remotely true. You code your front end to update by any means of your choosing, automated or manually, using ajax or websockets, no user interaction necessary, any user interaction possible.
-
“Slower for complex applications” - Imagine an adobe front end that queries a remote database of logged media entries, loads 10,000+ rows into the DOM (forget about “load next 10 items” ), all rows interactive. One of our apps allows you to edit, sort, and filter those entries, based on an ever-evolving customization terms (we typically customize and update the features/options of the UI throughout the course of a given project as needs evolve). It features a click-to-auto-assemble timelines based on any number of algorithms invented on-the-fly. It’s not uncommon to drop 300 - 500 short clips into a timeline as an auto-assembly. The clips themselves are imported into Premiere automatically, proxies and/or original media. This approach literally replaces the need to use Adobe’s project panel. The search-and-sorts, are instant even for thousands of items, far outpacing Premiere’s native UI. Menu items at the top of the UI allow it to instantly transition from a list of clips, to a dynamic interactive display of the show’s script, which is also interactive with click-to-view dialogue. This approach even out-performs by far Avid’s ScriptSync. Complexity does not slow things down.
-
“Can be harder to manage in large apps”: That’s up to the developer. We typically develop a solution in the morning. It has to be operative before noon. Our standard return on that morning coding session is 5x efficiency – same day. That code has to endure long-term, port from show to show, without ever shutting a show down. Contexts are: Reality, Fiction, Trailers, and VFX workflows (which are the most complex)
-
“Large file sizes using JQ”: False. No matter the complexity, not a single project goes above 1MB. Only library dependency: JQ. (And perhaps thanks to your insights, we’ll even begin migrating toward dropping that)
The presumption that JS/JQ is only valid for snippets of code is a misunderstanding that goes way back to the 90s. In fact you can build entire front ends – developed quickly, maintained and improved efficiently, and with reliable years-long endurance using font-end JS alone – no static HTML. The UI robustness and speed outperforms just about anything out there.
If a front end JS-based app is sluggish in the slightest, there’s something wrong with the code, not JQ.