Making Extension Development Easier

5

As we mentioned in our brown bag last week, one of our goals is how we can make Firefox extension development a better experience.  We’ve listened to the community, taken copious notes, and want to pose this question to all of you:

How can we make the development of extensions easier?

From lots of impromptu conversations with our developer community, we know that there’s a lot we can do to help at all stages in the developer life cycle.  We’re still pulling together ideas and we want to get you involved by asking you to let us know what you think.

Towards this end, we’re going to post a survey this weekend asking you about your experience learning, developing, and publishing add-ons.  We’re looking for brutally honest feedback about your experience as a developer and ideas on how things could be better.  We want to hear it all, and we’ll use this info to help guide our thinking in 2009.

Looking towards the future, we’ll continue the dialogue with a series of blog posts and phone chats so that you’ll get the opportunity to see what we’re thinking and get involved in planning the future of extensions.  It’ll be fun!

Nick

Categories: developers

5 responses

  1. johnjbarton

    Not in order of priority.
    1. Extensions are stored in deliberately obscured locations. eg the cryptographic name of extension directories, eg the use of UUIDs
    2. Extensions rely on URLs with deliberately obscure relationship to the files system. chrome urls.
    3. Much of the documentation on extensions encourages pointless practices that confuse and slow developers, eg UUIDs, jar files, too many variations in the directory structure.
    4. Error messages for syntax or runtime problems often do not come out anywhere.
    5. Error messages are most often incomprehensible, even to mozilla experts.
    6. Error messages often don’t have file names or line numbers that make sense.
    7. Files are sometimes named by chrome urls sometimes by file urls.
    8. The rules for when the browser has to reloaded vs a window or a file are largely unknown.
    9. The documentation site is artificially structured and overly verbose.
    10. The overview documentation is very old and one never knows what to trust.
    11. The documentation of the security system is almost not existent.
    12. Generally the API caters to the the obscure over the easy. It is heavily influenced by C++ needs but most extensions are in Javascript.
    13. The development tools are broken or under developed.

  2. Curtis Bartley

    Better error messages. And by “better error messages”, I mean, you know, that there actually *are* error messages. I’ve found the required RDF files to be the worst offender on this count, but there are many other places where it’s a problem. Actually, now that I think about it, the RDF files themselves are a total pain in the ass. Don’t fix them, just out right get rid of them. Drive a stake through them and set them on fire. I understand why they’re there, but there’s just got to be a better way. Something as simple as replacing them with JSON might work. Well, JSON plus good error messages when you get something wrong. And you will get something wrong.

  3. robcee

    that is quite a list!

    I’d like to follow-up with a plea for better development tools. Chromebug is useful as a debugging tool, but what I’d really like to see is an integrated IDE for experimenting with code on the fly. An Eclipse-style workspace for executing JS/XUL code. It’s already interpreted, so doing this shouldn’t be that hard. Some experimental extensions get part of the way there, but there’s nothing cohesive and usable by itself.

    I think to go along with the better tools, better abstraction from the underpinnings of XPCOM would help a great deal. FUEL was a start towards this kind of separation layer, but we need to keep going with it.

  4. Jorge

    I agree with the previous comments. I’d like to generalize John’s point 3 to this:
    We need a clearer guide as to how to make an extension. The current XUL tutorial is *not* an extension development tutorial. We need something that users can follow easily, giving them access to common practices, frequently used code snippets, etc.

    And, of course, an IDE would be more than welcome. A set of recommended and maintained plugins for Eclipse or Komodo would work just as well.
    FUEL was a good step, but it’s still very lacking IMO. I also liked the direction Labs was taking, with modules like the logging and observer objects. Those are quite useful.

  5. Bob Anderson

    XMLHttpRequest supports responseText and responseXML. There is no responseHTML attribute. I have to brute force parsing with REGEX.