Hi,
On Thu, May 2, 2019 at 7:02 AM Andrew Kondratev <[email protected]> wrote: > Hi Colleagues! > > Are there any plans about refactoring / modernisation of wicket's front-end > code? > None that I am aware of. > > What comes to my mind: > > - Start using TypeScript for a new code, so we can have type safety on > the front end side as well. TypeScript is also released under apache > license, so I think there should be no licensing issue with this. > Potentially, as a crazy idea Kotlin could also work, but I think > TypeScript > suits better and requires less effort and learning; > I do not see big profit in using TypeScript for Wicket Ajax. Generally I prefer TypeScript over JavaScript, but only for bigger code bases with more often development. wicket-ajax-jquery.js is quite stable in the last several years (since 6.0.0). It is more stable for two main reasons: - we migrated the old vanilla JS code to jQuery based one. Note: the vanilla JS version was fragile due to the browser incompatibilities. - we added a *lot* of JS tests ! IMO using TypeScript won't add much value. It will only make the build process more complex and a bit slower. > - Potentially get rid of jQuery, it's not that useful in 2019 (wicket > has recently dropped legacy IE support); > This has been suggested by someone else several months ago. But AFAIK nothing has been done so far. The good thing is that one can replace wicket-ajax-jquery.js with wicket-ajax-xyz.js in his/her application by using application.getJavaScriptLibrarySettings().setWicketAjaxReference(...). So both implementations could be supported by Wicket for some time with a deprecation cycle for the jQuery based one. These are the requirements I have: - same Wicket.xyz APIs are supported, because this is what the Java code uses - the test suite still passes > - Potentially introduce some modern lightweight front-end framework such > as ReactJS; > What benefits would that bring ? I do not want to use ReactJS just because it is the latest fashion in JS world. > > Sorry if it was already discussed, I searched on issues.apache.org/jira > and > didn't find anything relevant. Just wanted to discuss if something like > this is possible for distant future release. Potentially I can devote a few > hours a week to this. > Thanks for the suggestions! > > Have a nice day, > Andrew >
