I’m back on the UXP wagon after an extended break and I’m pleased to report that it’s shaping up nicely in the year since I’ve been actively developing!
That said, despite having a nice Webpack/React workflow in place my biggest development bottleneck is the lack of parity between UXP and a browser, particularly in terms of CSS.
So much development time is wasted chasing down errant properties to find that they haven’t been implemented, or getting all jiggy adding some nice React UI to find it doesn’t work because there’s a window method missing.
Whilst I’m no wizened web dev grognard, I know enough to debug a funky CSS property and try and find a workaround, but I can see it being a massive barrier to entry for greener devs.
I speak from deep personal experience that Adobe scripting is a fantastic gateway drug into the rough and tumble of the wider JavaScript ecosystem, and I think that at the moment UXP still presents some real challenges to novices.
Don’t get me wrong, mandem still need to go and learn basic JS/HTML/CSS first, but it’s a bumpy ride doing that and then entering a development environment that is so unpredictable and often obtuse in what it can and can’t do (and I’m not talking about grain vs green here).
This is exacerbated when using a utility class library. For example, I use UniformCSS) - I’d prefer to use Tailwind, but I can’t get it to work, ditto any React drag and drop library. From what I can tell this is down to missing CSS and/or window methods.
Enough of me arguing my case; my questions are:
• Is the plan for full parity with modern browsers?
• If so, is there a ballpark E.T.A. on that?
• if not parity, what is the intended end state for UXP CSS?
I apologise if this is retreading ground covered in Office Hours meetups - as a UK dad of two young children they always fall at that most fatal dinner/bath/bed time
TBH, when I was developing my plugin, CSS was probably the most painful part. And I’m a web developer, who knows CSS, and still spent weeks just on writing workarounds on styles.
It’s one thing when you don’t know how something works and you spend time on learning. Another thing when you know this works even on IE6, but not on UXP and usually it’s not even documented properly.
Currently we have two lists basically - what works on UXP (docs) and what doesn’t (known issues), but nothing about what’s not mentioned in these lists
In fact, much of my work consists of finding workarounds. I recently implemented a fairly complex drag & drop functionality (within the panel) myself and it was very tedious.
No React drag & drop library worked, so I had no other choice. My solution is probably not perfect either, as there is a lot to consider with good drag & drop, even in the browser API. It was a great challenge and I dare say I know JS and UXP quite well.
@tomzag I too have implemented HTML drag and drop after failing to get any library to work (I’m looking at you window.scrollTo) and without transition it’s clunky as hell
I agree about the difficulty. but after reading docs and seeing relevant topics on the forums I came to the realization that this is by design.
the vision is that UXP is not a browser nor it’s trying to be. and eventually the plan is to support less and less generic CSS and rely solely on Spectrum elements (according to something I read in the docs) so unless the vision changed you’re better off looking up what’s supported rather than what’s not.
I see what the team is trying to do and most importantly what they’re trying to avoid but maybe a middle ground can be achieved in future updates.
@Maher I’d love to see the bit of the docs you speak of that suggests less CSS support in future versions (I can’t find it).
SWC is all well and good, but at the moment (and since launch) we’re stuck in a halfway house where we have neither approach fully realised and that’s bad for development.
I use SWC, but I’m often finding that I have to do stuff I haven’t done for a long time - spacer divs instead of gap? Or hard-coding styles to elements with React rather than have good CSS (:not:last-child). I don’t have much desire to change SWC stylistically, but I would like to lay them out without a load of hacks.
The lack of animation/transition classes really makes for very lumpen and clunky UI, especially as previously mentioned, if one wants add interactivity such as drag and drop.
I remember this being mentioned maybe here in the forum at the very beginning of UXP, when it was just recently introduced. Won’t be searching for the post now, because I’m not even sure if it was forum or maybe even one of the live sessions But yes, I remember it was said, that we should try to rely on UXP supported features and avoid hacks, because they might stop working at any time, which would be very unfortunate for lots of developers, because there was (and I’d say still is) no way to develop a proper plugin without hacks
I have some work in progress to give you guidance in VSCode. It parses CSS, LESS and SASS into an abstract syntax tree and compares CSS features against the specific UXP version.
But currently, I do have not time to work on it and work on paid projects instead. Also, the lack of documentation makes it harder. I was thinking about a Patreon campaign but not sure about the potential… I was thinking once Illustrator, After Effects, and Premiere are full in UXP it could get a wider user base.
• Is the plan for full parity with modern browsers?
Nope. In my understanding, that’s never been the end goal and I’ll be very surprised if it ever happens.
• If so, is there a ballpark E.T.A. on that?
Like never, plus one day
At the moment, if you want to enjoy a real Browser environment, you can develop Adobe Express add-ons.
• if not parity, what is the intended end state for UXP CSS?
I don’t think there’s an “end state” as such; there are progressive additions/improvements driven by internal requirements and external requests, which can be integrated (or not) depending on their value vs. overall development cost. If/when they play along well with the platform’s current objectives.
I have no idea whether CSS is a priority for the UXP team now, I’ll leave that to the PMs. I would think, though, that the recent introduction of SWC has brought some extra properties support. @Jarda might know better, as he’s spent some time tinkering with CSS lately.
Keep in mind that UXP is not a browser. It’s a platform that provides the ease of using web technologies to build plugins/scripts for desktop applications. Hence, it does not support all the HTML/CSS capabilities you can use in a browser. In fact, the tags that are not supported are treated like simple <div> .
Prepare for the future - Spectrum UXP components will become the only supported user-interface controls in UXP in the future. Prepare now by using them instead of the HTML correlates
It’s not so much the lack of the CSS, but moreover the frustration at UXP’s CSS support being so opaque.
At the risk of sounding facetious, one hand we’re told that we shouldn’t use anything but supported Spectrum components and that workarounds should be avoided, but on the other hand we’re often left with no choice but to use workarounds to achieve quite basic design/functionality.
Sure, this has been the way of Adobe scripting since time immemorial, but everything else about UXP has been a great step forward and has hugely improved developer experience so this feels like a bit of retrograde step.
From the quotes provided by @Maher I interpret that at least to mean that the ability to use HTML tags will disappear, but not extant CSS, which I hope is the case. The loss of HTML tags matter not to me, Spectrum generally does the job fine in that respect; I’d just like more control over the laying out and display of those SWC.
Ultimately, I think that Adobe’s choices and our frustrations both stem from the same place - we want to build robust, beautiful plugins that are intuitive, enjoyable to use, and perhaps more importantly, that people want to purchase, but I think that we’re being a little bit stymied at the expense of what I’m not quite sure.
I have no idea of the complexity and technical challenges presented by adding CSS to UXP, but I don’t presume that it’s by any means a triviality for Adobe, and nor do I wish to come across as angry and resentful (far from it, I love UXP!) - I just struggle with the “not knowing”.
It’s one thing to have to revisit old work when the API changes (e.g. the switch to API 2/Manifest 5), it’s another thing to be worried that a hack for a flex gap is going to fall over.
But yes, I remember it was said, that we should try to rely on UXP supported features and avoid hacks, because they might stop working at any time, which would be very unfortunate for lots of developers, because there was (and I’d say still is) no way to develop a proper plugin without hacks
