Hacker News Reader

Hacker News

Comment by rdwallis | Hacker News Reader

Parent Full thread

rdwallis

In gwt, reflection isn't supported because it makes it hard for the compiler to do dead code elimination.

Supporting reflection might make it difficult to reduce the compile size of the javascript code in the future.

Or does c# reflection work differently from java?

Looks great by the way.

View on HN

C# / .Net will have the same issue, but when they developed native compilation for windows phone apps they added a concept of a runtime definition file that lets you control how much needs to be retained for reflection: http://msdn.microsoft.com/en-us/library/dn600639%28v=vs.110%...

The native compilation technology is moving over to normal .Net and I would imagine the runtime definition file could be used for javascript transpiling tree-shaking as well.

Thanks on first glance that looks like a much better solution than gwts' generators.

My implementation in GWT lets you control how much is retained by using annotations to control the retention level. It even gives you the option to defer loading reflection until a future code split, such that you only download the extra bytes for reflection support when you will actually need it. See above for link.

I actually have fully functioning reflection in GWT in a branch of my own, and will be getting it merged to master shortly after the GWT.create conference.

https://github.com/WeTheInternet/xapi/tree/master/gwt/gwt-re...

If you want to support complete reflection across the board it greatly swells compile size, but I have made it so you can be selective about what supports reflection, in order to avoid code bloat.

Wow the whole xapi project is great, thanks for the link.

How much do the threads actually work yet? How slow are they?

Threading support in gwt is still just a glorified Timer. I haven't had the time / a reason to actually implement a multi-compile to web worker to make them function correctly. If you can think of a good test project, I'd be glad to add it to my backlog after the gwt.create conference, where I'll be speaking about web components, java 8 and JsInterop. Basically, in my latest projects, about 90% of the implementation is annotated interfaces and default methods that get stitched together into web components...

I'm not sure how the other transpilers expose native javascript, but in the future of Gwt, interacting with plain javascript is dead simple; you get the best of both worlds; typed java code, and low-level js performance. The JsInterop stuff makes wrapping native js super easy, just define an interface that matches the JS, and it "just works" (tm). Even web components, just create an annotated interface, define default methods, and the compiler attaches them to custom element definitions. I could go on and on, but I'll save it for the correct forum (i.e., the gwt.create conference). :D

There is a project called gwt-ns that supports Web Workers (https://code.google.com/p/gwt-ns/)

Real threading would have to use ES6 yield/generators to translate an entire thread into a spawn loop so that async/await blocks can be emulated.

Reply on news.ycombinator.com