> I do think we should have another library that builds on Elemental2. While > browser compatibility is a lot better, it still isn't perfect and we need > somewhere to collect workarounds for specific issues and add helper > functions to make working with the library easier. >
But then you have the GWT overhead on top of it again. But I tend to agree that a purely generated API can never be that nice to use as a hand crafted one. I have only taken a very brief look at the generated code of the elemental2 snapshot build but I think my major points are: - vendor prefixes. Sticking to standard API and asking devs to polyfill them if needed sounds better to me. Avoids potential API duplication. - only doubles while int would make sense here and there - no use of generics and enums - no packages. Would be nice to have things like dom, crypto, promise, audio, webgl, etc. - often method signature defines Object as return type while I am pretty sure something more concrete would be more appropriate. - obviously no JavaDoc, but it would be nice to have. Especially for people working in a no-internet environment. - edge cases like EventTarget.addEventListener(EventListener) and EventTarget.addEventListener(AddEventListenerListenerCallback) that should be cleaned up Maybe it is worth thinking about providing some patch files in addition to the generator to fix some stuff that are hard to fix inside the elemental2 generator. Given that existing non-prefixed API does not change these patch files should be pretty stable and always applicable. -- J. -- You received this message because you are subscribed to the Google Groups "GWT Contributors" 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-contributors/71f5352a-41dc-4f91-a22b-9a9bb21b8bbb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
