The goal wasn&#x27;t to use HTML.  Our goal was somewhat different.  When I started Codenvy, it was after I had a pretty bad experience with developer tools.  I had been offline from programming for 7+ years and lost most of my skills.  When I tried to get current with maven, java, eclipse, tomcat, I was unable to get a simple program to compile.<p>I had a simple thought - it should be possible to let anyone anywhere contribute to any project without first installing software.  you should be able to click a link and then everything you need is generated for you - the workspace, the projects in that workspace, the environments that power those workspaces.<p>Now, if you are on a desktop, you may want to wire in your existing IDE to integrate with that workspace. But if you are a product manager and just want to test some code, you don&#x27;t want to install anything.  So a browser experience is necessary then.<p>Generally, we have never seen the browser experience as the replacement objective or substitute. But it is a necessary deliverable for those who do not wnat to bother with installing software first.<p>Codenvy takes Che and is working to provide this sort of no-install workflow around a concept we call factories. You start in a private anonymous screen, click a link and everything you need to continue working is there.  Really hard problem - that is what we focus on commercially.<p>But at the core of it, we needed a portable workspace server that had a web IDE.  We chose GWT for the development of the GUI because of the cross browser portability and performance optimization. It&#x27;s a brutal technology but we get a lot of nice optimizations.  We have started some explorations to support Vaadin for dynamic reloading of widgets and have some partners who may help us with a pure JavaScript client, too.<p>We are embedding all of the language services within the machines that power the environments that the workspace is bound to. We use either localhost or docker depending upon your configuration. Since everything is within, the actual comms between browser and the workspace machine is limited. So you can get a pretty darn good expeirence.  The file operations are localhost native, so we are able to process Java files with 50K lines at about the same speed that Eclipse or Netbeans does (minus the part of the file system being inside of the docker container).