Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Development" <dev@myfaces.apache.org>
MIME-Version: 1.0
In-Reply-To: <or4md1$2l5$1@blaine.gmane.org>
References: <or4md1$2l5$1@blaine.gmane.org>
From: Thomas Andraschko <andraschko.thomas@gmail.com>
Date: Thu, 5 Oct 2017 09:43:06 +0200
Message-ID: <CAAuOd=XB+pYNCEGc020fs+-i2qMNH0d6KbjO+Y4zhPDEaFSoRg@mail.gmail.com>
Subject: Re: jsf.js post 2.3 plans
To: MyFaces Development <dev@myfaces.apache.org>
Content-Type: multipart/alternative; boundary="001a113efa8e078322055ac7e013"
archived-at: Thu, 05 Oct 2017 07:53:02 -0000

--001a113efa8e078322055ac7e013
Content-Type: text/plain; charset="UTF-8"

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.punz@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
>
>
>
>
>
>

--001a113efa8e078322055ac7e013
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>Hi Werner,<br><br></div>big +1 for doing a =
completely new jsf.js!<br><br></div>Basically it would be really great to u=
se another lang as plain js.<br></div>But there is also another downside: m=
ost webdevelopers and commiters of MyFaces are fimilar with plain js but ma=
ybe not with TypeScript or else.<br><div><div>But i think we should do it i=
f can we can easily integrate it somehow in our maven builds.<br>My persona=
l opinion is that i would prefer plain js if the developers must install no=
dejs etc. on their machines. If everything is done by maven in the backgrou=
nd, it&#39;s ok for me.<br></div><div><br>As you already said, we actually =
must avoid dependencies like kotlin.js and jquery.js - thats a no go and al=
so not really required.<br><br></div><div>Regards,<br></div><div>Thomas<br>=
</div><div><br></div><div><br></div></div></div><div class=3D"gmail_extra">=
<br><div class=3D"gmail_quote">2017-10-05 9:19 GMT+02:00 Werner Punz <span =
dir=3D"ltr">&lt;<a href=3D"mailto:werner.punz@gmail.com" target=3D"_blank">=
werner.punz@gmail.com</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi =
guys<br>
<br>
<br>
I just wanted to start a discussion on how we are going to proceed with the=
 jsf.js codebase.<br>
The issue is following:<br>
<br>
Our codebase which currently is adapted by me for 2.3 is rather old.<br>
It by now is around 9-10 years old and back then most of the stuff I did ma=
de sense<br>
a) The library needed to be self contained<br>
b) There were an awful lot of browsers in use, which did not adhere to any =
standards whatsoever<br>
c) There was no real inheritance system available just the prototype system=
 which is one level below inheritance by allowing to access the class/objec=
t tree and manipulate it on the fly<br>
<br>
So what I did was following<br>
Implement my own class system for not having to deal with prototype inherit=
ance all the time<br>
Since I needed to be self contained integrating a library like JQuery (whic=
h also was it its infancy at that time) was out of the question<br>
due to possible conflicts. There also was no widespread support<br>
for querySelector on node level some browsers had it some browsers<br>
had other workarounds to speed the dom node lookup up.<br>
<br>
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.<br>
<br>
To the worse there were significant differences in dom and xml handling<br>
between the various browsers out in the wild compared to the already define=
d standards (I am speaking of you IE and mobile browsers in use back then)<=
br>
<br>
So in the end I ended up with a codebase which is about 40-50% there just t=
o 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.<br>
<br>
Again all of this made sense back then...<br>
<br>
<br>
Lots of things have been changed in those 10 years and now most of the thin=
gs do not make sense anymore.<br>
<br>
a) We have saner meta languages which allow to compile to javascript, follo=
wing candidates come to my mind<br>
<br>
- Typescript, a language which I amn very familiar with due to my day to da=
y work<br>
- Coffeescript ... not very familiar with that one<br>
- Kotlin... yes that one also has a javascript target compiler<br>
<br>
We definitely should opt for a meta compiler instead of pure js.<br>
The reasons are many, and I can speak here atm only for Typescript<br>
<br>
- You can change ecma script levels on build level<br>
- You can change the package management system in build level<br>
- You get additional coding security by having the apis fortified at least =
with some types instead of doing constantly your manual asserts<br>
- In the end the Meta language codebase is way cleaner than the original on=
e<br>
<br>
<br>
The downside is<br>
<br>
<br>
at least for typescript the maven integration is non existent, there is a m=
aven clientside plugin which downloads the entire node js chain onto your m=
achine within a build, but my guess is we do not need to do this<br>
for the apache integration builds, because in the end we just need the js c=
odebase. We can add special dev profile which enables the client side build=
 to build the js files.<br>
<br>
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 ca=
n probably bypass that. I need to have a serious look at it.<br>
<br>
The plus side probably is that it has decent maven support and a perfect ID=
E support on the Jetbrains IDEs. (Dont get me wrong the IDE support<br>
of Typescript also is very good on those, I use it on a daily base)<br>
<br>
<br>
Browser support:<br>
<br>
Since mobile browsers are up to rather recent standards nowadays the proble=
m is the desktop which at least in a corporate environment is moving really=
 slowly (I wonder corporations are really cautious regarding security and y=
et often use stone old often outdated not updated anymore, browsers - but t=
hat is just a snarky sidenote). But still there things have gotten better.<=
br>
<br>
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 mu=
ltiform requests instead of the iframe hack I had to introduce for jsf 2.2.=
<br>
<br>
I would prefer to have IE11 as baseline, given that most corporations proba=
bly 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 supp=
ort.<br>
<br>
By mildly adding small external libraries and avoiding shims<br>
we might get a small query monadish api on top of node.selectorAll like jqu=
ery.<br>
<br>
I still would avoid to integrate jquery because we have a core lib<br>
so everything integrated needs to be small. We do not have the luxury of fo=
r instance Prime Faces which can require or bundle a huge lib like JQuery a=
nd JQuery UI.<br>
<br>
Also we definitely would need promises (again rip the code out of a proven =
shim lib=C2=A0 but do not shim it, if it is not supported by the browser na=
tively)<br>
<br>
So my proposal is, after 2.3 I will start with a reimplementation which mig=
ht take some time in a saner environment and with a newly defined baseline.=
<br>
And once I am done we can drop it in as alternative jsf.js codebase<br>
for the users (we still keep the old one for 2.3)<br>
And for 2.4 upwards we will drop the legacy codebase entirely and just<br>
use the new reworked and cleaned up one.<br>
<br>
<br>
Just a little bit of food for discussion.<span class=3D"HOEnZb"><font color=
=3D"#888888"><br>
<br>
Werner<br>
<br>
<br>
<br>
<br>
<br>
</font></span></blockquote></div><br></div>

--001a113efa8e078322055ac7e013--