cancel
Showing results for 
Search instead for 
Did you mean: 

Wishing sapui5 openui5 be ported to typescript

former_member182048
Active Contributor
679

A couple of days ago @ranjanprj tweeted the following

Wishing #sapui5 #openui5  be ported to #typescript

https://twitter.com/ranjanprj/status/576267708779491328

I replied


.@ranjanprj not sure i understand the requirement,

TypeScript is a superset of JavaScript, #UI5 needs to lose JQuery dep to support ES6


A couple more interactions later and suggested we start an SCN discussion on Typescript, jQuery and ES6 support in UI5

Accepted Solutions (1)

Accepted Solutions (1)

former_member185575
Participant

My personal opinion on that:

Classes/Types

That argument from people (ABAP, Java or C#) that "types or classes" would help them to learn JavaScript is totally valid - I am also looking forward to ES6 class, but still - I need to learn the original prototype stuff. On code completion I totally agree, only good editors are here to help. And undefined is not a function is mainly due to poor error handling or accessing non available deep nested objects methods. That is not a language fault - ok you could see some errors before when it would compile. But wishing that the language would be this and that is like: oh Python, I constantly do { and ; could a Python dialect fix that for me?

Maintainability 1

Internally there are a loooooooot of people creating SAPUI5/OpenUI5 and using it to create a bunch of apps (now with S/4 HANA a big bunch). To get all non-JavaScript people on board with JavaScript + SAPUI5/OpenUi5 was sure pretty hard enough and now adding additional stuff like TypeScript is I think a bunch of work for such a big company and I believe out of question. For our framework we are our best customers, adding additional complexity would be hard. And since we are supporting lots of older browsers, you should be able to read your transpiled code (extra work).

Maintainability 2

Another thing is when we would handover apps or framework stuff to the maintenance team, how much languages do they have to learn in the next few years? Now maybe Typescript is cool, before CoffeeScript, what about Dart - you could not afford that in such a big company to support every "hip" language dialect, we should close to standards. Concerning this, yes I would call jQuery a "standard".

Getting rid of jQuery

I am not deep into how we use jQuery in the framework, but for me as an enduser - yes provide me an equivalent for $.ajax 😉 JQuery messed up with Promises, but as John said we have our ways around this.

If I would write var Button = Control.extend(... or Button extends Control in future - hm more or less syntax stuff. SAPUI5 is a big framework, getting rid of jQuery would not make it that much smaller.


Summary

If you are your best customer with a framework and have a long maintenance period and support for a bunch of browsers - staying close to JavaScript only and jQuery is not the worst decision. And yes -even if it is not that cool to wait until certain stuff has been declared as standard - we have a large customer base to support. SAPUI5 is an enterprise grade framework for business apps and not "hip" cutting-edge latest Chrome only thing. If I look around and see this blazing speed stuff changes in certain frameworks and what is cool and what is not I am really quite happy to have something reliable in terms of language.

joao_sousa2
Active Contributor
0 Kudos

One of the reasons SAP is successful is because it has a large ecosystem of partners adapting and building modules on top of SAP.

Maybe a lot of SAP employees are using SAPUI5, but not that many external developers are, and that's a problem for SAP with S4/HANA, getting them to move from a heavy typed language like ABAP to JavaScript.

If the cost of developing for SAP becomes too high, and training for customer resources too great, it will just be another reason to switch away from SAP. Cost are already too high, even in the ABAP world, and getting Java developers to embrace SAP didn't work in the past. Enterprise development is not the same as web design.

former_member182048
Active Contributor
0 Kudos
SAPUI5 is a big framework, getting rid of jQuery would not make it that much smaller.

I kind of agree that getting rid of jQuery would not make it much smaller, a lot of my gripe about is actually its over use in Controllers, "No DOM Manipulation in Controllers" . However SAPUI5 is a large framework toolkit, the core is slightly bloated and needs to be more customizable. JQuery is not just dependency, its also a transitive dependency, example every piece of code touches jQuery via QUnit.

Former Member
0 Kudos

Now maybe Typescript is cool, before CoffeeScript, what about Dart - you could not afford that in such a big company to support every "hip" language dialect, we should close to standards.

Typescript is not cool, it's an established dialect to give JS types, to allow easier maintenance and testing. And I would say Google and MS are bigger players in web development than SAP. They know what they do.

Furthermore, it would allow to throw out the awful hungarian notation I see in your code snippet below too. I wrote about that in another article and it drives me up the wall to see that.

To get all non-JavaScript people on board with JavaScript + SAPUI5/OpenUi5 was sure pretty hard enough and now adding additional stuff like TypeScript is I think a bunch of work for such a big company and I believe out of question.


I'm part of the third party developers and I get the impression that it would be a good time to move UI5 in the right direction, as adoption outside of SAP is not that high at the moment.


I need to learn the original prototype stuff. On code completion I totally agree, only good editors are here to help

I can recommend that three part series here -> http://davidwalsh.name/javascript-objects JS ticks differently to other languages. Nicely shown here.


PS:

Maybe even more important would be updating the API documentation. It's pretty bad. Methods and it's parameters are badly described on the API page -> https://openui5.hana.ondemand.com/#docs/api/symbols/sap.ui.html

It takes us forever to do simple tasks that are out of the scope of tutorials and simple apps, because we have to do a lot of trial and error. There is room to improve that with TypeScript for example.

PPS:

Also, how to test UI5 properly should be better documented too.

Qualiture
Active Contributor
0 Kudos

Honestly, what drives me up the wall is the ABAP style of WRITING EVERYTHING IN CAPS AND ITS HEAVY_USE_OF_UNDERSCORES

However, I think the API is actually well written, and every parameter is explained sufficiently. Could you maybe elaborate what you're missing?

former_member182048
Active Contributor
0 Kudos

wrt ABAP_SHOUTING

I do this all the time, especially in translation files and naming controls in views, I feel my approach is inconsistent with others.

Declaring constants also throws me, where and how to declare them? I tend to create own module under Utils and use then like utils.Constants.CONSTANT_VALUE but this doesn't feel right

The OpenUI5 guidelines don't cover these areas, wondering if it warrants a crowd sourced style guide for UI5 development?

MattHarding
Active Contributor
0 Kudos

+1 for constants and + even more for crowd sourced style guide (though would be nice if SAP put their UI5 guides out as a starting point in a public wiki, git, or similar.

Former Member
0 Kudos

Well, here the examples:

1. Search is totally unsufficient to find anything. Enter anything and you get a list of dozens of results and in almost any case, you won't get what you need on top.

2. Parameters in functions are inconsistently described. Sometimes you have arrays as parameters but the API does not tell how such an array should look like. Take bindElement() for example:

bindElement(sPath, mParameters?) : sap.ui.base.ManagedObject

Bind the object to the referenced entity in the model, which is used as the binding context to resolve bound properties or aggregations of the object itself and all of its children relatively to the given path. If a relative binding path is used, this will be applied whenever the parent context changes.

Parameters:

{string}sPaththe binding path
{object}mParameters?map of additional parameters for this binding

Returns:

{sap.ui.base.ManagedObject}reference to the instance itself

So tell me, what is mParameters and what parameters can I pack in there? A good API should add a couple or one example how to use the function into the documentation, that's not the case here.

That's the biggest headache we have here with the API.

3. Incomplete documentation. Take AmountFormat for example -> JsDoc Report - SAP UI development Toolkit for HTML5 - API Reference - sap.ca.ui.model.format.AmountF...

Many parameters are not documented and ambiguous.

The OpenUI5 Explored docs are better, but it's only mobile and why should I look at multiple places?

joao_sousa2
Active Contributor
0 Kudos

Completely agree with number 2, the "parameters" issue is widespread in the documentation. As for number 1 I gave up on integrated search, since Google gets you better results.

Qualiture
Active Contributor
0 Kudos

Hmmm, I guess you're right about these points which are indeed very valid; it's just that it never occured to me...

The search is indeed broken -- or at least does not work as expected -- and there are indeed examples of where the documentation is severely limited it seems. But if something is unclear, I just dive into the source code to see what's expected at a certain parameter

Yes, I fully agree these should be documented in the API of course, but then again, we are developers and we love to take a peek under the hood, right?

Former Member
0 Kudos

I disagree. I'm a developer to create solutions build on UI5, incrementing fast. Therefore I have no interest to look into the framework source code to accomplish simple tasks.

It takes time away from the actual stuff: building a testable and maintainable solution.

I don't have that issue with Angular, React, Meteor or any other modern JS tool, hence why I complain here

Qualiture
Active Contributor
0 Kudos

Of course it takes time from the actual development, but so does looking up stuff in the API (where it should be documented in the first place, let that be clear) but once you've grasped it -- whether from API or sources -- you'll never look back anyway

But if my memory serves me well, I believe I saw a tweet the documentation should be significantly improved the coming wave, let's hope it can live up the expectation

Answers (6)

Answers (6)

Tino
Explorer
0 Kudos

Hey Guys,

any new thinkings on TypeScript support in UI5? I would really love to have at least type definition (*.d.ts) files for the UI5 library. Those type definitions really add value to the development lifecycle as it removes a lot of very common errors. You could even watch that in the OpenUI5 course, where guys from the UI5 core team sometimes fought with some errors that wouldn't have occured with TypeScript. As a bonus you can write ES6 style today with all the good new stuff.

I really like this article about the motivation of the Angular team going the TypeScript route:

https://vsavkin.com/writing-angular-2-in-typescript-1fa77c78d8e8#.s1ybj8gsd

Even when UI5 would be written in TS, all other guys in SAP can still write Fiori apps in JS if they are not familar with TS (as it is just a superset), but I believe that one of the biggest struggles people have in the transition from ABAP OO to JS is the missing type system and Class syntax...

At UI5con Andreas Frische talked about using UI5 with TS, but as you can see, the current lack of support in the framework doesn't make it as easy as it should be:

https://www.youtube.com/watch?v=H6cqFVlKk7w

What do you think?

Regards

Tino

Former Member
0 Kudos

Hi Tino,

last year I had the impression that something like TypeScript would be helpful, but meanwhile I read a couple counter arguments.

For example that it's distracting people from really learning JavaScript instead of applying C#/Java concepts on top of JS, which is fundamentally different than those.

One should learn how to program functional style and use those advantages of JS instead of applying the imperative paradigms of OO languages.

I think I agree, but I'm not sure yet because I haven't used TS on a large application yet.

What would be much cooler would be ES2015 or ES2016 support in UI5. That would improve the code a lot.

Kind regards,

Michael

ChrisSolomon
Active Contributor
0 Kudos

"What would be much cooler would be ES2015 or ES2016 support in UI5. That would improve the code a lot."

That's the whole reason we have things like TypeScript (and Babel) now....because of the lack of support, these have to be "transpiled" into "old" JavaScript for support. I have been working a lot on side projects with Angular 2 and React.js, so I am just used to having to switch "languages" and deal with it. However, I think the support will come soon (quick?) and then the whole notion of needing TypeScript will fall away.

Former Member
0 Kudos

As an SAP employee, I'm a big fan of UI5 and ES6 / ES7.

I personally made a series of plugins which help the developers to leverage the latest front-end technologies to build SAP UI5 applications, including ES6, Babel, LESS, Gulp and Webpack.

Babel Plugins

GitHub - MagicCube/babel-plugin-ui5: An UNOFFICIAL experimental Babel transformer plugin for SAP UI5...

GitHub - MagicCube/babel-preset-ui5: An UNOFFICIAL preset for building SAP UI5 application with Babe...

Webpack Plugin

GitHub - MagicCube/ui5-loader: An UNOFFICIAL experimental Webpack loader for SAP UI5. Together with ...

Gulp Plugin

GitHub - MagicCube/gulp-ui5-lib: An UNOFFICIAL Gulp plugin for building SAP UI5 libraries.

Example Project

GitHub - MagicCube/babel-plugin-ui5-example: An example of how to use babel-ui5-plugin with Babel 6.

As always, please star my projects if you like them.

Former Member
0 Kudos

Hi Tino,

I don't think that UI5 will ever be ported to Typescript, since its code base is huge and encrusted with a custom-style semi-inheritance hierarchy that would imply a complete rewrite of the whole codebase to take benefit of TS features.


Nor I believe that a ui5.ts.d would be of help: UI5 is complex, sometimes unnecessarily overcomplicated and while having a TS declaration would ease the development, the elephant will still be there.

I develop applications on UI5 since 2013 and decided to migrate my 200k+lines of code to Typescript and my approach is to have my own pure TS Objects wrappers on the components I use most.


That way I simplified interaction with UI5 compos and abstract from them, just in case another framework (Angular2?, Polyfills?) gets more stable and enterprise-ready then do a complete UI5EXIT.


Just my 2c.


--R

Former Member
0 Kudos

I'm personally a kind-of passionate early adopter / beta user hence I played around with TypeScript already a year ago and it seemed quite cool (I also made it to work with HANA XS), but couldn't use it yet productively as it was too intrusive to make a gradual switch. Still I think TypeScript has a good outlook, given that it's backed by MS + Google and its just a superset of JS that stays as close as possible to the ES4 / ES6 / ES7 proposals. CoffeeScript never had a big company backing it afaik and its syntax is pretty different / incompliant.

Facebook's Flow seems to be a bit less intrusive and it also supports code checks for a bit more functional style code (which I'm a big fan of - OO sucks , watch out for ramda/ramda · GitHub). Unfortunately it lacks at the moment the maturity of TypeScript. Wrt to Dart I'm having the feeling it will never get really high adoption from the community, because nowadays JavaScript's features are catching up quite fast (ES6, ES7 and TypeScript etc.).

What I'm already using in some smaller projects is ES6 and ES7 in the backend (HANA XS, node.js) with the babel transpiler. In a recent node module which I wrote I made heavy use of arrow functions, template strings and ES7 async functions (those are really awesome!). In another HANA XS app I'm using just ES6 features.

Now that WebStorm 10 properly supports code completion of the ES6 module syntax I'm planning to create a small PoC on using ES6 modules with UI5 (instead of the UI5 module system). Therefore I will create probably a systemjs plugin that loads ui5 modules: systemjs/systemjs · GitHub . I did something similar already a few months ago with commonJS modules and webpack, but the result was a bit unsatisfactory, webpack seemed too complex and the server-side compile step was a bit annoying.

The cool thing is as soon as the systemjs loader properly works with UI5, one can basically plugin all transpilers that systemjs supports - most importantly babel 🙂 Systemjs does all the transpilation in the browser (during development) - so you still can make fast incremental changes and don't rely on too complex infrastructure.

I'll let you know when I make some progress with my plan.

Best Regards Christian

former_member182048
Active Contributor
0 Kudos

thanks for sharing Christian

I recently watched the ng-conf 2015 Day 1 Keynote and it was mentioned that Google (Angular + Chrome etc) is not only collaborating with Microsoft on Typescript but also working with Facebook and people like Yahuda  Katz (EmberJS/JQuery/Rails) and Jo Liss (Broccoli), smart crowd, TypeScipt definitely has a good outlook, lets hope we see more emphasis on FP than OO. ( further on in Keynote they took a wrong turn mentioning Angular 2 is set to use observable over immutable though ).

Sounds like you have really come quite far already, please do keep us updated with your progress and share what you can.

JSP

former_member182048
Active Contributor
0 Kudos

I apologies upfront for this next comment, probably wont make much sense but hopefully someone can pick up the gist.

I think you can make a good business case for TypeScript support for SAPUI5.

Typescript is about getting Enterprise developers to adopt Javascript. And by Enterprise developers i mean .Net and JAVA developers.

Somebody mentioned Visual Studio and I saw the bigger picture.

- Not one person has mentioned Eclipse in this thread, SAP have backed the wrong horse, WebIDE as productive as it is, is a super set of Eclipse.

WebIDE and Eclipse is targeted at net new JavaScript / Web developers, those who need an option.

I don't think you can convince existing Enterprise developers to leave the comfort of their tooling Visual Studio and Jet/Net/Webstorm and use your IDE, therefore you need to go to them!

Why do i think that Typescript is an Enterprise play.

CoffeeScript is to Ruby as TypeScript is to Java/C#/C++." - Luke Hoban

From Scott Hanselman's blog Why does TypeScript have to be the answer to anything?

JavaScript won the war!! the browser is ubiquitous (for now)

Coffescript was about getting Ruby on Rails, Python etc. developers to adopt JavaScript, these developers are more used to full stack development, they normally build consumer facing sites and have to cover the full process from CSS Preprocessing, to build pipelines and setting scalable repeatable production environments

SAPUI5 is about consistency and repeatability, these developers as a generalization get paid to build unique products. It will be hard to pitch SAPUI5 to them.

TypeScript is aimed at Enterprise developers, again a generalization, traditionally not as well versed in full stack development as the Rails crowd, sure they cover the full stack, but they have other things they need to worry about, like consistency and repeatability.

I see the Enterprise developers being more focused on interoperability between silo'd data stores and how to add value to something that is already there.

The cloud adds value to an Enterprise.

I think indirectly TypeScript and the coming together of Microsoft and Google is a cloud play, mainly for Microsoft.

Why have Microsoft invested lots of efforts in supporting AngularJS in Visual Studio, Microsoft  have their own JavaScript frameworks which are quite popular (KO etc), but not popular enough. AngularJS is being adopted by .Net developers because it is familiar to them. Offers developers things like Dependency Injection and Test Tool etc, making development on the front end a very familiar process.

BYOF bring your own Framework, we will provide the tooling and the back end, Azure.

You need to go to where the developers are to get them to use your products, one way would be to start with how they develop and make SAPUI5 easier to adopt  .

Food for thought or jetlag rambling, hopefully someone makes some sense of it.

JSP

Qualiture
Active Contributor
0 Kudos

Valid points... I for one would rather not use SAP WebIDE / Eclipse because I'm too attached to IntelliJ / WebStorm. Other enterprise developers most likely have their own preferred "enterprisey" IDE's apart from Eclipse

Coming from a Java background, I would wholeheartedly welcome TypeScript support for SAPUI5.

We once convinced SAP to open-source SAPUI5, maybe we can repeat history with our wish for TypeScript support?

joao_sousa2
Active Contributor
0 Kudos

In another thread where I was complaining about the lack of local SAP WebIDE you said I should look into WebStorm, and for someone used to Android Studio, Visual Studio, etc, its way better then SAP Web IDE.

Now I only use WebIDE for the web dispatcher and mock data.

Qualiture
Active Contributor
0 Kudos

Glad you like it, IMHO it is a real 'coders' IDE (as is their Java IDE IntelliJ)

WebStorm has out of the box typeScript support too WebStorm 9.0.2 Help :: TypeScript Support

former_member182048
Active Contributor
0 Kudos

I recently watched a developer code AngularJS with WebStorm, i couldn't keep up with what was happening it was so fast.

The thing that blew me away was how intuitive it was, the workflow felt and looked seamless, you know there is other libraries and tooling underneath like Jasmine, Grunt and Karma etc. but it looked polished and complete.

I wouldn't hesitate in paying for it if i could get the same experience for UI5

former_member242034
Discoverer
0 Kudos

This discussion is going a bit off topic imho.

#SAPUI5 is actually one the best pieces of software that I saw coming out of SAP. It is very well documented and designed and have been playing with it since inception when I was in SAP.

Javascript and libraries have their  flaws but it is quite powerful and suitable for dynamic applications, but for large scale application development and maintainence you need the discipline of statically typed programming language.

Here is why I think Typescript is the answer.

1. All Javascript is already Typescript ( Typescript is superset of Javascript ).

2. Typescript compiles to ES5, ES6 based on the compiler options provided.

3. With typescript you can use existing JS libraries such as JQuery, you can provide typed definition.

4. The compiler and compiler definition is opensource, so there is no lock in.

5. Typescript is only a type checker, i.e it's only for tooling and correctness, you still get idiomatic   javascript as output.

Coffeescript does not provide typesafety to the level of Typescript and the syntax is bit alien.

Dart the syntax is very nice but cannot use or facade existing Javascript libraries.

Maybe there could be a community effort and I'm thinking of developing a POC to show the benefits of Typescript for UI5.

Former Member
0 Kudos

Priya -

I disagree you on the premise that you need a static typed language for a large application I think that is a misconception that is propagated by bad or lazy practice in teams.  I have no problem with TypeScript as we use it ourselves - but I would say that language features are not the salvation its still left to the team/developer to build solutions in a disciplined way.  The compile time checking only gets you so far.


What I would like to see is more support for html views in the UI5 framework - or at lease better documentation around this.  Our team is transitioning our web dev efforts from Angularjs and Durandaljs to UI5.  We are web developers first, sap/abap developers second.  We are accustomed to HTML and CSS and we prefer to build our web products by building the markup/layout first and then binding it to our model....

joao_sousa2
Active Contributor
0 Kudos

Typed language leads to good intelisense which improves productivity and decreases the change of error.

When I'm writing C# or ABAP, the fastest way to discover I'm doing something wrong is for intelisense to fail since I rely on it to type faster. That doesn't happen in Javascript.

Qualiture
Active Contributor
0 Kudos

Both SAP Web IDE and IntelliJ (shameless promotion of my blog here) allows for proper code completion.

True, with untyped Javascript you could still deliberately enter bogus objects in method parameters, but at least the IDE's help you with correct parameter signatures

joao_sousa2
Active Contributor
0 Kudos

I don't call that code completion real intelisense. It's in another league.

Yes it helps, but it's not the same.

To clarify, when I'm doing ABAP or C# if intelisense fails, I messed up, period. Not with Javascript.

Qualiture
Active Contributor
0 Kudos

Indeed -- what else could you expect from an untyped language -- but to add in it's favor, just as IntelliSense, these code completions are perfectly context-aware.

(IntelliSense is a Microsoft Visual Studio originated thing anyway which I haven't touched for ages)

joao_sousa2
Active Contributor
0 Kudos

Tab is your friend. I call intelisense all implementations of the same type.

I actually like Visual Studio (which is now free with Community Edition). Add-ons for Office can really increase your productivity.

MattHarding
Active Contributor
0 Kudos

Hi John, Denise & Joao,

My 2 cents - I talk about TypeScript from a more philosophical perspective. The purpose of TypeScript (IMO) is to get rid of simple type style/common JavaScript issues that can be identified with an additional preprocessor language.

While I don't think this is the solution for JavaScript, the problem is very real. My hope is that we get a much higher artificial intelligence in our linting programs that can effectively understand what the developer is trying to do (and ask questions if it doesn't understand).

The point is, UI5 is for enterprise programs, and enterprise programs are usually not prone to misspelling a variable name, and everything being okay.  UI5 programs can happily make it through to production without a red flag being notified to the basis team; and this is a real concern.

Linting is the best way we have today (which is not forcibly integrated in the deployment through WebIDE today), but I think we need more and TypeScript is one brute force solution to this.

So bring on the AI in linting that understand UI5, and introduce constants from XML views and Gateway Services that remove us from typing this.getView().byId("IncorrectId"), but that's a big project in itself, but what will be necessary to avoid developers used to heavily typed languages like ABAP making a mess of production UI5 code.

Just my 2 cents.

Cheers,

Matt

former_member185575
Participant
0 Kudos

Hey Matt,

just wondering, because in Web IDE there is linting turned on by default and it seems to be quite useful - but if let's discuss this maybe in another thread if there are Web IDE problems.

For SAPUI5 development itself there is a linter on server side which not let you merge your stuff until everything is fine, for app development I don't know.

Hey Joao,

for me as an ex-ABAP developer - but with previous web development experience - getting rid of types was the smallest problem for me. The problem was more to understand a real MVC framework like SAPUI5 (in contrast to jQuery mobile) and getting onboard with all the other stuff like REST/OData. There is a bunch of work to do and understand on front- and backend to get an SAPUI5 app, even if wizards (Web IDE) help us to speed up. But it is an "expensive" process you are right. But for the first time - an "GUI" and a data communication (OData) from SAP based on standards and open source - yay!

Ah ok but I am getting off-topic.

former_member182048
Active Contributor
0 Kudos
For SAPUI5 development itself there is a linter on server side which not let you merge your stuff until everything is fine

Your talking about the Continuous Integration proccess right (Jenkins, Maven and Gerrit), a CI process is much needed feature in the WebIDE, that and Grunt + Karma and a CLI.

for app development I don't know.

run a linter over some of the Fiori apps and you'll get your answer, can also tell you all of the Fiori apps i have seen appear to have 0 Code Coverage (not good practice)

Would love for you to write more about how the core team at SAP internally on-boards developers for SAPUI5 developments. Have heard from a few people that initially this was a big challenge. I can only imagine with S4 the process has been somewhat refined and is quite efficient.

MattHarding
Active Contributor
0 Kudos

Hi Denise (and others),

John covers it off pretty succinctly but in short, outside of SAP, deployment is not fully automated and there is no guidance from SAP on best practices for this from what I can tell (though there are pieces here and there about this).

And linting currently only goes so far due to the inherent nature of JavaScript which is interpreted mostly at runtime - and until we can build a overarching project linting tool that can run the whole project in it's head with knowledge of string constants and what "this" is that; we will see unexpected results in testing that in stronger typed languages (or TypeScript) would not have compiled).  Note - I know I'm dreaming here but this is the only real solution I can think of to solve this with the current UI5 framework.

Plus for reference, I've encountered at least one variable naming issue that passes linting tests but is obviously an invalid spelling before (can't remember exactly what it was however).  And do you always remove the variable that is not used for events, even though you may use it in the near future??? e.g. Linting is far from perfect but is far better than when I used to develop JavaScript in notepad++ but also isn't always a compile error that should stop you going to production.

And I 2nd John's request for how SAP internally on-boards it's business suite SAPUI5 developers... e.g. this is a good conversation, and I do stress I love developing UI5 apps and seeing how happy customers are with UI5/Gateway interfaces that have been deployed, but to go off topic slightly for just a second, it's a real problem the fact that people (including myself) are struggling with the right way to build UI5 (with the ever changing best practice that is still a while away from settling IMO), that they are also not building with best CI practices like John and others within SAP promote; that mock frameworks only go so far for automated testing with the real need to build the mock framework into the Gateway/HANA oData itself potentially, that XML views are the defacto standard for views, even though this is not a typical approach to Web development and before WebIDE meant you needed to read the API documentation every time you tried to use a control, etc.

Actually, further to John's request; I'd like to encourage SAP to recognise this issue and to publish a roadmap for how it plans to get UI5/Gateway quality from all developers within the SAP eco-system (and beyond) and recognise that the path to S/4 Fiori "everything" needs at least a foundation of stability from a platform that is currently continually undergoing great improvements. e.g. At some point, in the Enterprise world, we need to get the foundation stable, and focus on new controls, optimisation, and other things seamless to all the apps already developed and not redo best practice because someone has an excellent idea.  e.g. The jump from Odata to Odata v2 was an excellent example of this.

Sorry - off my soap box now...

Cheers,

Matt

Former Member
0 Kudos

@Denise = please explain how JQuery messed up with Promises...?   Promises are a very useful feature for web development!



joao_sousa2
Active Contributor
0 Kudos

Hi. I really hated JQuery Mobile which I used before SAPUI5. In comparison SAPUI5 is awesome!

As I get more and more used to SAPUI5 I do less errors, so I waste less time in Chrome Developer tool. The problem is when you compare Javascript development to ABAP development in Eclipse with intelisense, ABAPDocs, automatic generation of parameters and automatic detection of syntax errors. I'm so much more productive!

SAPUI5 is being pushed by SAP so they have the most interest in using it, but for customers who are balancing a budget, if SAPUI5 is so much more expensive to develop and maintain they will either stay in ABAP (which is very bad for the S4/HANA strategy) or migrate to another vendor.

If SAPUI5 is to replace ABAP as the main programming framework (it seems that is the intention, ABAP becoming less and less important in S4/HANA) it needs tools as robust as ABAP. I let us reminded ourselves that ABAP is still miles away from Java or C#.

Training my team to use SAPUI5 will not be easy, I'm spearheading the effort but I foresee a lot of problems.

former_member185575
Participant
0 Kudos

I should correct myself: (Promises itself are super-useful, but) jQuery at the beginning did mess up the implementation:

Javascript promises and why jQuery implementation is broken | thewayofcode

promise - Problems inherent to jQuery $.Deferred - Stack Overflow

You're Missing the Point of Promises

therefore in SAP Web IDE we have used the Q library for promises. Maybe it is fixed now in jQuery, I didn't track this, since we used Q.

former_member185575
Participant
0 Kudos

To John - and others,

I think this is really great discussion with lots of valuable input here.

SAPUI5 internal

I can not answer the internal SAPUI5 onboarding, since I am not in that team, only can do for example.

Concerning CI for SAPUI5 - yes I meant Jenkins/Maven/Gerrit. For SAP Web IDE "build processes" yes you are right, let's see what happens over time and where priorities shift.

My types-opinion in general

Concerning types itself: I was a strong fan of ActionScript 3, it had everything a JavaScript developer could have dreamed of! It was really a pity that all the stuff had to be "reinvented" in JavaScript with jQuery extend or module loading with require and so on before it is now getting into the ES6 standard.

The idea of TypeScript itself is brilliant - it would make the life much easier (code completion/refactoring/knowing errors before runtime...) - I think there is just this little voice in my head with Microsoft & "web standards" (old IEs) and the former JScript which makes be a bit skeptical.

But Microsoft is doing a real great job now and with Google on board they could really make our JavaScript devlifes much much easier - and both are on the TC39 I think. It is just my personal fear not on "betting the wrong horse" (transpiler) and re-train-and-re-explain all the people - although this is even not my job

Conclusion

All in all I am very excited what the future will bring for SAPUI5 - when and if ES6 comes in, how much jQuery, if and when Web Components, ... - exciting times!

--- when typing SAPUI5 I for sure also mean OpenUI5.

Former Member
0 Kudos

Ah ok I understand.. I thought you were saying the concept of promises was bad... Im following you now... thanks for clarifying

former_member182048
Active Contributor
0 Kudos

I will start by adding context to my comment


.@ranjanprj not sure i understand the requirement,

TypeScript is a superset of JavaScript, #UI5 needs to lose JQuery dep to support ES6

TypeScript is a bit of a hot topic at the moment, at the recent AngularJS Conference NGConf there was an announcement that Microsoft and Google had been working together and the news was Angular 2.0 was going be built on Typescript

[SOURCE] Angular 2: Built on TypeScript - TypeScript - Site Home - MSDN Blogs

What is Typescript? Originally started by Microsoft, its a superset of JavaScript, aimed at making JavaScript more familiar to .Net and now Java developers providing them more familiar syntax and better tooling being supported in both Visual Studio and WebStorm.


.. adds optional static typing and class-based object-oriented programming to the language

[SOURCE] TypeScript - Wikipedia, the free encyclopedia

Microsoft also announced that the plan for TypeScript was to fully support ECMA Script 6 (ES6) in upcoming releases. That is the TypeScript transpiler will translate TypeScript code into JavaScript EC6 code. example Playground - Welcome to TypeScript

My comment about UI5 needs to lose JQuery dependency to support ES6,

SAPUI5 uses JQuery for some of the features that are/will be available in ES6. Also some of the jQuery features like Promises break the ES6 Native standard, this has already been picked up and there is jQuery based polyfill in jQuery.sap.promise.

I guess my point is SAPUI5 needs to mandate it ONLY supporting Modern "Evergreen" Browsers, as in browsers that keep themselves up to date, even Microsoft says its new browser IE11/Spartan whatever its called will be Evergreen. jQuery is quite a heavy dependency in terms of footprint, jQuery and JQM best days are behind them and the browsers they were built for are gone.

Looking at how JavaScript frameworks are evolving with things like AngualrJS 2.0 built on Typescript, EmberJS dropping jQuery, mobile toolkits like IONIC and how they render at near native speeds, React and the possibilities available when you use a  Virtual DOM eg Isomorphic / React Native mobile etc. And then there's the possibilities that HTTP/2 will bring, I think that jQuery is becoming a legacy and IMO needs re factoring out of UI5 for UI5 to be able to stay relevant.

What's your thoughts?

joao_sousa2
Active Contributor
0 Kudos

As a person more used to Java and C# writing things in Javascript with it's awful code completion and constant undefined errors is a pain for maintenance.

Typescript would be a huge plus and I do agree that supporting older browsers when mobile is the focus is misguided. Problem is the perceptions that many enterprise customers are still on IE8.

My company is in process of rolling out Windows 8.1.... yes, when Windows 10 is almost here. Same thing happened with Windows 7, which we only got when Windows 8 was launched.

former_member182048
Active Contributor
0 Kudos

Thanks Joao,

wrt to Browser support


" Problem is the perceptions that many enterprise customers are still on IE8"

I agree and from what i see a lot of customers are trying to roll out Fiori on Windows XP via Chrome for XP.

I don't think this is a very good strategy. Microsoft no longer supports Windows XP and Google have said next month they will stop supporting Chorme for XP. I think this will create a major issue for customers, one which I think SAP shouldn't hold their hands through.

former_member242034
Discoverer
0 Kudos

John Patterson thanks for creating this post and having the discussion on this.

Well It was me who wrote that twitter post so just wanted to detail it a bit here my perspective.

I understand that Javascript is a great programming language to do web pages. But when it comes to web applications things change a bit.

UI5 took the object oriented approach with JQuery as an underlying DOM framework to abstract itself away from the document oriented nature of web applications to an object oriented nature of web app development and this is great, but when it comes to enterprise Javascript starts become a problem at that scale. Few thoughts and this applicable to any enterprise grade application development.

1. The UI layer is where more refactoring is requested / required by the customer/end user.

    This is exceptionally hard to do with Javascript over a period of time.

2. Long term maintainence, enhancement of UI is very hard with untyped Javascript.

3. UI Scaffolding, code generation can be done but hard again to maintain, understand and extend.

4  UI5 is fully OOP and constructor driven, with lots of parameters, a typed language would impact a lot on developer productivity in this case.

As for TypeScript

1. Typescript can compile down below ES6 as well, Currently compiles to ES5.

2. With TypeScript you can create type definition facade ( tds ), already done for Jquery and others here

    https://github.com/borisyankov/DefinitelyTyped, same facading can be done for UI5.

3. High code reusability possible with a typed programming language.

4. Good code generation, scaffolding and extension possible.

5. Google dropped AtScript and joined rival like Microsoft on TypeScript, and this shows and maturity   of   TypeScript.

6. Typescript compiler is completely open source under Apache license.

7 Microsoft and Mozilla have already ported well over thousand lines of JS to TypeScript via some kind of pattern match and replace.

If SAP embraces TypeScript for OpenUI5 which is a superset of JavaScript, then it would provide huge advantage in all areas.