Paradigm smashing

In Flux: Martin Lippert on the mission to bridge the desktop and cloud IDE divide

Lucy Carey

Pivotal‘s Martin Lippert outlines Eclipse’s groundbreaking new server-facing project.

Pivotal‘s Martin Lippert outlines Eclipse’s groundbreaking new server-facing project, Project Flux.

JAX: Can you outline the project for our readers?

Lippert: Project Flux is a new project at Eclipse. It’s about moving towards the cloudbased IDE. Project Flux tries to solve two different problems in cloud base architecture: first, the idea that future developer tooling will in some ways be based on the cloud, or run on the browser instead of the classical desktop idea. But don’t really know what this is going to look like.

There are certain ideas about just implementing exactly the same IDE that’s running on the desktop at the moment, just running in the browser. But I don’t think that’s the right way. So Flux is about trying to finding out what this tool could look like, and how it could be implemented.

The second part is that, if you took a look at approaches to cloud based developer tooling today, people are building something that’s running inside the cloud, you can access it with a browser ­ and that’s it.

You have to jump over the wall into this cloud based world, and then you are caught there. You have to check out your stuff in the cloud, and leave everything else you were working on behind on your desktop IDE. It’s a totally separate world. It’s quite difficult for people to jump over this wall because of the either­or decision they have to make. So this step is quite huge.

Flux is trying to build a bridge between those two worlds, so toolmakers like myself can move towards cloud based development tooling in a very smooth and slow way. People can start using cloud based developer tools at the same time, while they are continuing to use their IDE. Cloud tooling is quite feature rich now ­ but you don’t want to leave everything behind. Thats’s the basic thing we’re trying to solve with Flux.

Originally this was known as Project Flight right?

Yes, Flight was our first name. But right before we made it public and presented it to Eclipse, we saw that there was this project from Twitter that was also call Flight ­ so we decided it wasn’t such a good idea to have two projects with this name! Anyway, I totally dig the name Flux too ­ like the Flux capacitor thing in the Back to the Future movies.

Going back to what you were saying before, there is a cognitive dissonance between developing for the cloud and IDE. Why do you think this is?

I’m not sure. I think many of the elements that you have in your desktop and IDE, they are the usual elements ­ they’re very familiar and you’re used to them. You have your navigator and the open tabs and so on. Whereas on the browser, they are trying to rebuild exactly this, and to me, that feels a little strange. It’s not really adopting the idea of web applications.

Interestingly, at the Orion Projects at Eclipse, they are trying to move away from the IDE paradigm, but are finding that people actually want these elements included. Maybe it’s just the natural way of doing things, or maybe the old way is actually better.

But I like to step away, and step back from these traditional views, and trigger new thoughts about these things. And maybe you’ll end up building similar things that are there in existing desktop IDEs if it’s a good solution. I’m not totally sure what the future cloud based developer tool will look like exactly ­ we have a lot of ideas, and have built prototypes and things like that, but I don’t have a perfect vision. I think it will evolve over time.

Do you have an idea for the basic blueprints for the architecture of Flux?

Yes, we have a pretty clear vision for the architecture of Flux, and it’s totally different to what we have in current desktop IDEs. The basic idea is for that first of all, you have very loosely coupled components that are running in a cloud based environment. Those very small loose components are kind of micro services, and are all connected with asynchronous messaging.

There’s no RESTful API ­ there’s no server that you call to do some stuff. They are just communicating with messages. That means that on top of these messages, there’s some kind of synchronisation protocol being implemented so that the desktop IDE can connect with these messaging systems. The cloud based components can then exchange messages about how you changed the file, what you’re typing, things like that.

So, Flux is implementing these synchronized messaging systems, based on this asynchronous messaging. it’s a little like DropBox for code. Your files in your desktop IDE, you can connect to Flux ­ it feels very seamless, but it’s all being backed up automatically on the cloud. That’s a very fundamental backbone of Flux.

On top of that, those components that are running inside the cloud, they can participate in these synching mechanisms as well ­ and that’s very interesting, because it opens up a whole load of new possibilities for building these microservices inside the cloud. It opens up a whole new world of possibilities, and to me it’s a huge foundation for the future.

Everytime I think about this architecture, there are new ideas come up. Every time I speak to someone, I get new ideas. It opens up a whole new world of possibilities, and to me it’s an awesome foundation for the future of cloud-based developer tooling.

Martin Lippert

Martin is a Principal Software Engineer at Pivotal and works on development tools for the Spring Framework, Cloud Foundry and JavaScript. Together with his team, he is responsible for the Spring IDE, Spring Tool Suite and the Cloud Foundry Integration for Eclipse. Martin is also co­founder of it­agile GmbH, one of the leading agile companies in Germany. He is interested in Agile and Lean Software Development, refactoring techniques, innovation, and the delivery of high­-quality open­-source software.

Paradigm shift image via Shutterstock

Inline Feedbacks
View all comments