Orion - web based IDE from Eclipse | Hacker News Reader

Orion - web based IDE from Eclipse

borisoneclipse.blogspot.com

46 pointshencq21 comments

I think it is a very good initiative. 15 years ago many did not believe that web is a good platform for e-mail. I would use web-based IDE for all the same reasons I use web-based e-mail: accessible from everywhere, no setup, portability and consistency across operating systems, new features available immediately without me worrying.

I also agree with their premise that a lot of the development cycle already happens online. E.g. bug tracking and code repositories.

I think if it will stay exclusive to (client side) web development for a while though. But who knows, maybe someone decides to make some web service available that allows you to deploy straight to some server.

There was an episode of This Week in Startups with DHH as a guest where a Shark Tank caller pitched his web-based IDE. I was surprised to see both Calacanis and Hansson shit all over the idea. For the reasons you mention, it's a great idea. Off topic - it's really interesting to observe people making poor judgments when they're blinded by their own success.

Gotta admire their determination to keep finding new ways to slow down the performance of Eclipse. Seems that Moore's law finally caught up with them and they couldn't produce two second waits for menus to appear in desktop Java anymore, so they had to step it up and port to Javascript.

Given what we've come to expect from an IDE these days (think IntelliJ or VS.NET + ReSharper), it's tough to imagine a browser-based version being all that compelling. I've actually worked for extended periods using a browser-based editor while traveling, but it really wasn't that pleasant. I don't think I'd consider doing it if I was sitting at my main dev box.

re 2nd paragraph: but isn't that a fantastic reason for them / others to be attempting to make a usable one? However unusably slow it may be (though their users are used to that by now)?

A few years ago (and probably still), a lot of companies had interest in tighter control over source code and development environments. This would be one possible move supporting that direction. (I haven't read up on Orion, yet.)

I can imagine some developers not liking some aspect of that. But there are a lot of people sitting at their desks, putting in their 8 or 10 or whatever. And if you're outsourcing, suddenly you're giving the contractors access to a web page and only the components they're working on, rather than the whole shebang.

I think I'd find it kind of / rather frustrating, but it wouldn't be the first work environment to generate those feelings.

>suddenly you're giving the contractors access to a web page and only the components they're working on, rather than the whole shebang.

Isn't this already doable? Just make separate binaries for the sections you want, all you need to distribute are the interfaces (header files, etc) to build against. Whether companies actually do so or not is a different issue entirely, and yes, something simpler may increase its use, but I fail to see how this would actually change anything but frequency.

In some cases. But I've seen environments where this wouldn't even begin to be possible.

I used the word "contractors", but I could also apply the description to direct employees located in different countries.

This also keeps the source from being located (other than a page at a time, as it were) in those jurisdictions. (Also, potentially, sensitive test data.)

My experience may have been an anomaly, but after tackling duplicate systems and builds, attendant source control issues, latency in rich client development tools, blah, blah, there was a growing push to bring everything back and keep it "on the mothership". One step was having people essentially remote in to local hosts via Citrix.

Webification was happening initially for project management tools, but eventually, if they could give everybody web pages and be done with it (except for those directly maintaining the infrastructure), Management and IT would have been very happy.

A lot of these aspects may be, initially at least, "big company" problems. But my -- admittedly limited -- perception is that, in those environments, they are on a lot of people's radar.

(I'm suddenly reminded of the recent tussle that IBM went through with the Russian government, to ensure that they could use encryption/security IBM deemed sufficient/necessary on development environments for developers located in Russia.)

From what they have on the wiki, it sounds like it may not necessarily slow down the performance by that much.

It looks like they are really only putting a web frontend on top of eclipse, so all the computation heavy stuff happens on the backend and gets sent back to the browser asynchronously. In other words, it should work as fast as the desktop eclipse (minus latency issues).

This should work fine. A couple folks on my team split out some of the VS backend to run on a server and do the editor in JS inside of a browser back in 2003/2004 and the intellisense, etc. was totally reasonable. All tests were done with co-loc'd servers, though, thinking back :-)

Desktop Eclipse can compile my code for me as I type it and show compile errors in red. I truly believe that in a few years something like this can be running test suites on another server as I type. It may not work exactly the same but the idea is there. You will know very soon that you have broken some regression test - or that your code as it exists in the editor would break a test if checked in.

All in all I am a big fan of this idea. I spend way too much tome fiddling around with the settings in desktop Eclipse and even when I get it working I know it is only temporary.

I truly believe that in a few years something like this can be running test suites on another server as I type.

Welcome to the future; Hudson (and probably other CI suites) can do this today.

yea but I thought I had to check in the code before those tools could come into play. I think they could run if I pause editing my code and it happens to compile.

With a little bit of scripting you can have your local working copy rsync'ed to a build-server at regular intervals.

I think there's even a hudson-plugin for that but I can't remember the name right now.

Granted, this still requires you to save your code before changes become visible, but honestly I don't see how an even finer granularity would help anything.

A Google search uses hundreds of machines in parallel for a few milliseconds; if it was done serially it would probably take a second or more. Now imagine applying the same idea to IDEs; compiling, testing, code indexing, refactoring, etc. could be done dramatically faster in the cloud than on your desktop.

Tried to install this and it doesn't really work. Cloud9 looks _much_ more mature, and I like that the server is also written in JS.

Development is definitely going online, but I doubt that Eclipse will have a significant part in this transformation.

I think IDEs will be one of the last classes of applications to move from the desktop to the Web. In addition to the usability challenges of running a highly complex application in a browser, there are also a ton of security/access issues that will need to be addressed to make a Web-based IDE useful.

We often need full, unrestricted access to the machines we're coding on, as well as the ability to obtain and use a ton of different tools alongside an IDE. Bringing this kind of freedom and flexibility to a browser is going to be tough.

I think this is a great step forward (though does anyone remember mozilla's online IDE efforts - bespin?). Has a more special place in my heart since Ive been "thinking" about doing something similar for years.

Plus I think this (and/or bespin) would make it a lot easier to combine RFS5 (Development on hand helds) and RFS6 (iPad applications)!!! Cant wait.. My hour long train rides to the city would be a lot more productive without having to carry a laptop!

So whether or not this specifically is going to pan out to anything, it has a fantastic nugget of an idea in the middle of it: There will be web-based API standards for tools dealing with code. These APIs represent a good thing, as now perhaps people will start creating great code tools to the API instead of to a specific editor/ide. As such, we get a start to the "standard code tools interface" I've wanted for a really really long time.

tl;dr -- this could be the start of the end of "use this IDE because it can do X and this other IDE for Y" and the beginning of "Point your editor to Z for this functionality!"

"IDEs are big honking applications that take a while to load, use up all your computer's resources, and come loaded with features that you don't even know existed."

This is why I hate Eclipse.

i think is a good idea. the final product is not ready yet but it is a step forward for ide development. It could also boost collaborative work among developers and it might improve security and availability(keeping the code away from the developer desktop it easier to backup, avoid code stealing, etc.)

Reply on news.ycombinator.com