Thursday, February 19, 2009

Thoughts on Bespin and Eclipse

I'm really stunned by the quite opposite reactions that the Mozilla and the Eclipse communities are having about Bespin.
On the one hand it is like Bespin is the best thing since sliced bread, ("hey look now I have a cool editor in my web browser") on the other a quite mixed reaction is coming ("why the heck would I want to ever do this", "where is my code completion, type hierarchy", etc.)
Honestly I'm not really surprised by this reaction from the eclipse community especially when you have been around long enough to remember the early days of CDT and the complaints it was receiving because it was not up to the task in comparison to JDT... or more recently on other fronts when you see bugs titled like "XYZ sucks", and the difference in participation on a new effort. Feels like our community is spoiled.

So where do I stand on Bespin? Well somewhere in the middle. I'm not impressed by the overall Bespin concept because it only solves one little part of the problem of creating an IDE: the snappy text editor and the collaboration. I like it, I like the fact that it is done with HTML5 canvas, the way the extensibility is working to invoke commands, etc. However when it comes down to running a full fledged IDE, I'm skeptical. Not about the abilities of the browser or canvas to scale (remember that a few years back Java was declared dead for rich client apps?), but simply because I know what it takes to have all the features that make you so productive in Eclipse. Most of them can't just work of one or two source files at least to give you assistance to the degree you are used to. We can probably get the information back from the server, but would it get back fast enough; we could have less precise operations, but are we ready to go with this?

All that said, I believe that there is a place where a Bespin based IDE (or the like) can be useful as a lightweight tool to do a quick task... (peer programming like scenarios, just need to fix a typo in the file, provide translation, etc.). But I don't think we are quite there yet, and there is a lot of cool problems to solve. For example the model as to where the resources being edited are coming from is unclear. One possibility is to assume that everything I need is already available on a remote server "on the cloud" (or my buddy's machine) then I can just edit this. Now, if my principal model is to work in a regular IDE and try to use my web IDE to just perform some mundane tasks, then the overhead of locating and opening the file would rather be low (Unless of course I can directly edit the code straight out of the code repository and put it back there on save (see lower)).

So what would I want to see / do / explore?
  • Explore with running a more complete headless Eclipse in the cloud. 
There I'm curious about the response time to get the result of for example a code completion, browsing type hierarchy, over the wire when hosted on a real cloud service. From there, I would want to see if any benefit can be had in having a caching proxy / partial replica of what's running on the cloud (and probably and augmented version of this with more functionality) on the user's machine so we can have better response time. For example maybe my server on the cloud does not offer completion, or type hierarchy browsing, but this can be done through my local server. Also this would solve the disconnected mode enigma with IDE based browsers.

  • Following this, is offering an "upgrade" path from the browser to the local experience. 
This addresses the case where I've started doing this mundane task but it turns into a bigger thing than expected and I need a complete IDE.

  • Making the workspace cloud friendly. 
When I hear cloud, I hear scalability, 100s of machines running my app. However I don't believe that our current workspace format is really that replication friendly. Do we need this? I don't know.

  • Explore DVCS as the underlying storage of a workspace. 
Would the usage of a DVCS server help in solving the remote server / local proxy synchronization that would result in a proxying solution mentioned earlier? Would that also facilitate handling a case where multiple people would work on the same workspace at the same time? And also does that make the workspace more cloud friendly

  • Could Bespin provide the web browser implementation of the eclipse app model (aka 20 things). 

  • Explore single sourcing (generative technique, model based, ...) of commands to make it easy to target both the we-based and client-based IDEs

  • Finally and unrelated to all that is to see if we can have an SWT for HTML5 canvas. 
Given that canvas seems rather new, it could bring to the browser fans the maturity of SWT and it could be a good space to win esp. if we want to ease single sourcing.


Caveat, this is just the fruit of my imagination as I have not been involved in the Mozilla/Eclipse meeting.

4 comments:

Doug Schaefer said...

Sounds like the bar will be lively in Santa Clara on this issue ;).

Ian Bull said...

Great Post Pascal!!! This is exactly the type of thinking that makes e4 so exciting. The worry that people have -- OMG I am only going to be able to run Eclipse in a browser next year -- is extremely premature. I see e4 as a great *set* of enabling technology, that will enable all sorts of things. Hey, isn't that what makes e3 so successful:-)

Ed Merks said...

Experience has taught me that all great ideas will be met with immediate and strong opposition. Of course bad ideas produce opposition as well, though rarely as strongly as do great ideas. Mediocre ideas produce no reaction at all.

The key is to look at the reasons for the reaction. Any comments to the effect of "I don't need this" likely reflect having missed some or all of the point, with the most important one being "so don't use it if you don't need it." Comments about "this won't work" are typically wrong up front given it's a reaction to something that is already working. Where there's a will there's almost always a way.

The good thing is that there is more to be learned by paying attention careful to the opposition than there is basking in universal support.

Eric Rizzo said...

My primary concern with this Bespin thing is not "I don't need it" (although I don't and I've taken the time to give it careful consideration and still haven't seen anything explain when this would be really useful or what the future "vision" of it might be). No, my big concern is that "playing around" with this mgiht suck valuable time away from people whose efforts are needed in Eclipse 3.x and e4. There is SO MUCH work that needs to be done on those things, I'm concerned something "cool" like this will suck away resources.