Potential of browser based IDEs
-
Rama Krishna Vavilala wrote:
The big advantage is that you do not have to mess up your development machine each time there is a new version of IDE or wait for hours for installation of IDE to complete.
Actually, that's a HUGE disadvantage, IMHO. I don't want the damn IDE changing on me in the middle of an intense project development cycle. Maybe it's just me, but I like stability and the delusion of control. I turn off automatic updates, because I'll decide when and if I want to update the apps I use. And as to a browser-based IDE, I'm sorry, but I still frequently enough work in a disconnected state that I don't want anything important to be living on the web, be it data or tools. And even in a theoretical "always connected" scenario, I don't want to deal with the downtime of the inevitable hardware failure, routers, cable/DSL modems, drunk drivers smashing into telephone polls, lightning strikes and other acts of God, etc. In other words, I'd be happy living in a cabin on a remote mountain with a once-a-day 10 minute data burst as a satellite passes overhead. The rest of the time, I could easily live without an Internet connection. Marc
Pretty sure I've talked about this before, but... There's one huge potential advantage for a "cloud-based" IDE (whether browser-based or otherwise): integrated source control. Yeah, I know. I hate it too. ;-) But I hate it because it gets in my way. I don't really ever want to see source control when I'm writing, any more than I want someone standing over my shoulder talking about the movie watched last night. But when I'm editing, or trying to track down the source of a problem, it could be useful... Flag routines that someone else is working on so I can coordinate with them, integrate "blame/annotate" so I can quickly identify the author and origin of each change, let me pick a specific revision to test against... ...and of course, that's all possible now, using most modern source controls systems. But they're slow. They get in my way. They require me to be involved in the fiddly details of maintaining the local cache, er, "working directory". Example: creating a new branch is fast, but pulling down the files for that branch into a separate local working area is slow... Never mind that most of the files are already on my machine, unchanged and unlikely to change. The solution is to give up on the idea that you're editing local files. Your IDE (editor, compiler, debugger) pull them off the network and cache them locally, but changes belong to a branch somewhere; saving commits it, and you merge up when finished. The local filesystem is a cache, with no need for multiple copies of the same revision of a file. And at that point, an editor in a native-code IDE and an editor in a browser-based IDE are both pulling the file from the same place, both saving changes to the same place, and the choice between them can be made on convenience vs. capability.
-
Pretty sure I've talked about this before, but... There's one huge potential advantage for a "cloud-based" IDE (whether browser-based or otherwise): integrated source control. Yeah, I know. I hate it too. ;-) But I hate it because it gets in my way. I don't really ever want to see source control when I'm writing, any more than I want someone standing over my shoulder talking about the movie watched last night. But when I'm editing, or trying to track down the source of a problem, it could be useful... Flag routines that someone else is working on so I can coordinate with them, integrate "blame/annotate" so I can quickly identify the author and origin of each change, let me pick a specific revision to test against... ...and of course, that's all possible now, using most modern source controls systems. But they're slow. They get in my way. They require me to be involved in the fiddly details of maintaining the local cache, er, "working directory". Example: creating a new branch is fast, but pulling down the files for that branch into a separate local working area is slow... Never mind that most of the files are already on my machine, unchanged and unlikely to change. The solution is to give up on the idea that you're editing local files. Your IDE (editor, compiler, debugger) pull them off the network and cache them locally, but changes belong to a branch somewhere; saving commits it, and you merge up when finished. The local filesystem is a cache, with no need for multiple copies of the same revision of a file. And at that point, an editor in a native-code IDE and an editor in a browser-based IDE are both pulling the file from the same place, both saving changes to the same place, and the choice between them can be made on convenience vs. capability.
Shog9 wrote:
Your IDE (editor, compiler, debugger) pull them off the network and cache them locally
Makes sense, and sounds wonderful, but the very reason that checking out a "working directory" is slow is because my network connection is still about 1,000 times slower than it needs to be, for anything on the Internet to not feel like it's getting in my way. :) Marc
-
Shog9 wrote:
Your IDE (editor, compiler, debugger) pull them off the network and cache them locally
Makes sense, and sounds wonderful, but the very reason that checking out a "working directory" is slow is because my network connection is still about 1,000 times slower than it needs to be, for anything on the Internet to not feel like it's getting in my way. :) Marc
Well, there's where the browser client might have an edge: a single source file should transfer (gzip compressed) fairly quickly (<1sec). Assuming the server-side takes care of handling class browser, Intellisense-type stuff, I'll probably never pull down enough code during a typical editing session to notice... Vs. the tens or hundreds of MB I currently need to pull down to get full support from VS (and that's not counting the time VS takes to rebuild its internal databases every time, for every branch for every user working on that branch...)
-
Rama Krishna Vavilala wrote:
The big advantage is that you do not have to mess up your development machine each time there is a new version of IDE or wait for hours for installation of IDE to complete.
Actually, that's a HUGE disadvantage, IMHO. I don't want the damn IDE changing on me in the middle of an intense project development cycle. Maybe it's just me, but I like stability and the delusion of control. I turn off automatic updates, because I'll decide when and if I want to update the apps I use. And as to a browser-based IDE, I'm sorry, but I still frequently enough work in a disconnected state that I don't want anything important to be living on the web, be it data or tools. And even in a theoretical "always connected" scenario, I don't want to deal with the downtime of the inevitable hardware failure, routers, cable/DSL modems, drunk drivers smashing into telephone polls, lightning strikes and other acts of God, etc. In other words, I'd be happy living in a cabin on a remote mountain with a once-a-day 10 minute data burst as a satellite passes overhead. The rest of the time, I could easily live without an Internet connection. Marc
Marc, I'm a pretty forward thinking EE and techie (the two go together). I too just don't get the cloud. Too much loss of control over apps and data. I guess they figure if you rename the technology enough times someone will eventually buy into it. thin client->saas->cloud longhorn->vista->mojave experiment etc. Now hosting an in-house private cloud -- I can see a business case made there.
-Sean ---- Fire Nuts
-
Marc, I'm a pretty forward thinking EE and techie (the two go together). I too just don't get the cloud. Too much loss of control over apps and data. I guess they figure if you rename the technology enough times someone will eventually buy into it. thin client->saas->cloud longhorn->vista->mojave experiment etc. Now hosting an in-house private cloud -- I can see a business case made there.
-Sean ---- Fire Nuts
Sean Cundiff wrote:
Now hosting an in-house private cloud
Quick! We need to capitalize on that idea. There are obviously different kinds of clouds: Cirrus Cumulus Stratus Stratocumulus NimboStratus Cumulonimbus ... The variety is astounding! We can use the cloud metaphor to describe any network topology!!! And best of all, we can create a whole series of vaporware products!!! Marc
-
I was looking at Ares - a web based IDE for Palm Pre development. I must say that I am impressed. The IDE is pretty responsive and lot of features you expect in a desktop IDE are present in Ares. Of course, I have not done any real work to see how the IDE will hold up. But it seems to be a nice start. So do you expect to see a Browser based (most likely SilverLight) version of VS2010? (may be something which is lower than the Express edition in the hierarchy). The big advantage is that you do not have to mess up your development machine each time there is a new version of IDE or wait for hours for installation of IDE to complete.
There are already enough things that slow down the work -- memory and disc bloat, badly organised threading and priorities within the IDE, etc. Why on Earth would you want to add another layer -- nay, several more layers -- of things that can slow you down and/or screw up your work? Tip: If someone in IT says "This can be done!" and they sound even vaguely excited about it, run a mile.
I wanna be a eunuchs developer! Pass me a bread knife!
-
I was looking at Ares - a web based IDE for Palm Pre development. I must say that I am impressed. The IDE is pretty responsive and lot of features you expect in a desktop IDE are present in Ares. Of course, I have not done any real work to see how the IDE will hold up. But it seems to be a nice start. So do you expect to see a Browser based (most likely SilverLight) version of VS2010? (may be something which is lower than the Express edition in the hierarchy). The big advantage is that you do not have to mess up your development machine each time there is a new version of IDE or wait for hours for installation of IDE to complete.
I have yet to see a browser based UI that comes close to the finish and polish of top end rich client UI's. It's the small details that's hard to put a finger on, response times, visual cues etc. Sure Word is bloated and Notepad is easy. But there's a reason for all the shingles: easy, after a while of regular productive use, is not enough.
Rama Krishna Vavilala wrote:
(most likely SilverLight)
That's kind of cheating, isn't it?
Agh! Reality! My Archnemesis![^]
| FoldWithUs! | sighist | µLaunch - program launcher for server core and hyper-v server. -
Rama Krishna Vavilala wrote:
The big advantage is that you do not have to mess up your development machine each time there is a new version of IDE or wait for hours for installation of IDE to complete.
Actually, that's a HUGE disadvantage, IMHO. I don't want the damn IDE changing on me in the middle of an intense project development cycle. Maybe it's just me, but I like stability and the delusion of control. I turn off automatic updates, because I'll decide when and if I want to update the apps I use. And as to a browser-based IDE, I'm sorry, but I still frequently enough work in a disconnected state that I don't want anything important to be living on the web, be it data or tools. And even in a theoretical "always connected" scenario, I don't want to deal with the downtime of the inevitable hardware failure, routers, cable/DSL modems, drunk drivers smashing into telephone polls, lightning strikes and other acts of God, etc. In other words, I'd be happy living in a cabin on a remote mountain with a once-a-day 10 minute data burst as a satellite passes overhead. The rest of the time, I could easily live without an Internet connection. Marc
-
I was looking at Ares - a web based IDE for Palm Pre development. I must say that I am impressed. The IDE is pretty responsive and lot of features you expect in a desktop IDE are present in Ares. Of course, I have not done any real work to see how the IDE will hold up. But it seems to be a nice start. So do you expect to see a Browser based (most likely SilverLight) version of VS2010? (may be something which is lower than the Express edition in the hierarchy). The big advantage is that you do not have to mess up your development machine each time there is a new version of IDE or wait for hours for installation of IDE to complete.
The only IDE I need vim.
-
I was looking at Ares - a web based IDE for Palm Pre development. I must say that I am impressed. The IDE is pretty responsive and lot of features you expect in a desktop IDE are present in Ares. Of course, I have not done any real work to see how the IDE will hold up. But it seems to be a nice start. So do you expect to see a Browser based (most likely SilverLight) version of VS2010? (may be something which is lower than the Express edition in the hierarchy). The big advantage is that you do not have to mess up your development machine each time there is a new version of IDE or wait for hours for installation of IDE to complete.
Looks great. Not fast on firefoxf but I'll see how it will run on chrome.
-
I was looking at Ares - a web based IDE for Palm Pre development. I must say that I am impressed. The IDE is pretty responsive and lot of features you expect in a desktop IDE are present in Ares. Of course, I have not done any real work to see how the IDE will hold up. But it seems to be a nice start. So do you expect to see a Browser based (most likely SilverLight) version of VS2010? (may be something which is lower than the Express edition in the hierarchy). The big advantage is that you do not have to mess up your development machine each time there is a new version of IDE or wait for hours for installation of IDE to complete.
Lively Kernel[^]. The Lively Kernel project provides a complete JavaScript development environment and platform. . Originally written at Sun Labs, now an Open Source Project. The entire IDE and app's run in the browser, and the overall experience is reminiscent of Smalltalk or, more specifically, SELF development. Their GUI work is staggering for running within a browser. Somewhat predictably, IE is not supported - Chrome is the best option for running in Windows. Maybe IE9 will be better equipped.