Question about JQuery library in SAPUI5

[Former Member]

Hello,

The latest SAPUI5 release is bundled with JQuery 1.11.1 from 2014.

How often is JQuery library updated in SAPUI5?

Is there a roadmap for JQuery library updates in SAPUI5?

Is JQuery library shipped with SAPUI5 modified in any way or it is the original copy from JQuery Team?

Best regards,

Boulat

[AndreasKunz · Accepted solution]

Hi Boulat,

jQuery 1.11.1? Which UI5 version are you looking at?

As you can see in the history of the commits of the thirdparty/jQuery folder (https://github.com/SAP/openui5/commits/master/src/sap.ui.core/src/sap/ui/thirdparty/jquery), the current version is jQuery 2.2.3.

However, this was a recent change and the currently released version of SAPUI5 is still using 1.7.1 by default:

https://sapui5.hana.ondemand.com/resources/sap-ui-core.js (see comment close to the top)

The standalone file is here: https://sapui5.hana.ondemand.com/resources/sap/ui/thirdparty/jquery/jquery-1.7.1.js

1.8.1 is already contained but not default:

https://sapui5.hana.ondemand.com/resources/sap/ui/thirdparty/jquery/jquery-1.8.1.js

These files are not modified, but directly taken from the jQuery project.

You can even use the UI5 core with a plain jQuery you already loaded into the page (e.g. if you need a newer version with a fix) by using this version of the UI5 core, which excludes jQuery:

https://sapui5.hana.ondemand.com/resources/sap-ui-core-nojQuery.js

But we can only guarantee compatibility with the jQuery versions shipped with UI5.

Regards

Andreas

[Former Member · Accepted solution]

Hello Andreas,

I checked jQuery version used by SAPUI5 1.36.7 Demo Kit hosted here https://sapui5.hana.ondemand.com/

The version returned is 1.11.1

Best regards,
Boulat

[pmuessig · Accepted solution]

Hi Andreas et al,

Basically the included UI5 version is the original jQuery package coming from jQuery.org – no modifications.

With UI5 1.38 we are upgrading from jQuery 1.11.1 which was long time our standard jQuery version to jQuery 2.2.3. As we need to verify that a new jQuery version doesn’t harm our framework + controls we need to plan such a jQuery upgrade safely. But the main point for the long delay of the jQuery migration to newer version was that we were relying on jQuery 1.x and for the migration to 2.x additional work was necessary.

Additionally to mention - starting with 1.38 we are removing old jQuery versions like 1.7.1 and 1.8.1 from the UI5 delivery and with 1.40 the complete jQuery 1.x versions will be removed and we will only distribute the required version for UI5 which is currently 2.2.3. Here I would expect that we can do regular updates again until we migrate to jQuery 3.x which might again need some more testing to be safe.

HTH and best regards,

Peter

[daniel_ruiz2 · Accepted solution]

lol

[AndreasKunz · Accepted solution]

Ah, right, I screwed up this one... the comment close to the top was something taken from an even older version.

Anyway, despite of its age, as jQuery has matured for quite some years, 1.11.1 isn't too different from the latest 1.x release (1.12.3). And the upgrade to 2.x is - as Peter wrote below - something that required some extra effort, but has now been done for the upcoming version.

Regards

Andreas

[daniel_ruiz2 · Accepted solution]

haha, at least you took the joke on good spirit.. pretty cool.

but really, the sad part of the story is a hard dependency to jQuery when so much was fought to get flash out of the way for standard web apis, and things like .animate in the source when css3 is around is also pretty crazy (above all on sap.m namespace)

I don't want to hijack the thread or anything and I know you guys are all busy coding the library etc, but I would love to understand the reasons behind that approach.. lack of time or resources is not a thing, because SAP has the GDP of Ireland last I checked.. I just really don't get it.

PS: I'm not being sarcastic, I really don't understand why not to use an approach like Angular.

[AndreasKunz · Accepted solution]

Hi Daniel,

don't forget that UI5 was started before Angular, at a time where we still supported browsers like IE6 and CSS3 animations were far away. A huge part of jQuery was just needed to bring browsers en-par and avoid different code for different browsers all across the library. I think jQuery did and still does a good job making frequent tasks in the DOM easy and reducing the code we have to write. Comparing it to Flash is, frankly, comparing apples to a train loaded with rotten oranges.

Writing a similar (maybe more focused) low-level DOM lib on our own wouldn't have been a good idea: even with the GDP of Ireland I believe you should re-use existing stuff (especially on such a generic level) instead of trying to do everything on your own.

By the way: throughout most of the UI5 development time, the team had only around 10 developers, so comparing the company to Ireland, those other 4,594,990 people were not available to help us write our own jQuery.

Looks like jQuery 2 adds about 80k of overhead compared to jqlite, but I have to say I'm not familiar enough with the API comparison to judge how much more code would have to be written in UI5 to make up for the missing APIs...

Certainly the browser world is different today and switching to jQuery 2 reflects this even though this is of course not an early and bold step. And certainly we could do better in many places and move faster in some. But in enterprise space long-term compatibility is a hard requirement - we can't just say "let's throw it away, we'll do better next time" like Angular did. Sure, UI5 isn't as cool as those who can afford forcing apps to be re-written every two years. But long-term stability and reliability is also a value.

Regards

Andreas

[daniel_ruiz2 · Accepted solution]

hi Andreas,

Well, it will be hard for me to even question "when" SAP could have started something because information is closed, so there's no way I can actually validate what you say - so let's keep this argument off the table, and really work out releases.

UI5 has been released on 1.0 dates end of 2011 and Angular 1.0 dates end of 2010 - so Angular is older, but I really think the first initial release "to the public" (meaning a dozen of SAP Customers) happened around first quarter of 2012 pretty much on the Java side. Now at that time, there was already a minimum constraint of Internet Explorer 9, which was raised very quickly to Internet Explorer 10 for obvious reasons.. so really, justifying with Internet Explorer 6! is not a valid point because it wasn't even a target.

Web-APIs evolved just after the Flash "war" happened, and a lot of these new API's are very close to their AS3 versions, or even the Canvas manipulation with the drawing API from Flash - and the comparison is not far fetched: Flash was a problem because 99.9% of the browser had it installed (so there is a dependency) and some people cannot live without jQuery either because it was crazy to write js for every browser.. - jQuery had a peak and it's cooling and it will fade, at this moment with the current state of ES and vendor implementations there's very little reason to use jQuery - again, you can always write what is missing and rely on standards for everything else.

IMO ES is not close to what AS was / is, HTML/JS/CSS is still not as powerful as Flash used to be 4 years ago - analyse by it's merit, Flash was never bad until a jackass said it was bad, you probably know who I refer to.

I agree about re-writing, you should avoid re-write and re-use but only when you don't earn negatives of it - for instance, most if not all DOM manipulation happens with jQ.innerHTML which is absolutely slower than native manipulation and node creation. I mean, jQ.innerHTML even lose to the native innerHTML so why? - Clearly, you don't have enough resources to re-write of fix all the bottlenecks, all the aging code and pitfalls of the library because "scary" enough, a giant company like SAP can only really afford "10" developers to drive and code their "next big move" on User Interface when something like Angular has 200+ contributors... - I will read your statement as an excuse rather than a reason, and I'm not saying it's the developers fault. (and usually it's not)

Honestly, I haven't ever read that Angular, React or any of these other frameworks "force" someone to "re-write" or bump their versions - what happens like everything else is that major re-writes incur in shift, you bump a version and you work on that more than the previous code.. most of these frameworks still support older versions for quite some time, and again, "they are not in the enterprise world" (what you forgot is that only companies that does not understand this area too well would choose UI5 over Angular but this is another topic) - or worst, SAP can still say it's supported until X day and we will not be enhancing it anymore - it happened before in many occasions.

Basically, backward compatibility is not really an excuse to not fix pitfalls or not evolve - there are ways to work around this and I'm sure you guys all know this too.. why not challenge and push your company to invest more, because let's face it, 10 developers is sort of shame.

I suggest we add each other to keep talking (if you want), my stuff is being moderated and this is my last reply out of the main topic.

Cheers,

Dan.