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. I particularly don't like all this jQuery and evals and everything chunked 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.
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. So I suppose wicket-ajax-jquery should be left alone. What we can do 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. Have a good weekend, Andrew пт, 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. >
