tag:blogger.com,1999:blog-17547394.post7358060558593335093..comments2023-03-24T13:39:26.449-05:00Comments on Boris Bokowski: Embedding web UI components in Eclipse using e4Boris Bokowskihttp://www.blogger.com/profile/06344587055927544695noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-17547394.post-17117506864290042862010-01-21T03:51:55.530-05:002010-01-21T03:51:55.530-05:00I don't want to comments on the complexity of ...I don't want to comments on the complexity of e4 architecture. With the embedding web UI components in the Eclipse, it at least give the advantage of reusing the web widgets in Eclipse. <br />So question here - whether e4 can allow the embedded web UI components access data in local file systemSamhttps://www.blogger.com/profile/14689029869103346974noreply@blogger.comtag:blogger.com,1999:blog-17547394.post-19343003469899242772009-11-11T05:14:14.457-05:002009-11-11T05:14:14.457-05:00Hi Boris,
I would also like to comment on the big...Hi Boris,<br /><br />I would also like to comment on the big picture.<br /> <br />I agree that client technologies and Web technologies will converge. I also like the approach to let Web-based components run within Eclipse and communicate with the rest of Eclipse effectively making Eclipse a better browser. I agree that client-server based approaches like RAP are limited to certain scenarios and are not able to bring every highly-interactive client-based application into the Web.<br /><br />On the other side, there is a lot of power (developer experience, exiting code and frameworks) with Java/Scala/OSGi/SWT/EMF/Workbench/etc that can not be cross-complied into AJAX/JavaScript/Flex and Co but is compelling to be used in Web-based or client-server scenarios.<br /><br />At the end, a user doesn't care whether it is JavaScript or OSGi. What matters for a Web user is whether it can be a) automatically installed/updated, b) triggered/opened by a URL, c) run without local footprint (i.e. all user data on server, roaming etc), d) integrated with other Web technologies/frameworks like AJAX, mashups etc. <br /><br />What if Eclipse would create a technology (similar to Java WebStart or other Web browser plugins) that allows automatic installation/update/removal of "browser-embedded" Eclipse on the client machine? There can be also a JavaScript bridge that allows communication between "embedded" Eclipse and AJAX/JavaScript. Such an Eclipse installation must be able to run without local footprint (with exception of the p2 repository with OSGi bundles and necessary UI native libs) and communicate with some (eventually Eclipse-based) server to get/put user data and store user context. <br /><br />The proposal goes in the same direction as RAP with regard to a client-server approach and single-sourcing. But the communication with backend parts of the application will be done not on the UI level as with RAP (where you need a high-frequency, low-latency channel) but on data/content access level where you can work with a low-frequency communication and may also use caching frameworks like Google Gears or CDO.<br /><br />Such a solution is not intended to compete with Web frameworks where there is no chance for Eclipse to win. It will be rather a competition with Adobe AIR and JavaFX. I believe that Eclipse has very good chances to become a dominant technology in this space.<br /><br />What do you think?<br /><br />Best regards,<br />EdEd Bartschhttps://www.blogger.com/profile/15286223339937161951noreply@blogger.comtag:blogger.com,1999:blog-17547394.post-34194526497467766222009-09-28T08:05:12.135-05:002009-09-28T08:05:12.135-05:00"A case study (you posted) on RAP showed that..."A case study (you posted) on RAP showed that a customer choose RAP instead of GWT because of the clean programming model and the presence of advanced widgets, compared to GWT."<br /><br />@André: That would be me :-) But my company is just a regular technology user. My point was that RAP is a fully developed framework. The widgets themselves (that would be RWT) are no more advanced than GWT's, but GWT does not really do more (OK, besides RPC calls). So developing with GWT feels mostly like working with SWT/RWT.YouCanPlayBetterhttps://www.blogger.com/profile/03315529331463834175noreply@blogger.comtag:blogger.com,1999:blog-17547394.post-62507572743987849902009-09-26T04:22:17.776-05:002009-09-26T04:22:17.776-05:00Hi Elias
I completely agree that e4's too com...Hi Elias<br /><br />I completely agree that e4's too complex to be attractive as plain web framework. I hardly can imagine that we want to compete with rails. Eclipse will probably always be a niche product where a user programmer has to develop a simple web based solution (display, edit, store data). Eclipse always had a steep learning curve and its main strength always was in enterprise scale apps. You dont need OSGI modularization for small rich clients. But I agree in general, we most likely have to improve in this area. <br />But that's just one side of the medal: how to attract adopters. On the other hand, we might win the race where you need a framework for a large scale web application. A case study (you posted) on RAP showed that a customer choose RAP instead of GWT because of the clean programming model and the presence of advanced widgets, compared to GWT. That might be the competition that e4's capable to win: Is e4 compelling where you're up to implement an app (not just a page). <br />Any thouts?Andréhttps://www.blogger.com/profile/11800340699268382462noreply@blogger.comtag:blogger.com,1999:blog-17547394.post-8517091107653633272009-09-25T19:31:04.217-05:002009-09-25T19:31:04.217-05:00Hi Boris,
instead of commenting on the details I ...Hi Boris,<br /><br />instead of commenting on the details I would like to step back and comment on the big picture.<br /><br />Speaking purely from my <b>personal</b> POV, I'm not yet convinced that e4 is going to be a compelling <b>general purpose web framework</b> (perhaps a compelling tooling framework with web capabilities).<br /><br />Let's say we just graduated from university and want to build the next facebook. Would we rather learn framework XYZ or OSGi+Extension Points+SWT/JFace+Workbench Model+EMF+declarative UIs? <br /><br />I think the sweet spot lies somewhere beyond of what the current 'js widget toolkits' offer but with drastically less functionality/complexity than e3/e4 do require. However I don't think we can get there without leaving our legacy behind.<br /><br />Looking forward to a constructive discussion,<br /><br />Elias.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-17547394.post-64603318848218855122009-09-25T17:31:57.774-05:002009-09-25T17:31:57.774-05:00awesome! I specially loved the architecutral analy...awesome! I specially loved the architecutral analysis (client-side and server-side logic, etc.). I peronally believe that we'll have to move towards the web and embrace it. The power and speed google and mozilla invest to move apps to the web won't be easy to follow though. Where will start the desktop in a few years? Will there be any separation left? etc. etc.Andréhttps://www.blogger.com/profile/11800340699268382462noreply@blogger.com