| Re: [eclipse-incubator-e4-dev] SWT port to Flex |
So I'm reading between the lines that the intention is to take existing running Java code using SWT, and transmute that, in toto, to Flex. Just like what (I understand) GWT does. *Devil's Advocates positioning below!!!* As for "what does this solve" ... let me play devil's advocate here. I love the shape of SWT, I don't care much about the actual bindings to Java. Even though that's the only SWT story - I look at it in a more idealized form. Similarities to Cw / Cg perhaps :-) Take that as my "pro-SWT" stand. Extending the "SWT interface" story out across other languages in no way seems like a stretch to me. Useful? Dunno. But as a concept - works for me. Now, let's look at the actual language issues here. In my, particularly slanted, view of the world, the value of Java is declining against the value of "scripting" languages. Bear with me, I admit I may not be right there, but just pretend. _javascript_ will just never go away, it would seem. And I mean literally. As such, by forcing everyone who wants to use SWT to first learn Java, you are going up against a smaller set of developers every year. YOUR POTENTIAL MARKET IS DECREASING. Alternatively, by exposing SWT in _javascript_, your potential market over time is increasing. And there's already a story for running _javascript_ code in Java, called Rhino or JDK 1.6 javax.scripting (or whatever), so Java folks are also potential customers here. You've got both markets. Another way of looking at this problem is "what problem are you trying to solve". I'm guessing the problem is: "I've got a lot of pre-existing Java/SWT code and/or Java/SWT experience I want to reuse". If you can do a 100% translation from those reusable assets into runnable _javascript_/Flex/Silverlight/whatever assets, then you've solved your problem. If you can't do 100%, then you have a cost/benefit issue on your hands. My experience here is colored by the "Smalltalk on the Web" experiences from a decade ago; we didn't even try to go down the transparent route because we knew it wouldn't be 100% and the cost/benefit didn't seem to work out in "transparency"'s favor. You might well argue the web has radically changed in a decade, pushing the potential for 100% transparency back in the web's favor, but I'd argue it hasn't. DHTML and XHR are almost that old anyway, we certainly had some JS back then, and the big issues are UI rendering anyway but "event handling" and ui transitions. Flex is on a better footing for SWT than 'html' (obviously), but has it's own "not of the web issues" like - how do I bookmark a spot in a Flex app? You might do a bang-up job porting SWT to Flex, but that doesn't mean you've solved the web UI story. Frankly, I'm pretty bullish on Flex/Silverlight/etal here, but don't think they will displace HTML/CSS/JS either. You are forever relegated to that sliver of the web that caters to those UIs. I could of course be much meaner in my argument and say something like: "I certainly expect a bunch of Java heads to assume that Java is the answer to every problem. Are there 'web people' involved in the discussion here? I don't think any 'web people' ever consider Java to be part of the answer when it comes to 'web UI'". But I'm not a mean guy so I won't say that. :-) And I don't consider myself a knowledgeable 'web person', more of an enthusiast, prosumer. And rock thrower. On Sep 19, 2008, at 12:30 PM, Steve Northover wrote:
Patrick Mueller |