Re: [gwt-contrib] Re: Elemental 2?

Elemental2 just generates code from whatever WebIDLs or Typescript headers you feed it. If you want to knock out certain APIs, just comment them out in the IDL file. On Wed, May 18, 2016 at 2:10 PM, Ming-Yee Iu wrote: > It would also be nice if Elemental 2 also has an easy way to

Re: [gwt-contrib] Re: Elemental 2?

It would also be nice if Elemental 2 also has an easy way to selectively knock out certain fields/methods in the code generator. I don't know how many times I'll be using code completion and accidentally end up writing something like div.setInnerText("click me") because innerText is

Re: [gwt-contrib] Re: Elemental 2?

I agree with you on Java idiomatic API design, but the first version won't be so specialized, we will have to hand curate overrides of the auto-generated APIs, it's not really possible to automate this. On Wed, May 18, 2016 at 10:22 AM, Ming-Yee Iu wrote: > Is it possible to get

Re: [gwt-contrib] Re: Future direction for common JS api's

Interesting; I had not seen JSweet before. The javac -> TypeScript -> JS approach is surprisingly parallel (albeit with different selections) to J2CL's ecj -> closure -> JS. - Stephen On Wed, May 18, 2016 at 8:50 AM Jens wrote: > Given that Elemental 2 is developed

Re: [gwt-contrib] Re: Elemental 2?

Is it possible to get some hints about what's cooking for Elemental 2? Is the code generator still going to be Python or is it going to be rewritten in Java? I found modifying the Python code generator when I wanted to change Elemental 1 to be annoying. Is the output going to be a direct

[gwt-contrib] Re: Future direction for common JS api's

Given that Elemental 2 is developed behind closed doors, I would guess it can take TypeScript definition files and/or some IDL input to generate JS APIs for GWT / J2CL. That should cover nearly all Web APIs. IMHO TypeScript definition files would be preferred because there are tons of them on

[gwt-contrib] Future direction for common JS api's

I am at the point in my GWT-React project where I need to come up with a future proof way of handling low level server communication. I was contemplating implementing the new Fetch API (with polyfills for older browsers). This would also need the promise API. The question I have is what will