@Peter: Thanks a lot for your comprehensive insight, like always! 👍 One production ready WASM I know is from .NET: https://visualstudiomagazine.com/articles/2020/05/19/blazor-webassembly-3-2.aspx
But I never tried it... [email protected] schrieb am Montag, 25. Januar 2021 um 19:09:00 UTC+1: > Thanks for the insightful reply. You seem to focus on optimization which I > agree is a worthy target. > > I was focusing on development practices and reuse. For example I have > created bindings for jQuery. I would love to just use somebody else's > bindings. But here is the thing. I didn't need jQuery for me or my > application. I needed it for DataTables.net. I created bindings for them > too and jQuery was a requirement. > > Having done the exercise I believe that it is impossible to reuse jQuery > from another source and DataTables.net from another. They have to be > developed in sync or at least first the jQuery and then the DataTables.net > bindings. It looks like a huge waste of effort to me and not very scalable > regarding ecosystem growth if every gwt developer develops his own bindings > every time. > > But what would be a proper solution here? Create a mega project to > coordinate smaller bindings only projects? Provisions have to be taken for > packaging and namespaces in order to avoid collisions and a ton of other > things that are massive headaches. > > Thanks again. > > > > > On Mon, Jan 25, 2021 at 10:35 AM Peter Donald <[email protected]> > wrote: > >> >> >> On Sun, Jan 24, 2021 at 8:17 PM Vassilis Virvilis <[email protected]> >> wrote: >> >>> I asked here one or two times but IIRC the answer was there should be an >>> automatic way to import js libraries. Maybe through DefinitelyTyped >>> typescript https://github.com/DefinitelyTyped/DefinitelyTyped >>> definitions? not sure if it is even possible. >>> >> >> There are a few problems that we became aware of quickly. To get dead >> code elimination / minimization / optimization you really need to have a >> consistent type model for all code within an output target. When we >> experimented with this approach we used the same model that I believe is >> used inside google. i.e. closure typed javascript is the definitive >> representation, java is compiled to closure compiler annotated js via j2cl, >> typescript is compiled is compiled to closure annotated js via tsickle, >> jsinterop-generator converted closure annotated code into jsinterop >> annotated java and then closure compiler was responsible for >> optimization/assembly. >> >> However you could rarely take an off-the-shelf typescript library and >> import it into the mix as tsickle was usually on an older version of >> typescript or the library was not completely typed or it used some >> typescript features not supported by tsickle. This usually meant that the >> library had to be patched and/or was not stripped of unused code and/or was >> not optimized etc. We often ended up writing our own library event when >> there was an equivalent available in the js ecosystem. (Which is no >> different to what we have to do with java-to-js solutions but generally the >> tooling available for long term maintenance is less good for js than for >> java). Even when all the stars aligned we often found that closure could >> not detect some code was unused due to the way js works and so we had to >> patch code so we could eliminate unused code by changing how we used a >> library. This is probably one of the reasons we ended back writing code in >> java. We could not use the existing ecosystem and had to work with a >> limited ecosystem if we wanted high-quality, minimized code . >> >> So while it may be possible to use existing libraries from typescript >> and/or DefinitelyTyped, unless the typing is 100% then bugs will creep in >> and you won't be able to eliminate unused code. Where we are using js >> libraries we tend to write our own bindings or we just rewrite the >> functionality we need in java and get all the benefits provided by the >> compiler. >> >> I am not aware of such a way or at least a roadmap. Do you think that >>> with the WASM target the jsinterop binidings will be more automatic / >>> easier / less manual? >>> >> >> WASM is still a moving target and I haven't tracked it of late ... but >> there were specs that defined the inter module API which would be trivial >> to automatically generate bindings for. There was also primitive tooling >> that did dead code elimination and optimization between modules (by >> essentially removing the unused API ingress and re-running intra module >> optimizer to strip dead code) but I don't know how good it is. I don't know >> if it will ever be possible to do whole application optimization and >> combining into a single module but I am not sure that will be much of a >> problem in practice. At least not for languages that do not have much >> overhead during compilation. >> >> Anyhoo - it will be an interesting time regardless. >> >> -- >> Cheers, >> >> Peter Donald >> >> -- >> > You received this message because you are subscribed to the Google Groups >> "GWT Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/google-web-toolkit/CACiKNc7Z%3DC3F0cXTggkPhPFeh8%3D5M%3DYpE45%3DWfnCWJzSaBFGgw%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/google-web-toolkit/CACiKNc7Z%3DC3F0cXTggkPhPFeh8%3D5M%3DYpE45%3DWfnCWJzSaBFGgw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > > > -- > Vassilis Virvilis > -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/b0058ab1-52f6-48fc-8df0-fcf182e5510bn%40googlegroups.com.
