Thanks for detailing the future of browser and how jsf cope up with it.
I was using mojarra for my application and the commandLink was not working due
to script problem.So I switched to myfaces and we got some problem with
repeated ajax calls. (Myfaces 4160).
Are we syncing with mojarra regarding the technology to be used with the
jsf.js, entire scripting arena.Not sure spec say anything about the technology
used for scripting.
Thanks & Regards,Dora Rajappan.
On Thursday, October 5, 2017, 11:32:23 PM GMT+5:30, Thomas Andraschko
wrote:
yep. +1 for IE11 in JSF.next
2017-10-05 14:36 GMT+02:00 Werner Punz :
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
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 :
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 th
