I am not very eager anymore to use plain js
especially since we have to target ES5.
Even if we use ES6 we need to recompile back into ES6.
The reason why I moved the codebase over to Typescript
from my day to day work, was that the language thanks to Angular2
got enough foodhold to be used by a wider audience and it
really improves the code a lot thanks to rather sane extensions
to the Javascript.
In fact I personally think, a bigger JS Codebase is almost
unmaintainable in the long term if you dont move it to a higher level or
pull some third party libs in thanks to the dynamic untyped nature of
the languate. You still can cover a lot of issues by extensive unit
testing, but still the language is totally untyped and allows you
literally to change anything anywhere.
And Typescript is close enough and well documented enough that moving up
is a no brainer.
Typescript is more or less just a JavaScript ++.
In the end the result always is javascript, so even if a bug is just
investigated and sent back on plain javascript level it is easy to trace
it back to the typescript origins (either via mapping files which show
the bug straight in the browser as typescript or simply by looking up
the code)
As for Kotlin, this one also gets a wide adoption atm, thanks to Android
but i have a little bit of stomac ache due to the kotlin.js issue
and due to the fact that you cannot trace the js code back as easily as
you can do on the typescript side.
Also it is a totally different abstraction layer.
Am 05.10.17 um 09:43 schrieb Thomas Andraschko:
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 <[email protected]
<mailto:[email protected]>>:
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
