Hi All, After some reading I decided that I want to try to set up a new group of behaviours similar to Wicket's Ajax ones, but using Fetch API and no eval/Function. https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API
Technologywise I think I'll stick with ES modules and maybe Flow type checker. I'll produce a prototype with simple behaviours like OnChangeAjaxBehavior. Cheers, Andrew пн, 20 мая 2019 г. в 09:18, Martin Grigorov <[email protected]>: > Hi Andrew, > > On Fri, May 17, 2019 at 4:38 PM Andrew Kondratev <[email protected]> > wrote: > > > I'd like to conclude this discussion to start a new one. > > > > This JavaScript looks like 2005 and indeed it is. It is yesterday. > > What I proposed to do had to be started in 2012 to be nice and stable > > today, it will also be yesterday soon. > > > > Yes, this is how it works in JavaScript world - by the time you are ready > to go in production your choice of library/framework is already replaced by > the new fancier one :-) > > > > I particularly don't like all this jQuery and evals and everything > chunked > > > > jQuery did and still does a LOT for the Internet! > All statistics show that jQuery usage in the wild leads by a lot any other > JS frameworks. > > > > into one file. Unfortunately evals it's a nature of this part of a > wicket, > > components do return arbitrary JavaScript to be executed, we simply can't > > make developers to rewrite all the code they created for wicket-ajax. > > > > Wicket is server-side framework. The applications use > AjaxRequestTarget#append/prependJavaScript() to exectute whatever they need > in the browser. > The only way to do this is by using `eval` (or Function, but I still have > to retry to see which use cases didn't work). > CSP says that `eval` is bad, but the code that is eval-ed comes from the > application, so it is trusted. It would be a problem if user input is > blindly eval-ed. > > > > > > I think I was a bit stuck in yesterday, I didn't think that today 85% of > > browsers do already support es6 modules, they can simply work without any > > transpilation. At least in development environment. > > > > Just to give you a contra opinion - Apache Tapestry decided to follow the > fashion and some years ago they moved from JS to CoffeeScript. I guess you > understand how they feel today about this decision :-) > Today TypeScript is the new CoffeeScript (but better!) but as you/we said > earlier - tomorrow something else will replace it, maybe pure ES with ES > modules. > All we need at the end is the JavaScript code that enables Wicket > Ajax/WebSocket support. > > As we mentioned few times in this mail thread wicket-ajax.js is quite > stable in the last several years, mostly thanks to jQuery and the JS unit > tests! > So, moving to a modern build would not improve much the user experience. > Me, as a Wicket developer, would be more happy to work with modern > technologies, like TypeScript, but me, as a user, I don't really care which > build tool Elasticsearch (Gradle) or Tomcat (Ant) use. They both provide > their value and I use them for it, not because they are built with > Gradle/Ant/Sbt/Bazel/... > > > > So I suppose wicket-ajax-jquery should be left alone. What we can do > > > > Sven already simplified it a bit and said that he will work on jQuery-free > version. So, there is a progress! And it is thanks to you! > I hope this rejection to move to TypeScript will not let you down and you > will stay around and keep pushing us to improve Wicket in any direction you > see room for improvements! > > > > instead is to create a new generation of behaviours server with a > > different javascript core, using es6 and whatever technologies of > > today/tomorrow we like, browsers will support it to the moment when it > will > > be production ready. > > > > What I imagine this could be some kind of RPC without a need to eval > > arbitrary code, but rather reference previously registered code. > Currently > > it doesn't even have to be in wicket's code base nor to depend on > > particular wicket version. > > > > I'm going to do some reading before rushing headfirst into this. I'll > > appreciate any links, advises and architecture recommendations. Maybe > such > > stuff already exists and I'm just wasting time. > > > > Google Web Toolkit (GWT) and Vaadin are based on RPC JS <-> Java. Maybe > this is what you are looking for. > > > > > > Have a good weekend, > > Andrew > > > > Have a great start of the week! > > Martin > > > > > > пт, 17 мая 2019 г. в 23:07, Martin Grigorov <[email protected]>: > > > > > Hi, > > > > > > The benefits I see are: > > > 1) the big file (~2500 lines) would be split into several modules. This > > > could be achieved without switching to TypeScript > > > 2) with TypeScript the code will be type-safer than now. This also > helps > > > for better documentation of the expected parameters (e.g. the Ajax > > > attributes) but only if one can read TypeScript signatures, e.g. > > mapOfMaps: > > > {[key: string]: {[innerKey: string]: string}} - this is Map<String, > > > Map<String, String>> > > > > > > The drawback as I already said is the eventual problems with > sourcemaps. > > > > > > On Fri, May 17, 2019 at 1:31 PM Sven Meier <[email protected]> wrote: > > > > > > > Hi, > > > > > > > > as one of the few maintainers of that code I'm not in favor of this: > > > > IMHO it is not worth to introduce a new language and to complicate > the > > > > build process just to generate ~2500 lines of JS code. Code which is > > > > closely tied to the browser, pretty stable, thoroughly tested and > > *almost > > > > never seen much less touched by anyone else than the committers*. > > > > I really appreciate the work you have put into this, but I don't see > > any > > > > advantage. I'd rather reduce and improve the current code in > > JavaScript. > > > > > > > > I don't want to be a spoilsport, but on an official vote to switch to > > > > TypeScript I will give a -0 at best. > > > > > > > > Regards > > > > Sven > > > > > > > > > > > > -- > > > > Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet. > > > > > >
