SuperDevMode not so super

[StefanR]

In a larger GWT multi project app and it took me several hours to get the new SuperDevMode running (I found this video very helpful).

Now, I'm a bit disappointed about the coolest new feature of 2.5 and I wonder if I have missed something.

• Compilation is slow. It takes between 1 and 2 minutes plus the bootstrap time of my server app. The app has sth above 20k LOC and heavily uses RequestFactory and GIN code generators, maybe that's the reason? So overall startup performance is worse than with standard DevMode.
• Code changes require a recompile. In DevMode non-structural changes are applied automatically by the Eclipse Debugger.
• Debugging the code in the Browser is ... hm, it works. But honestly, nothing compare to a IDE debugger. Browsing through the source tree in Chrome is a pain with thousands of classes.
• GWT CodeServer is very resource intensive. During compilation, I cannot use my machine for anything else. If it's running it takes more than 1GB of RAM.

Is anyone successfully using SuperDevMode for larger apps?

[Filipe Sousa]

I'm facing the same problems as you. But I'm using GIN and GWT-RPC

[maticpetek]

I understand you pain. Our application is around 150k LOC of client code, we are using only GWT-RPC, we have big problems with development productivity and unfortunately SuperDevMode did not bring anything useful for us. 

[Paul Stockley]

Our project is about 35,000 lines of client and server code. We don't use RPC or request factory because we have our own RPC mechanism. We do have quite a lot of UI binder files. Super dev mode recompiles take between 6 to 8 seconds. So it sounds like the generators are your problem. For some types of generators, they run every compile even if you haven't changed any related code. They are aware of the issue and will be looking into it for a future release.

[Joshua Kappon]

Also facing the same issue.

[Paul Robinson]

I have about 250kloc, lots of RPC and no generators or UI binder.

With decent hardware, a recompile is about 7-8 seconds. With a 3-4 year old computer, it was taking about 20 seconds.

Paul

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/q1lGr7hhCo4J.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[Daniel Mauricio Patino León]

It's to sad that if i want to change a small line of code, like css on uibinder i need to recompile all the project.

Plus JSR 303 Validation annotations aren't compiled in superdev mode i will put a issue

[Clint Gilbert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/14/2012 09:47 AM, Andrew Mackenzie wrote:
>
> IMHO, SuperDev is not the fix for this, and GWT is exploring a
> path (Source maps, browser debug, etc) that breaks one of the best
> and distinguishing points of GWT.
>

Agreed. The inability to debug using an IDE makes super dev mode a
non-starter for me.

SDM solves a problem for the browser plugin maintainers, which I
completely understand, but it creates problems for users like me.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlCj8lEACgkQ5IyIbnMUeTvFtwCfcMOnIYxXwTsiZu87tDuT1yrJ
pL0AoKi8fJKLYPaOohoR3PzZdRaEWWUO
=bIqT
-----END PGP SIGNATURE-----

[emurmur]

I am really enjoying SuperDevMode.  My desire is to program to the browser, not to a high-level GWT api.  I've build an MVP framework on top of lower level browser api's, so no UI Binder, no request factory, no GWT widgets.  Compiles are fast.  Debugging in Chrome works well.  There are some things to get used-to, and I generally prefer the IDE debugger's ui, but debugging the actual code in the actual execution environment at full speed is a big benefit.  I can make changes to html or css and simply reload the page and I'm debugging again in 2 seconds.  If I step a little too far in the code, I can reload and I'm debugging again in 2 seconds.  If I change a line of Java code, I need to recompile, but that takes about 5 seconds in my app.  So SuperDevMode and source maps are ideal for me.  If feel like I'm getting the productivity of a Javascript work flow and the structure and code-reliability of Java.

Ed

[Clint Gilbert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm glad SDM works for you; the ability to see HTML or CSS changes
quickly is definitely a pro.

But losing the IDE debugger is a big con. No browser debugger that
I'm aware of matches the functionality of Eclipse or IntelliJ. Losing
the ability to debug the client and server from the same 'place' is
also a con.

I'd rather be kept as insulated as possible from the javascript
environment, at least by default.

> -- You received this message because you are subscribed to the
> Google Groups "Google Web Toolkit" group. To view this discussion
> on the web visit

> https://groups.google.com/d/msg/google-web-toolkit/-/30Xavun1iLYJ.

> To post to this group, send email to
> google-we...@googlegroups.com. To unsubscribe from this
> group, send email to
> google-web-tool...@googlegroups.com. For more options,
> visit this group at
> http://groups.google.com/group/google-web-toolkit?hl=en.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlCkHU0ACgkQ5IyIbnMUeTu+CgCeIUSy71ESOJp0bx2QJ3ky+W1Q
VTIAoKKg/DCWuGXWPd8LZsMsppqwUZfU
=YTPA
-----END PGP SIGNATURE-----

[Chris Lercher]

In my opinion, Super Dev Mode is an awesome addition to Dev Mode.

It fits in my workflow:

- For super-fast changes in client-side code (to fine-tune styling etc.), I use Dev Mode, with a Debugger attached, and a simple button on the page that rebuilds just the widget I am tuning. Nothing beats that in speed (<<1 sec reload).

- When trying the real app without the intention to make client-side changes, I use Production Mode.

- When I plan to make some bigger code changes e.g. to a Dialog (structural changes which a Java Debugger couldn't handle anyway), I use SuperDevMode, displaying only the Dialog. This gives me a quick UI and very high realism.

The only problem I see is, that Super Dev Mode has been officially described as a "replacement" for Dev Mode. I don't know, if that's such a good idea. I agree with Andrew Mackenzie, that it would be basically good enough to have one browser (per OS) available for DevMode (reminds me of the old Hosted Mode). "Hosted Mode" for one browser + Super Dev Mode for all browsers would give me most of what I need. I imagine, that it would also allow "Hosted Mode" to be more optimized than the current Dev Mode (somehow I always had the feeling, that the old Hosted Mode reacted quicker than Dev Mode, but I could be wrong).

I understand, that keeping the browser plugins up to date is not an easy task. And the current Dev Mode plugin situation is not good:

- The Firefox Plugin *seriously* leaks memory (http://code.google.com/p/google-web-toolkit/issues/detail?id=7648), 

- Chrome plugin doesn't always work with latest Chrome (which is ok on Mac thanks to Chromatic, but it's hard to get old versions of Chromium on Linux)

So currently, it's impossible to recommend *any* browser to use with DevMode on Linux (and also somewhat difficult for Windows). Which is a situation that should be resolved soon (maybe by fixing the Firefox plugin leak). I think, it should take priority over Super Dev Mode - because even if it maybe actually replaces Dev Mode someday, there's still a long way until it's fully there.

[Oliver Krylow]

We are also enjoying super death mode as it allows debugging mobile applications directly on the device . This is a huge time saver and while I agree that having the debugger not integrated is inconsistent for java devs but really, after spending 5 minutes with the chrome debugger you will find most of the features you are used to ,if not even more. It is really not such a big deal, rather a minor inconvenience.
Also the promise of gwt is NOT to abstract the browser or web technologies and semantics away from you, but rather to bring good and structured workflow and tooling to web development .

Oliver

[Thomas Broyer]

On Thursday, November 15, 2012 2:34:12 AM UTC+1, Oliver Krylow wrote:

We are also enjoying super death mode as it allows debugging mobile applications directly on the device . This is a huge time saver and while I agree that having the debugger not integrated is inconsistent for java devs but really, after spending 5 minutes with the chrome debugger you will find most of the features you are used to ,if not even more. It is really not such a big deal, rather a minor inconvenience.
Also the promise of gwt is NOT to abstract the browser or web technologies and semantics away from you, but rather to bring good and structured workflow and tooling to web development .

+1000 

[Thomas Broyer]

On Thursday, November 15, 2012 1:14:56 AM UTC+1, Chris Lercher wrote:

The only problem I see is, that Super Dev Mode has been officially described as a "replacement" for Dev Mode. I don't know, if that's such a good idea.

With browsers all adding remote debugging support (except IE maybe) and hindering plugins (for good reasons), I believe it *is* a good idea in the long run: SourceMaps could then be used by your IDE so you could put breakpoints in your editor window.

I have the feeling that JetBrains might be working on it (they already have JS debugging for Chrome and Firefox): https://plus.google.com/110412141990454266397/posts/iKRyXaYBm92 I really wish "better support for SuperDevMOde" means support for sourcemaps.

The tools exist for Chrome for Eclipse too, so the Google Plugin for Eclipse could possibly have support for sourcemaps.

 

I agree with Andrew Mackenzie, that it would be basically good enough to have one browser (per OS) available for DevMode (reminds me of the old Hosted Mode). "Hosted Mode" for one browser + Super Dev Mode for all browsers would give me most of what I need. I imagine, that it would also allow "Hosted Mode" to be more optimized than the current Dev Mode (somehow I always had the feeling, that the old Hosted Mode reacted quicker than Dev Mode, but I could be wrong).

It's possible that HostedMode was faster than DevMode, because communication between JS and Java was done through JNI, and now goes through TCP. Embedded browsers, even if using the exact same engine, don't behave like their "full blown" counterparts (IE, when embedded, has different rules for switching between IE5.5Quirks/IE7/IE8/etc. modes for instance)

[Chris Lercher]

On Thursday, November 15, 2012 2:53:37 AM UTC+1, Thomas Broyer wrote:

SourceMaps could then be used by your IDE so you could put breakpoints in your editor window.

I can see the potential - it could be big. I do have a few doubts though:

1. Would this also allow me to inspect the internal state of objects from within my IDE? (Is this even possible?)

2. What about super-sourced classes, which are - at least in Eclipse - usually excluded from the build path to avoid error messages (that's probably the smaller problem, as I imagine, that this could be taken care of by the IDE plugins)

 

 

Embedded browsers, even if using the exact same engine, don't behave like their "full blown" counterparts (IE, when embedded, has different rules for switching between IE5.5Quirks/IE7/IE8/etc. modes for instance)

I think, living with these differences in Dev Mode would be ok. The situation was different back in Hosted Mode's time, because Super Dev Mode was missing. I believe, that Dev Mode currently has some important use cases, which Super Dev Mode can't cover (yet?) For these use cases, the browser differences are often not that important.

[Clint Gilbert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/14/2012 08:33 PM, Oliver Krylow wrote:
> Also the promise of gwt is NOT to abstract the browser or web
> technologies and semantics away from you, but rather to bring good
> and structured workflow and tooling to web development .

Well, sort of. Or perhaps that's how it is for you. A structured
workflow and tooling is very welcome for web work, where the dominant
technologies have grown organically over decades to do things far
beyond their originally intended purposes.

HTML/CSS/JS are the web's assembly language. Most (definitely not
all!) developers don't need to care what CPU instructions their C
compiler or language JIT runtime generates, and that's a Very Good Thing.

That GWT goes beyond the papering-over of browser differences provided
by Jquery-level JS libs is similarly a very good thing. Every
browser, JS, or HTML detail that I don't need to care about frees up
mental resources that I can use toward actually solving the problems
my apps need to solve.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlClGYQACgkQ5IyIbnMUeTvIiwCbBVZH3si+AqROg3zmLOOkdvP4
+XUAn21jNnz+95Lm4ycNS2/J/qD85yCL
=eUK1
-----END PGP SIGNATURE-----

[Clint Gilbert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

If I could hook Eclipse up to Firefox or Chrome and step through code,
that would make SDM much more workable. Is that currently possible?

If so, is it possible to inspect the internal state of an object
defined in Java, compiled to JS, and running in a browser VM?
Breakpoints and stepping line by line are great, but losing object
inspection would be a big step back.

> -- You received this message because you are subscribed to the
> Google Groups "Google Web Toolkit" group. To view this discussion
> on the web visit

> https://groups.google.com/d/msg/google-web-toolkit/-/65KGTSLnUJ0J.

> To post to this group, send email to
> google-we...@googlegroups.com. To unsubscribe from this
> group, send email to
> google-web-tool...@googlegroups.com. For more options,
> visit this group at
> http://groups.google.com/group/google-web-toolkit?hl=en.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlClHDEACgkQ5IyIbnMUeTsejwCcCepJDymqjpECsv7PXhXnbciF
L9gAn34/OEEJArXpXU6zq+10OlSmvs2L
=QD9T
-----END PGP SIGNATURE-----

[Paul Stockley]

One tip in the chrome dev tools to find a source file is to select the sources window and just start typing the name of the file. This will take you to the files that match as you type.

[Thomas Broyer]

On Thursday, November 15, 2012 5:55:44 PM UTC+1, Paul Stockley wrote:

One tip in the chrome dev tools to find a source file is to select the sources window and just start typing the name of the file. This will take you to the files that match as you type.

Or Ctrl+O.

[pierre]

The SuperDevMode seem do a full compile as is com.google.gwt.dev.Compiler with PRETTY style plus sourcemaps generation. It even take longer time than a normal GWT compiler compilation. Moreover, the unitCache is not always pickup correctly make the compilation even longer.

[Colin Alworth]

There is a prototype project enabling Eclipse to debug the JS running in the browser with sourcemaps - check it out at http://github.com/sdbg/sdbg.

> google-web-toolkit+unsub...@googlegroups.com. For more options,

[Jakub Ściuba]

Is there any option to debug JS running a browser with sourcemaps in IntelliJ? 

[Frank Hossfeld]

Yes, there is. Create a running configuration for JavaScript, start the configuration, install the IntelliJ-Plugin for Chrome... end it works ... Really nice.

It seems, that FireFox won't work. I opened a ticket at IntelliJ. Hope theq will fix it soon.

[Adrian Bastholm]

I just got started with SDM but it seems like one cannot inspect variables in the java source maps, maybe I missunderstood the whole thing. It's nice that you can see the java source and step debug, but I really need to be able to inspect variables. 

For instance I somewhere read that you're supposed to be able to inspect overlay types, which I don't seem to be able to. 

Have I got something wrong, or did I hope for too much ?

/Adrian

[Jens]

I just got started with SDM but it seems like one cannot inspect variables in the java source maps, maybe I missunderstood the whole thing. It's nice that you can see the java source and step debug, but I really need to be able to inspect variables. 

For instance I somewhere read that you're supposed to be able to inspect overlay types, which I don't seem to be able to. 

Have I got something wrong, or did I hope for too much ?

Always keep in mind that source maps just overlays javascript to make it look familiar to you. You do not deal with java at all, it is still all javascript. 

In Chrome dev tools you can see the "Scope Variables" section on the right which shows you all variable values of the current scope. These are JavaScript variable names but should be easy to identify. 

When using Source Maps the "code viewer" in Chrome is more or less read only, so you can not hover anything to get more information about a variable. You also can't navigate your code inside Chrome dev tools by ctrl + click on a java class name of something like that. If you want that then use the experimental Eclipse plugin SDBG or use IntelliJ which both are able to connect to Chrome and show you debugging informations of Chrome inside your IDE. That way you get code navigation back and you can set breakpoints in your IDE instead of Chrome dev tools.

-- J.

[Adrian Bastholm]

Thanks Jens for clarifying that.

/Adrian