I’m having big doubts about how much time and effort I should invest in learning to program Komodo. It seems that, whichever way I go, Komodo Edit won’t be adequate and I’ll have to program to fix its bugs and/or add even little features that are needed — like not losing my Places when the drive gets mounted, for example, which you guys will never fix. Fine. I’m not lazy—I can put in some effort.
But I’m really worried about the whole XUL thing. I realize that Mozilla is throwing out XUL plugins. But what mean for Komodo Edit? Isn’t Komodo built on XUL? Is Mozilla committed to the underlying XUL framework? Will I be devoting time to learning something that is a dead end?
Atom Editor for example seems much more flexible and extensible from the ground up. Many things “just work” out of the box, and you can easily add plugins in JavaScript. They have a nice package manager system that even works from the command line. Atom seems to be using the latest trends in applications—not old, clunky frameworks such as XUL but nimble frameworks such as Node.js and CoffeeScript.
This is not a rant—it’s a real request for feedback. I’m torn between the two. Whether I go with Atom or Komodo I’m going to have to put significant time and effort into learning the framework, because each has its own drawbacks and bugs that I’ll have to fix. (“Open with Atom” forgets the project directory; Komodo forgets Places when the drive is dismounted; etc.)
You’ve touched on this before, but @nathanr, could you give us a clear explanation about whether the underlying framework of Komodo is in danger of being abandoned by Mozilla; and about the long-term evolution for the Komodo platform and plugins?
Something you need to understand is Komodo uses a specific version of the Mozilla framework. Sometimes we decide to upgrade, but often, for our use case, it is not necessary. It’s not because Mozilla stops supporting XUL in its latest versions that all of a sudden XUL will break for us. We have a fully working version of Mozilla and currently no real reason to move away from it, though I’m sure that time will come.
What this means though, is that we get to decide when it’s time for us to move away from XUL. We could theoretically (not saying that’s what the plan is) keep using XUL for years to come. We probably won’t, but we could.
Realistically what you’ll be seeing is we’ll be moving more and more towards HTML5, just like Mozilla. Many of our new code uses HTML5. Additionally all of our new modules are modularized to a degree where the underlying markup language is irrelevant. If we were to switch Komodo from HTML5 in its entirety tomorrow then the underlying SDK’s would be changed accordingly also, and code that used those SDK’s will continue to function without needing any changes (or very little).
And you know what? We’d probably be doing this regardless of XUL reaching end of life or not. It’s only logical.
Of note; of course any new editor out there is going to be using more modern and popular technologies. When Komodo was first released it was the same in that regard. Long term that doesn’t mean much though. Atom is largely based on Coffeescript, which honestly it would not surprise me if it would be facing a similar situation as XUL in the years to come. Would that mean the end of Atom? Of course not.
Thanks for the response @nathanr. If I could probe a little further to better understand this. Is the Komodo Edit application itself written in XUL, or only the extensions?
You seem to be saying that only the plugins use XUL, and that the Komodo UI itself uses something else—and that you could switch out the markup language for just the plugins without disturbing the main application itself. Am I understanding that correctly? If not XUL, what framework is Komodo Edit using at its core?
Komodo uses XUL and CSS for the UI (but a lot of new things are written in HTML5), Scintilla as Lexer and syntax highlighter, Python, C++ and JS for the functionality. There are some types of files that are related to Scintilla directly (UDL files for example).
Komodo mostly uses XUL under the hood, but we are using more and more HTML5 in our latest work.
Note that Firefox itself is still very much using XUL and will remain dependant on it for a while. They are only deprecating it so that their community stop using it, such that when the time comes for them to themselves make the switch to HTML5 their community will not be affected by it.
For what it’s worth, the Pale Moon browser (a fork of Fire Fox) seems committed to XUL and other FF features that Mozilla has or is abandoning. See http://www.palemoon.org/roadmap.shtml
I don’t know what it would take to switch from FF to PM, but, so far, I’ve had no problems using “traditional” FF extensions with PM.
Given the direction Mozilla has been taking, I’ve shifted my efforts to Pale Moon. Not saying that FF doesn’t have some new things worth having/using.