3 ms·
The move to superdevmode is the nail in the coffin for GWT for me. It has been my go-to framework for the past 5 years. I really love doing everything in Java (
by flavor8 12y ago
The move to superdevmode is the nail in the coffin for GWT for me. It has been my go-to framework for the past 5 years. I really love doing everything in Java (I don't like Javascript, don't particularly enjoy writing HTML, and find the compile time checks of the UI invaluable); some of the core components are clunky to work with, but you can easily write some component libraries that sit on top of GWT and generate elegant HTML. The killer feature is being able to debug UI code in your IDE (specifically, for me, IntelliJ). With the loss of classic dev-mode (mainly due to browsers being a moving target, and the GWT team being too small) that is no longer possible; you now have to interact with the browser's built in debugger, which is qualitatively much worse.
So, I'm on the hunt for a replacement too. It'll still be Java-centric (compiled languages ftw), probably will involve Dropwizard, and ideally will generate much of the Javascript. I don't know if that exists yet though.
- stephen 12y ago> ideally will generate much of the Javascript Just to play devil's advocate, but with any compiled-to-JS language, you're right back to where GWT is with superdevmode: stuck in the browser's debugger. My hope is that with enough "compiled-to-JS" languages (Coffeescript, etc.) becoming popular that browser vendors will build a standard debugging wire protocol, much like the JVM's, which would allow IDE-based debugging of sourcemapped JS code. This project is taking that on for Eclipse, which is a huge challenge and I'm very impressed that they're even attempting it: https://github.com/sdbg/sdbg https://github.com/sdbg/sdbg Given you use IntelliJ, which typically has a much faster turn around on supporting bleeding-edge browser/etc. integration, I would actually except them to get it first.