I think it's ok for us to say that the baseline is IE11. If you are concerned, take a poll on the users list.
On Thu, Oct 5, 2017 at 3:43 AM, Thomas Andraschko <andraschko.tho...@gmail.com> wrote: > Hi Werner, > > big +1 for doing a completely new jsf.js! > > Basically it would be really great to use another lang as plain js. > But there is also another downside: most webdevelopers and commiters of > MyFaces are fimilar with plain js but maybe not with TypeScript or else. > But i think we should do it if can we can easily integrate it somehow in our > maven builds. > My personal opinion is that i would prefer plain js if the developers must > install nodejs etc. on their machines. If everything is done by maven in the > background, it's ok for me. > > As you already said, we actually must avoid dependencies like kotlin.js and > jquery.js - thats a no go and also not really required. > > Regards, > Thomas > > > > 2017-10-05 9:19 GMT+02:00 Werner Punz <werner.p...@gmail.com>: >> >> 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 >> >> >> >> >> >
