yep. +1 for IE11 in JSF.next 2017-10-05 14:36 GMT+02:00 Werner Punz <werner.p...@gmail.com>:
> Yeah given the timeframe, I guess IE11 is perfectly fine. We cannot > expect JSF 2.4 to hit the final spec before 2019, by then even > corporate support of Windows 7 will come to an end. > > The main problem I see is that we probably will be stuck with supporting > IE11 for many years, since Microsoft still basically packs it in with > every windows 10 sort of as secondary browser. So IE11 support will die > about 10 years after Microsoft stops doing it. > > And believe me even IE11 > is currently the bottom barrely quality and speedwise you currently get > in the browser space. Even frameworks like Angular 1 basically drive the > IE11 engine to its limits, the more shims you add it the bigger the browser > becomes as a problem in day to day development. > > > I guess we once will hit the point where we will say we cannot support it > anymore. Not now not in 2 years but sometime in the future. > > > Werner > > > > Am 05.10.17 um 14:12 schrieb Mike Kienenberger: > > 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 >>>> >>>> >>>> >>>> >>>> >>>> >>> >> > >
