Bling and the future of IDEs
- Share
-
- |
Read later
Reading List
At EclipseCon 2013, L33t Labs revealed a port of SWT running on OpenGL, and used it to demonstrate an Eclipse instance with graphical effects animated by the OpenGL hardware.
The presentation was one of the most highly praised at the time, and recently, a video on YouTube has been released which demonstrates the ability to render the IDE with the affects applied:
SWT is Eclipse's widget rendering library, which can have implementations provided for a variety of different windowing systems whilst taking advantage of native rendering and compositing engines. It was created at a time when the Java-based graphics suffered poor performance and did not look like the native operating system's controls. Since then, the JavaVM and Java UI has increased in performance, and new initiatives such as Java FX have allowed Java to catch up with SWT.
Although the OpenGL example showed a lot of eye candy (including effects which would never likely be used in a real environment) there has been a shift in expectations over the last half decade. Since the release of the iPhone in 2007, the mobile industry as a whole has been focussed on not only eye candy but specifically on targeted user interface improvements that enable the user's attention to be drawn to specific locations of the code.
Many IDEs share the heritage of those created in the previous millennium; Eclipse's “Java Browsing” perspective is based on Visual Age for Java's user interface (which itself is based on Visual Age for Smalltalk, released in the 1980s). Little has changed with the UX of development environments for any of the major Java development tools over the last decade, other than minor tweaks in interface colours or underlying rendering technology changes. (For more on the history of Eclipse, see InfoQ's interview with Mike Milinkovich on the past, present and future of Eclipse .)
Perhaps the biggest change of development environments over the last few years has been Apple's Xcode, which introduced a new way of working with Git repositories (visualising the change history as a TimeMachine-esque effect) and the paths which could lead to a static leak:
These days, the focus of the IDE has swung to the web, with Eclipse Orion aiming to be a web-based editor. In the age of always on-line Git repositories, having an editor which only works in a browser would be an ideal way to work with code remotely. Some of this requires that the UX be reconsidered to fit in with the way in which browsers work, but provides an experimental playground for trying out new techniques and mechanisms.
Whether OpenGL as a rendering platform for an IDE remains to be seen, but the next decade is likely to bring about significant UX changes in the way that code is edited, debugged and built.
Rate this Article
- Editor Review
- Chief Editor Action
Submit
Submit
Hello stranger!
You need to Register an InfoQ account or Login or login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think
Community comments
Missing the point
by
Ronald Miura
Posted
CloudSharper is another Web IDE that looks to be feature rich
by
Faisal Waris
Posted
Will always need desktop IDE, why not make it great
by
Doug Schaefer
Posted
Any IDE should worry about workflows
by
Ken Walker
Posted
Re: Any IDE should worry about workflows
by
Doug Schaefer
Posted
Random stuff about Eclipse
by
Mike Lythgoe
Posted
IDE in the web
by
Yann Cébron
Posted
Re: IDE in the web
by
Faisal Waris
Posted
Re: IDE in the web
by
Yann Cébron
Posted
Re: IDE in the web
by
Tyler Jewell
Posted
Re: IDE in the web
by
Doug Schaefer
Posted
Robustness, that's all we need from Eclipse
by
Luca Veronese
Posted
One can only hope
by
Jeff Heon
Posted
Re: One can only hope
by
Faisal Waris
Posted
Re: One can only hope
by
Jeff Heon
Posted
Missing the point
by
Ronald Miura
Smooth transitions and animations are nice and all, but they're most valuable in consumer-facing UIs.
The problem with Eclipse is not that it doesn't animate the panes going in and out the sidebar, but that it freezes while trying to download a DTD file when the proxy is not properly configured.
And, the move to 'The Cloud' may work for dynamic language programmers, since they are already used to crippled tools, but it simply can't scale to the degree of complexity we ('enterprisey' developers) need. They fu**ed up Eclipse with this Juno crap, and waste resources in these pointless endeavours. I think the time of relearn my keyboard shortcuts is really coming this time.
The problem with Eclipse is not that it doesn't animate the panes going in and out the sidebar, but that it freezes while trying to download a DTD file when the proxy is not properly configured.
And, the move to 'The Cloud' may work for dynamic language programmers, since they are already used to crippled tools, but it simply can't scale to the degree of complexity we ('enterprisey' developers) need. They fu**ed up Eclipse with this Juno crap, and waste resources in these pointless endeavours. I think the time of relearn my keyboard shortcuts is really coming this time.
CloudSharper is another Web IDE that looks to be feature rich
by
Faisal Waris
It's built with F# which is also the initial language supported. Support for other languages is planned.
It is still being developed but here are some links for the curious (very few details as of yet):
i.imgur.com/bdaC3x4.png
twitter.com/CloudSharper
It is still being developed but here are some links for the curious (very few details as of yet):
i.imgur.com/bdaC3x4.png
twitter.com/CloudSharper
Will always need desktop IDE, why not make it great
by
Doug Schaefer
There are certain types of apps where it will always be awkward to build from within the cloud. Yeah, you can have an editor in a browser and push a button to build, but then how do I load and debug that app on the smartphone I have here on my desk?
Having an IDE on the desktop will always be the best solution for many environments so why not make it great. I look at other content provider tools, especially those used by designers, the Blender 3D modelling tool as an example, and they're beautiful. To see the IDE in that mode as the l33t labs guys have done with the guts of Eclipse driving it gave me a lot of hope that we can make Eclipse look great and a pleasure to use.
But I have to agree with Ronald as well, you can make the IDE look great but if the workflows are horrible, or worse - don't work, that rips away the "pleasure to use" part and just makes users angry.
So we really need both and there's lots of work ahead. I just fear that the focus of the Eclipse community is being pushed towards Orion and that takes away focus on making the Eclipse the desktop IDE great. And seeing the passion of Eclipse users, they deserve a great IDE.
Having an IDE on the desktop will always be the best solution for many environments so why not make it great. I look at other content provider tools, especially those used by designers, the Blender 3D modelling tool as an example, and they're beautiful. To see the IDE in that mode as the l33t labs guys have done with the guts of Eclipse driving it gave me a lot of hope that we can make Eclipse look great and a pleasure to use.
But I have to agree with Ronald as well, you can make the IDE look great but if the workflows are horrible, or worse - don't work, that rips away the "pleasure to use" part and just makes users angry.
So we really need both and there's lots of work ahead. I just fear that the focus of the Eclipse community is being pushed towards Orion and that takes away focus on making the Eclipse the desktop IDE great. And seeing the passion of Eclipse users, they deserve a great IDE.
Any IDE should worry about workflows
by
Ken Walker
You have to think of Cloud and mobile development like where we're at with VMs and operating systems. Nobody really wants a physical machine for every platform they develop for. Mobile is the same. Services like Build at PhoneGap or hosted sites for real device testing will be the way to go if you're supporting more than one platform or an ecosphere where there are too many devices to even contemplate owning. If you're submitting your code to an online repo to participate in the infrastructure described then what does it matter if your editor and debugger are in the cloud too?
I think some focus on Orion is a good thing for Eclipse as well. The workflows are being thought through, and lean and clean a methodology toward providing what you need when you need it. There's nothing stopping doing the same thing to Eclipse to make it great. IDEs should not just have features for the sake of having them. Workflows need to be part of the picture.
I think some focus on Orion is a good thing for Eclipse as well. The workflows are being thought through, and lean and clean a methodology toward providing what you need when you need it. There's nothing stopping doing the same thing to Eclipse to make it great. IDEs should not just have features for the sake of having them. Workflows need to be part of the picture.
Re: Any IDE should worry about workflows
by
Doug Schaefer
I fully agree. Orion is a great new direction leading to a new way of developing software. I don't know if it matters whether it's great for Eclipse or not. It does matter that it's great for developers who want to write their software that way.
And if the user community I support wants that, I'll be there to help support it, just as I do users who don't want to use any IDE and are happy with vi and command-line tools.
But my worry is that in the desktop IDE space, Eclipse has strong competition. If my users start see the alternatives as more desirable, I'll need to follow them there. And that would be a sad day. But it doesn't need to happen that way and I will keep fighting to keep the Eclipse desktop IDE relevant.
And if the user community I support wants that, I'll be there to help support it, just as I do users who don't want to use any IDE and are happy with vi and command-line tools.
But my worry is that in the desktop IDE space, Eclipse has strong competition. If my users start see the alternatives as more desirable, I'll need to follow them there. And that would be a sad day. But it doesn't need to happen that way and I will keep fighting to keep the Eclipse desktop IDE relevant.
Random stuff about Eclipse
by
Mike Lythgoe
What was the point of that article? It talked about why Eclipse has historically used SWT, reasons which are now fairly irrelevant, then said IDEs will probably move to be Web apps, which is what many people are saying all apps are going to be, which isn't something I agree with.
IDE in the web
by
Yann Cébron
Why would people store their company's sensitive intellectual property somewhere in the cloud? Why would they make their work environment 100% dependent on 3rd party service providers? Why should they introduce additional technical challenges and possible problems using a full-time remote connection to be able to work?
I just don't buy this whole "IDE-in-the-cloud" thing yet.
I just don't buy this whole "IDE-in-the-cloud" thing yet.
Robustness, that's all we need from Eclipse
by
Luca Veronese
If this is the future of IDEs then I'm disappointed.
Eclipse has been losing in robustness and performance at each release.
Juno is really a crap.
That's what I need. Robustness and performance.
Fancy effects are good for videogamers, not for Enterprise developers.
Eclipse has been losing in robustness and performance at each release.
Juno is really a crap.
That's what I need. Robustness and performance.
Fancy effects are good for videogamers, not for Enterprise developers.
Re: IDE in the web
by
Faisal Waris
We need "always on" internet connections anyway to look up information as we are writing code (at least I do). I am constantly looking at help information on APIs, code samples, etc. as I am writing code. Granted there are a few times when I can just focus on the code on hand.
IP protection is an issue but with CIA singing a deal to use the Amazon cloud the trend is clearly towards cloud for almost everything. See fcw.com/articles/2013/03/18/amazon-cia-cloud.aspx.
I think the key question is whether a web IDE can provide a similar experience to a full featured desktop IDE. Only time will tell.
As developers we are very finicky and can get easily frustrated if the IDE is not working for us.
IP protection is an issue but with CIA singing a deal to use the Amazon cloud the trend is clearly towards cloud for almost everything. See fcw.com/articles/2013/03/18/amazon-cia-cloud.aspx.
I think the key question is whether a web IDE can provide a similar experience to a full featured desktop IDE. Only time will tell.
As developers we are very finicky and can get easily frustrated if the IDE is not working for us.
Re: IDE in the web
by
Yann Cébron
@Faisal: I'm not always on. Many people aren't - they are travelling or working from locations where (fast) internet is not available.
Storing sensitive data and intellectual property the existence of your company depends on at cloud storage providers where any secret service might (and actually does, see PRISM) access your data in uncontrollable ways seems like a total no-go to me, not even talking of security problems like hacking or leaking. Maybe locally hosted "cloud" IDEs might be safe enough.
Storing sensitive data and intellectual property the existence of your company depends on at cloud storage providers where any secret service might (and actually does, see PRISM) access your data in uncontrollable ways seems like a total no-go to me, not even talking of security problems like hacking or leaking. Maybe locally hosted "cloud" IDEs might be safe enough.
Re: IDE in the web
by
Tyler Jewell
Disclaimer: I am CEO of Codenvy, a cloud IDE. And I am an investor in InfoQ, though I wish that investment got my company coverage! :)
Our community has over 65K users and we learned a lot about the value of cloud relative to desktop IDEs. The pain that we solve is around administration. Developers surveyed on LinkedIn by Electric Cloud indicated that they spend 13 hours / week administering their desktop environment. This is about 2/3 of their time coding, and 1/3 dealing with administration, maintenance, starvation, merge, and human costs. If you happen to be using Eclipse, this number tends to even be higher.
The value of a cloud IDE is that is an instantly provisioned environment. Our IDE is targeted for use by teams working on complex applications with multiple dependencies. We do have intellisense capabilities, but not the degree of an IntelliJ or Eclipse. But the cloud IDE contains a complete workspace: IDE, project, build system, and runtime for debugging. All of the components are automatically configured by project type or PAAS deployment target. We do heavy lifting to reduce failure rates.
The workspaces themselves are team oriented, so they can be used in a Webex style, a google docs style, or replicated like a GitHub clone.
The programmatic nature of an IDE is a big benefit for ISVs who are seeking ways to simplify the evaluation workflow for developers of an SDK or API. It is possible to launch a cloud IDE that is integrated to an SDK or API, taking the time to Hello World down significantly. Reducing the error rate for evaluation or support scenarios means a developer is more likely to adopt a technology.
As a result of this, we see three types of users adopting a cloud IDE. Those that kick the tires, and compare it against their desktop equivalent. It's more of an experiment. The primary users who are using it entirely as their primary workbench. And a new class of users that I call Auxiliary. These users have a primary workbench that is another tool, but use a cloud IDE for commutes, on vacation, with a mobile device (say to check an issue), hackathons for brief periods, or for onboarding to a new project, or those pinned to a chromebook. It's all of the situations where someone just wants to hack briefly, and not deal with the setup or configuration.
Other commenters are stating a concern about always-on connectivity. Interestingly, on our feedback page where we have 1000s of votes, offline access isn't in the top 5 requested features. It is a concern for some people, but for the most part, those with chromebooks are always connected. But even so, it will be possible for companies like us to offer an offline mode by syncing the code repository to the local machine. There are ways to enable this activity.
Thanks for the great conversation.
Our community has over 65K users and we learned a lot about the value of cloud relative to desktop IDEs. The pain that we solve is around administration. Developers surveyed on LinkedIn by Electric Cloud indicated that they spend 13 hours / week administering their desktop environment. This is about 2/3 of their time coding, and 1/3 dealing with administration, maintenance, starvation, merge, and human costs. If you happen to be using Eclipse, this number tends to even be higher.
The value of a cloud IDE is that is an instantly provisioned environment. Our IDE is targeted for use by teams working on complex applications with multiple dependencies. We do have intellisense capabilities, but not the degree of an IntelliJ or Eclipse. But the cloud IDE contains a complete workspace: IDE, project, build system, and runtime for debugging. All of the components are automatically configured by project type or PAAS deployment target. We do heavy lifting to reduce failure rates.
The workspaces themselves are team oriented, so they can be used in a Webex style, a google docs style, or replicated like a GitHub clone.
The programmatic nature of an IDE is a big benefit for ISVs who are seeking ways to simplify the evaluation workflow for developers of an SDK or API. It is possible to launch a cloud IDE that is integrated to an SDK or API, taking the time to Hello World down significantly. Reducing the error rate for evaluation or support scenarios means a developer is more likely to adopt a technology.
As a result of this, we see three types of users adopting a cloud IDE. Those that kick the tires, and compare it against their desktop equivalent. It's more of an experiment. The primary users who are using it entirely as their primary workbench. And a new class of users that I call Auxiliary. These users have a primary workbench that is another tool, but use a cloud IDE for commutes, on vacation, with a mobile device (say to check an issue), hackathons for brief periods, or for onboarding to a new project, or those pinned to a chromebook. It's all of the situations where someone just wants to hack briefly, and not deal with the setup or configuration.
Other commenters are stating a concern about always-on connectivity. Interestingly, on our feedback page where we have 1000s of votes, offline access isn't in the top 5 requested features. It is a concern for some people, but for the most part, those with chromebooks are always connected. But even so, it will be possible for companies like us to offer an offline mode by syncing the code repository to the local machine. There are ways to enable this activity.
Thanks for the great conversation.
Re: IDE in the web
by
Doug Schaefer
@Tyler looks like you just got yourself a free ad :)
But seriously. I'd live to hear from a cloud IDE user. They're the ones who matter.
But seriously. I'd live to hear from a cloud IDE user. They're the ones who matter.
One can only hope
by
Jeff Heon
"...the next decade is likely to bring about significant UX changes in the way that code is edited, debugged and built."
Yes, let's fundamentally rethink IDEs, not just a simple web-based or not discourse.
Get inspired:
How to Think Like a Pioneer
Yes, let's fundamentally rethink IDEs, not just a simple web-based or not discourse.
Get inspired:
How to Think Like a Pioneer
Re: One can only hope
by
Faisal Waris
At least one fundamental rethink in IDEs/languages is that of Type Providers in F#.
Essentially type providers allow you to take external metadata and expose that as types in your language -- as you write code.
For example lets say you want to access a Hadoop dataset in typed way. Here is what you can do:
The code above is calculating the average "age" across the "bankmarketing" dataset. The actual calculation runs in Hadoop; here we are just expressing the logic.
The key is that all datasets (including "bankmarketing") and all their fields are available as F# types with full support for code completion (intellisense in MS world) -- just by referencing the type provider with connection info.
There is a behind-the-scenes interaction between the type provider the IDE and the compiler that makes it all seamless.
You can actually tryout this code here www.tryfsharp.org/Learn/data-science#hadoop .
There many type providers available already and new ones are being written all the time. It is a very successful innovation.
Essentially type providers allow you to take external metadata and expose that as types in your language -- as you write code.
For example lets say you want to access a Hadoop dataset in typed way. Here is what you can do:
type HadoopData = HiveTypeProvider< ... connection info ...>
let hive = HadoopData.GetDataContext()
let avgAge =
hive.bankmarketing
|> Seq.averageBy (fun b -> float b.age)
The code above is calculating the average "age" across the "bankmarketing" dataset. The actual calculation runs in Hadoop; here we are just expressing the logic.
The key is that all datasets (including "bankmarketing") and all their fields are available as F# types with full support for code completion (intellisense in MS world) -- just by referencing the type provider with connection info.
There is a behind-the-scenes interaction between the type provider the IDE and the compiler that makes it all seamless.
You can actually tryout this code here www.tryfsharp.org/Learn/data-science#hadoop .
There many type providers available already and new ones are being written all the time. It is a very successful innovation.
