You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Werner Punz <we...@gmail.com> on 2019/11/08 14:30:38 UTC
Re: MyFaces reimplementation in typescript
Am 10.10.19 um 12:10 schrieb Werner Punz:
> Hi, this is not really official so its done when its done, but last
> friday I have started to pick up my work regarding the
> reimplementation of jsf.js for myfaces in typescript which I started a
> while ago but put on hiatus due to more pressing issues.
Another status update. I have covered now everything except multipart
requests. Also I have updated to typescript 3.7+ due to the elvis
operators they just added, that way I could reduce some usage of my own
framework which partially emulated an elvis propert resolution, a little
bit and replace it with in language constructs.
Lots of tests already are implemented and cover now the entire
implementation (test coverage itself still is a tad too low for some parts)
You can see it here https://imgur.com/a/cpwyucP,
So what is left:
Next week I probably will dump the codebase the first time into my
browser based integration tests, to see how it works and if it works for
the first time and then also the first checks against IE11 will be
performed.
After that work on xhr, then Udo requested to have a talk
about what we can do about shadow dom support on the 13th
of december.
So I expect a first implementation I can commit into the myfaces
codebase sometime early next year (take this with a grain of salt)
Might be ideal to have it in for 3.0.0-M2 so that the users can start to
field test it.
Re: MyFaces reimplementation in typescript
Posted by Werner Punz <we...@gmail.com>.
Biweekly update...
Sorry for that, but I was bound by work last week, so I was able
to pick up the work today in the morning.
I debugged some minor issues Udo discovered out today. Thanks Udo
for doing a session here in Vienna with me.
It now works more or less in the Tobago Codebase he is working on.
So please try to use the implementation and send me bugs on github (for the
time being until i have moved the code into myfaces then things will
move over to jira).
After christmas I will start a discussion on how to integrate the code
into myfaces. So that we can get the code into 3.0-M2 or MyFaces Next M2
or however we are going to call it.
Werner
Am 29.11.19 um 12:53 schrieb Werner Punz:
> Weekly update:
>
> Function complete:
>
> The new codebase now is function complete, I just added an alpha-1 tag.
> Work is still done regarding improving the code a little bit
> improving the jsdoc comments and also Udo wants to get something
> regarding shadow dom updates in.
>
> But we are now on the same function level except for the dropped stuff
> as the old implementation.
>
> So what does that mean? The code is not fully ready to be merged into
> the myfaces codebase but you can start to test it by dropping it in
> yourself.
>
> In https://github.com/werpu/jsfs_js_ts/tree/master/dist/window
> you can find builts for the development and production environments.
> Please drop it in and give it a testrun, any feedback, negative,
> positive, bugs, is appreciated.
>
> Cheers
>
> Werner
>
>
Re: MyFaces reimplementation in typescript
Posted by Werner Punz <we...@gmail.com>.
Weekly update:
Function complete:
The new codebase now is function complete, I just added an alpha-1 tag.
Work is still done regarding improving the code a little bit
improving the jsdoc comments and also Udo wants to get something
regarding shadow dom updates in.
But we are now on the same function level except for the dropped stuff
as the old implementation.
So what does that mean? The code is not fully ready to be merged into
the myfaces codebase but you can start to test it by dropping it in
yourself.
In https://github.com/werpu/jsfs_js_ts/tree/master/dist/window
you can find builts for the development and production environments.
Please drop it in and give it a testrun, any feedback, negative,
positive, bugs, is appreciated.
Cheers
Werner
Am 22.11.19 um 17:45 schrieb Werner Punz:
> The usual weekly update...
>
> Changes can be seen as usual on the github project:
>
> https://github.com/werpu/jsfs_js_ts
>
> Following
>
> all my integration tests now pass
> IE11 support now is in
>
> I now also have relative concrete code and performance numbers
>
> dev build: unmangled roughly 250 kbypte,
> prod: compressed es5 level 89Kbyte,
> if you pull the es level up to es2015, 69kbyte.
> Higher ES Levels than 2015 don´t have a huge impact anymore.
>
> Speed, roughly 25% slower than the old code, which was highly optimized
> and low level
> on an extreme case with a form with a few hundred inputs (my spreadsheet
> test) on chrome.
> IE11 might have a higher hit, not tested yet.
>
> The reason is a higher abstraction I have. Instead of operating directly
> on nodes and setting the attributes straight on dom
> I now operate on JQuery like monads and selectors which then route into
> the dom.
> Instead of looping over elements, I stream, flatmap map and reduce them.
> Instead of pulling the map and having asynchronous callbacks I work now
> with
> promises and shim them if not provided.
>
> All this improves readability but sacrifices some performance.
> Given that normally the performance of the ajax part is not really where
> the problem is,
> I can live with that for the time being, should the users complain
> (which I frankly doubt given that jquery and other frameworks
> usually provide bigger slowdowns), then I could have another round of
> optimizations.
>
> I guess 5-10% still is possible without sacrificing readability too much.
>
> The plus side is, the code is very readable now and we can ramp
> up Ecmascript versions on the fly without a single code change.
>
> Happy weekend
>
> Werner
>
>
>
>
>
>
>
>
> Am Fr., 15. Nov. 2019 um 16:24 Uhr schrieb Werner Punz
> <werner.punz@gmail.com <ma...@gmail.com>>:
>
> Another small update...
>
> 112 Tests atm (including the base framework)
>
> and the first 9 of my around 18 integration tests now pass properly,
> have not looked to deeply into the others so I am not sure how many
> really still fail atm.
>
> The build now also works on windows, the reason for that was, that I
> have to send in my Mac for repairs soon (keyboard), so I had to move
> the
> build over to the desktop computer and for testing ie11 doing it on
> Windows 10 makes perfect sense.
>
> Also the viewstate handling now got a major cleanup and is very readable
>
> https://gist.github.com/werpu/f46ccb54ce89acc0df933050df35f3cf
>
> I still postpone the eval and viewstate to the post update processing
> phase on the client
> this has never caused any troubles with the old implementation so I
> keep
> it, it just now is cleaner.
>
> In the example the viewstate is stored and then after all udpates are
> performed the viewstate is applied by the second method.
>
>
> So what is still pending...
>
> a) First all my 18 integration tests must pass and I have to convert
> parts of them to permanently integrated unit tests where it makes sense.
> (just ported the test for the viewstate handling over into a unit test)
>
> b) I have to get the code then running on the only supported legacy
> browser (IE11)
> it should theoretically work with a bunch of fixes, practically I
> probably have to change the
> packaging format and other smaller tweaks.
>
>
>
>
>
Re: MyFaces reimplementation in typescript
Posted by Werner Punz <we...@gmail.com>.
The usual weekly update...
Changes can be seen as usual on the github project:
https://github.com/werpu/jsfs_js_ts
Following
all my integration tests now pass
IE11 support now is in
I now also have relative concrete code and performance numbers
dev build: unmangled roughly 250 kbypte,
prod: compressed es5 level 89Kbyte,
if you pull the es level up to es2015, 69kbyte.
Higher ES Levels than 2015 don´t have a huge impact anymore.
Speed, roughly 25% slower than the old code, which was highly optimized and
low level
on an extreme case with a form with a few hundred inputs (my spreadsheet
test) on chrome.
IE11 might have a higher hit, not tested yet.
The reason is a higher abstraction I have. Instead of operating directly
on nodes and setting the attributes straight on dom
I now operate on JQuery like monads and selectors which then route into the
dom.
Instead of looping over elements, I stream, flatmap map and reduce them.
Instead of pulling the map and having asynchronous callbacks I work now
with
promises and shim them if not provided.
All this improves readability but sacrifices some performance.
Given that normally the performance of the ajax part is not really where
the problem is,
I can live with that for the time being, should the users complain
(which I frankly doubt given that jquery and other frameworks
usually provide bigger slowdowns), then I could have another round of
optimizations.
I guess 5-10% still is possible without sacrificing readability too much.
The plus side is, the code is very readable now and we can ramp
up Ecmascript versions on the fly without a single code change.
Happy weekend
Werner
Am Fr., 15. Nov. 2019 um 16:24 Uhr schrieb Werner Punz <
werner.punz@gmail.com>:
> Another small update...
>
> 112 Tests atm (including the base framework)
>
> and the first 9 of my around 18 integration tests now pass properly,
> have not looked to deeply into the others so I am not sure how many
> really still fail atm.
>
> The build now also works on windows, the reason for that was, that I
> have to send in my Mac for repairs soon (keyboard), so I had to move the
> build over to the desktop computer and for testing ie11 doing it on
> Windows 10 makes perfect sense.
>
> Also the viewstate handling now got a major cleanup and is very readable
>
> https://gist.github.com/werpu/f46ccb54ce89acc0df933050df35f3cf
>
> I still postpone the eval and viewstate to the post update processing
> phase on the client
> this has never caused any troubles with the old implementation so I keep
> it, it just now is cleaner.
>
> In the example the viewstate is stored and then after all udpates are
> performed the viewstate is applied by the second method.
>
>
> So what is still pending...
>
> a) First all my 18 integration tests must pass and I have to convert
> parts of them to permanently integrated unit tests where it makes sense.
> (just ported the test for the viewstate handling over into a unit test)
>
> b) I have to get the code then running on the only supported legacy
> browser (IE11)
> it should theoretically work with a bunch of fixes, practically I
> probably have to change the
> packaging format and other smaller tweaks.
>
>
>
>
>
>
Re: MyFaces reimplementation in typescript
Posted by Werner Punz <we...@gmail.com>.
Another small update...
112 Tests atm (including the base framework)
and the first 9 of my around 18 integration tests now pass properly,
have not looked to deeply into the others so I am not sure how many
really still fail atm.
The build now also works on windows, the reason for that was, that I
have to send in my Mac for repairs soon (keyboard), so I had to move the
build over to the desktop computer and for testing ie11 doing it on
Windows 10 makes perfect sense.
Also the viewstate handling now got a major cleanup and is very readable
https://gist.github.com/werpu/f46ccb54ce89acc0df933050df35f3cf
I still postpone the eval and viewstate to the post update processing
phase on the client
this has never caused any troubles with the old implementation so I keep
it, it just now is cleaner.
In the example the viewstate is stored and then after all udpates are
performed the viewstate is applied by the second method.
So what is still pending...
a) First all my 18 integration tests must pass and I have to convert
parts of them to permanently integrated unit tests where it makes sense.
(just ported the test for the viewstate handling over into a unit test)
b) I have to get the code then running on the only supported legacy
browser (IE11)
it should theoretically work with a bunch of fixes, practically I
probably have to change the
packaging format and other smaller tweaks.
Re: MyFaces reimplementation in typescript
Posted by Werner Punz <we...@gmail.com>.
Am 08.11.19 um 15:30 schrieb Werner Punz:
> Might be ideal to have it in for 3.0.0-M2 so that the users can start to
> field test it.
>
>
Small update, filesizes
67054 Nov 11 20:04 jsf.js
17095 Nov 11 20:04 jsf.js.br
19503 Nov 11 20:04 jsf.js.gz
327790 Nov 11 19:28 main.js.map
There might be some possibility to reduce the code further more
but not without sacrificing readability by removing parts
of the underlying framework (which is bundled in)
I guess we can live with that. I also enabled extra
build outputs with brotli and gzip compression.
You can see those sizes there, we should think about
serving those instead of the raw js file in prod.
(gzip is ie11 supported, brotli in the newest browsers)
Cheers
Werner