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...
vas...@gmail.com 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 <pe...@realityforge.org> wrote:--On Sun, Jan 24, 2021 at 8:17 PM Vassilis Virvilis <vas...@gmail.com> 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 google-web-tool...@googlegroups.com.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.
--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 google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/b0058ab1-52f6-48fc-8df0-fcf182e5510bn%40googlegroups.com.
No comments:
Post a Comment