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. > > >
