+1 on rewriting the JS codebase. I'm personally a huge fan of TypeScript as well and use it on a daily basis, and I don't see a downside with choosing it since it's very popular these days.
One other possibility, however, is pure Java using JSweet ( http://www.jsweet.org/). It's certainly more build overhead than just using TypeScipt, but since it uses the tsc compiler internally _and_ integrates with maven, it might be a good choice. It doesn't have a runtime library like Kotlin. ___ Kito D. Mann | @kito99 | Author, JSF in Action Web Components, Polymer, JSF, PrimeFaces, Java EE training and consulting Virtua, Inc. | virtua.tech JSFCentral.com | @jsfcentral | knowesis.io - fresh Web Components info +1 203-998-0403 * Listen to the Enterprise Java Newscast: http://enterprisejavanews.com On Thu, Oct 5, 2017 at 3:19 AM, Werner Punz <werner.p...@gmail.com> wrote: > Hi guys > > > I just wanted to start a discussion on how we are going to proceed with > the jsf.js codebase. > The issue is following: > > Our codebase which currently is adapted by me for 2.3 is rather old. > It by now is around 9-10 years old and back then most of the stuff I did > made sense > a) The library needed to be self contained > b) There were an awful lot of browsers in use, which did not adhere to any > standards whatsoever > c) There was no real inheritance system available just the prototype > system which is one level below inheritance by allowing to access the > class/object tree and manipulate it on the fly > > So what I did was following > Implement my own class system for not having to deal with prototype > inheritance all the time > Since I needed to be self contained integrating a library like JQuery > (which also was it its infancy at that time) was out of the question > due to possible conflicts. There also was no widespread support > for querySelector on node level some browsers had it some browsers > had other workarounds to speed the dom node lookup up. > > Also no unified ajax handling, the ajax api was at its infancy and I still > had to support the archaic IE way of doing things. > > To the worse there were significant differences in dom and xml handling > between the various browsers out in the wild compared to the already > defined standards (I am speaking of you IE and mobile browsers in use back > then) > > So in the end I ended up with a codebase which is about 40-50% there just > to support legacy browsers. While I did some work to isolate the quirks > code and compile it out of the codebase there still is work to be done. > > Again all of this made sense back then... > > > Lots of things have been changed in those 10 years and now most of the > things do not make sense anymore. > > a) We have saner meta languages which allow to compile to javascript, > following candidates come to my mind > > - Typescript, a language which I amn very familiar with due to my day to > day work > - Coffeescript ... not very familiar with that one > - Kotlin... yes that one also has a javascript target compiler > > We definitely should opt for a meta compiler instead of pure js. > The reasons are many, and I can speak here atm only for Typescript > > - You can change ecma script levels on build level > - You can change the package management system in build level > - You get additional coding security by having the apis fortified at least > with some types instead of doing constantly your manual asserts > - In the end the Meta language codebase is way cleaner than the original > one > > > The downside is > > > at least for typescript the maven integration is non existent, there is a > maven clientside plugin which downloads the entire node js chain onto your > machine within a build, but my guess is we do not need to do this > for the apache integration builds, because in the end we just need the js > codebase. We can add special dev profile which enables the client side > build to build the js files. > > As for Kotlin, I have not evalauted their javascript stuff but what put me > off was that the website said you have to integrate kotlin.js which is a no > go, but this depends, if kotlin.js just implements their runtime lib we can > probably bypass that. I need to have a serious look at it. > > The plus side probably is that it has decent maven support and a perfect > IDE support on the Jetbrains IDEs. (Dont get me wrong the IDE support > of Typescript also is very good on those, I use it on a daily base) > > > Browser support: > > Since mobile browsers are up to rather recent standards nowadays the > problem is the desktop which at least in a corporate environment is moving > really slowly (I wonder corporations are really cautious regarding security > and yet often use stone old often outdated not updated anymore, browsers - > but that is just a snarky sidenote). But still there things have gotten > better. > > From a browser support standpoint we probably can strip the support pre > IE9 level which means we finally at least can use a standard ajax api, ajax > multiform requests instead of the iframe hack I had to introduce for jsf > 2.2. > > I would prefer to have IE11 as baseline, given that most corporations > probably have frozen their environment on a Windows 7 IE11 baseline by now, > but I guess we have to drag at least IE9 with us with some third party lib > support. > > By mildly adding small external libraries and avoiding shims > we might get a small query monadish api on top of node.selectorAll like > jquery. > > I still would avoid to integrate jquery because we have a core lib > so everything integrated needs to be small. We do not have the luxury of > for instance Prime Faces which can require or bundle a huge lib like JQuery > and JQuery UI. > > Also we definitely would need promises (again rip the code out of a proven > shim lib but do not shim it, if it is not supported by the browser > natively) > > So my proposal is, after 2.3 I will start with a reimplementation which > might take some time in a saner environment and with a newly defined > baseline. > And once I am done we can drop it in as alternative jsf.js codebase > for the users (we still keep the old one for 2.3) > And for 2.4 upwards we will drop the legacy codebase entirely and just > use the new reworked and cleaned up one. > > > Just a little bit of food for discussion. > > Werner > > > > > >
