4 ms·

I like the general idea of this. Considering how much of a resource hog modern C++ compiler is for example (I hear good things about Scala as well) it would be

I like the general idea of this. Considering how much of a resource hog modern C++ compiler is for example (I hear good things about Scala as well) it would be nice if I could use a lightweight low powered front end machine to edit code and then have the backend bother with parsing, compiling, etc. People do this already with distributed builds so why not make it baked into IDE with code analysis as well. Maybe the OS can even save memory if you run multiple instances on stuff like executables, etc. What I really don't like is how developers are pretending that HTML is the only client side technology if you go client->server route. To me architecting this as a HTML app shows 0 benefits - the install time is irrelevant - I am a developer - I know how to install applications and I do this for all my other IDEs, the time it takes me to install a thin client is irrelevant. All this "use JS/DOM as front end" does is either : compile to JS -> introduce an extra compile step, a shitty VM emulation, worries with interop and leaky abstractions use JS -> poor semantics and both are abusing a layout model made for documents into application development model that gets really inefficient at rendering. IDEs are at the top of GUI complexity - why make shit even more complicated by doing things that slow development down - if they would for example write the frontend in something like JavaFX (not having used JavaFX I'm only speculating here, but I heard good things) it would probably be equally good (if not better) and at the same time it would make development a lot simpler.

PaulHoule 11y ago
I think Eclipse was slow enough before the JS/DOM thing came a long. Back in the bad old days GNU emacs was written in LISP but it always seemed pretty peppy. Today there are a lot of editors written in modern scripting languages and/or the JS/DOM environment such as Atom and Light Table and they all seem just a little bit laggy.
- TylerJewell 11y ago
  The goal wasn'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. 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. 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't want to install anything. So a browser experience is necessary then. 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. 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. 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'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. 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).
- noxToken 11y ago
  I've only used three different IDEs/editors with regularity: Eclipse, IntelliJ and Sublime Text. I've dabbled with others like Atom and Brackets, and you're right, they all seem to have a bit of "heft" to them - except for Sublime Text. It starts up quickly. It's closes quickly. It's always immediately responsive. What makes it different from the others?
  - stronglikedan 11y ago
    Python (ST) vs. Java (Eclipse, IntelliJ)? I really don't know. I'm just speculating based on what I've read about both languages.
  - MrBuddyCasino 11y ago
    Sublime is an editor, not an IDE, isn't it? Afaik it does not have a complete model of the code in my workspace, the way Eclipse would.
    - noxToken 11y ago
      True. It's only an editor. That's why I brought up Atom and Brackets. Neither of them are slow per se, but they don't feel as instantaneous as Sublime Text. No matter how many plugins I throw in there, the size of my project, the number of files open, ST always feels like the most responsive thing I've ever used. I don't have any objective data, but perhaps it's due to the Kool-aid. It was the second text editor I used (Notepad++ being the first). I fell in love immediately.
      - MrBuddyCasino 11y ago
        No I agree, ST feels just right. Why anyone would want to use the DOM and JS for the view layer in a project as demanding as an IDE is beyond me. When I put my ear to the ground and listen really hard, I can hear the vibrations of a herd thundering by in the distance. I think I know that noise, I've first heard it when people were XMLifying everything back in 2000.
        11y ago
- smacktoward 11y ago
  Back in the bad old days GNU emacs was written in LISP but it always seemed pretty peppy. Back in the really old days, when desktop computers came with just a few megabytes of RAM at most, people used to joke that emacs stood for "eight megs and constantly swapping."

PaulHoule 11y ago

I think Eclipse was slow enough before the JS/DOM thing came a long. Back in the bad old days GNU emacs was written in LISP but it always seemed pretty peppy. Today there are a lot of editors written in modern scripting languages and/or the JS/DOM environment such as Atom and Light Table and they all seem just a little bit laggy.

TylerJewell 11y ago
The goal wasn'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. 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. 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't want to install anything. So a browser experience is necessary then. 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. 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. 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'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. 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).
noxToken 11y ago
I've only used three different IDEs/editors with regularity: Eclipse, IntelliJ and Sublime Text. I've dabbled with others like Atom and Brackets, and you're right, they all seem to have a bit of "heft" to them - except for Sublime Text. It starts up quickly. It's closes quickly. It's always immediately responsive. What makes it different from the others?
- stronglikedan 11y ago
  Python (ST) vs. Java (Eclipse, IntelliJ)? I really don't know. I'm just speculating based on what I've read about both languages.
- MrBuddyCasino 11y ago
  Sublime is an editor, not an IDE, isn't it? Afaik it does not have a complete model of the code in my workspace, the way Eclipse would.
  - noxToken 11y ago
    True. It's only an editor. That's why I brought up Atom and Brackets. Neither of them are slow per se, but they don't feel as instantaneous as Sublime Text. No matter how many plugins I throw in there, the size of my project, the number of files open, ST always feels like the most responsive thing I've ever used. I don't have any objective data, but perhaps it's due to the Kool-aid. It was the second text editor I used (Notepad++ being the first). I fell in love immediately.
    - MrBuddyCasino 11y ago
      No I agree, ST feels just right. Why anyone would want to use the DOM and JS for the view layer in a project as demanding as an IDE is beyond me. When I put my ear to the ground and listen really hard, I can hear the vibrations of a herd thundering by in the distance. I think I know that noise, I've first heard it when people were XMLifying everything back in 2000.
      - 11y ago
smacktoward 11y ago
Back in the bad old days GNU emacs was written in LISP but it always seemed pretty peppy. Back in the really old days, when desktop computers came with just a few megabytes of RAM at most, people used to joke that emacs stood for "eight megs and constantly swapping."