A lot of negative feedback (maybe ) has been going for SDM. It seems a little harsh to my eyes so here is my positive 2 cents.
We are using SDM for a new project which started from zero lines but grows up pretty fast. We are importing older (even non GWT) modules and 3rd party projects with a fast pace. So far we are at 15-20kloc (sloccount) and the SDM compilation doesn't really slows us down. Of course we do tricks with remote filesystems and ssh-tunels to run the compiler in faster machines than our older developer machines. But the fact that we able to pull such tricks is evident to me that the technology is sound and simple enough for me to understand it. I have to admit that the DM with the plugin business I never understand it enough so I could explain it to my co developers. The SDM is pretty straight forward. Of course I wouldn't say no to improvements in compile time (currently 8sec for me - but may vary up to 30sec) in my i5 with 8G machine. On another note I have to say that SDM triggered some old memories of mine. The way the debug happens in the browser reminded me my first days in computing with x86 debuggers where we were trying to match the compiler output (assembly) to the higher level C input (yes I know - source maps). I am not really using the debugger in my every day life to watch variable values so this feature was not a big enough loss for (and can be emulated by looking at the assembly ^H^H javascript variables). However what I find indispensable is the browser's debug tools. Why css is not applied? It is overrided? Who override it? Why width: 100% means 83px? Where are my other 2 pixels? Where is the padding? What the padding is doing here? And of course flow related questions like: Exception? From where? From here? I thought it was an event listener? Aah the mouse events are also triggering the event listener. What do you know... And for this the browser's debugging tools (chrome and (not or) firefox) are good enough ^H^H best admittedly with some brain assisted mapping. So far SDM represents a win for me Vassilis Virvilis On Wed, Apr 2, 2014 at 12:30 PM, Aleksander Gralak <aleksan...@gralak.org>wrote: > Do not agree. A lot of people complain about it. > > > 2014-04-02 11:05 GMT+02:00 Jérôme Beau <javar...@gmail.com>: > >> Hi Thomas, >> >> I just realized that lack of Firefox 27+ support for dev mode recently >> (tried it because Chrome's plugin crashed too often) and really think this >> is a shoot in the foot for GWT : even if you don't control Mozilla choices >> of course, forcing to move to a non-mature SDM is very risky for GWT itself. >> >> By non-mature, I mean a SDM that lacks features DM had, such as >> Java-level inspection (inspecting Java values of Java variables). I am >> amazed that nobody complains about this loss. Even if you achieve proper >> support for debugging in SDM from the IDE, will it allow such Java-level >> inspection ? I doubt it, you'll only allow JS-level inpections, while >> allowing Java-level stepping, which does not fit the GWT promise of keeping >> at the Java level. This is the reason why most of GWT developpers use it. >> >> >> Le mercredi 5 mars 2014 10:15:55 UTC+1, Thomas Broyer a écrit : >> >>> >>> >>> On Wednesday, March 5, 2014 9:30:54 AM UTC+1, Ed wrote: >>>> >>>> > They have to change, they have to update their tools and move >>>> forward, or quit doing Web dev. >>>> Agree, that's why I spend a lot of grey hairs in using SDM, but it's >>>> simple not there yet saidly... Don't get me wrong, I wish it would as I >>>> certainly see the advantages. >>>> >>> >>> And don't get me wrong: I'm not saying SDM is either perfect nor 100% >>> usable yet. I was just reacting to the fact people complain that DevMode >>> won't be maintained anymore as they don't *want* to move to SDM (which is >>> entirely different from your "I tried, it didn't work" situation). >>> We're currently in a transition period where DevMode is already >>> half-dead and SDM isn't 100% usable yet. Hopefully SDM should be much >>> better by the next release, with incremental compilation (that'll have an >>> impact on your code to really take advantage of it). >>> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "Google Web Toolkit" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/google-web-toolkit/QSEjbhhHB4g/unsubscribe >> . >> To unsubscribe from this group and all its topics, send an email to >> google-web-toolkit+unsubscr...@googlegroups.com. >> >> To post to this group, send email to google-web-toolkit@googlegroups.com. >> Visit this group at http://groups.google.com/group/google-web-toolkit. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to google-web-toolkit+unsubscr...@googlegroups.com. > To post to this group, send email to google-web-toolkit@googlegroups.com. > Visit this group at http://groups.google.com/group/google-web-toolkit. > For more options, visit https://groups.google.com/d/optout. > -- Vassilis Virvilis -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
