Two years ago I started sharing/backing up some photos/textures on Flickr. Like many others I used Uploadr to do this, and the more I was using it the more a felt annoyed by the lack of a simple yet invaluable feature: being able to zoom into a thumbnail (or at least launch a native OS preview)... you know, just like when you're parsing a bunch of small 100x100 picture's thumbnails on your hard drive and naturally expect that double-clicking one of them would obviously open a wider version (deadly useful to compare pictures quality). Well, Uploadr just doesn't do that.
I first thought that Yahoo (makers of Uploadr and owners of Flickr) would quickly "fix" that. Then I tried a bunch of third party software to replace Uploadr, but none of them was able to cover my needs as well as Uploadr did. In the other hand, I didn't wanted to spend any time in modifying the Uploadr's source code as I really thought the guys at Yahoo would quickly come with a nice and sustainable solution (far better than the ugly hacking bypass I was going to inject).
Two years later, I came to the conclusion that they would probably not add this feature anytime soon. So I decided to dig a little bit in the source code and get that thing done.
I feel at ease (or at least pleased) when I do shaders, game prototypes, and 3d related stuff in general; but going into modifying Uploadr was pretty far from my usual confort zone... yet, in many ways it remained an interesting experience.
Javascript was ok, but XUL is a framework you have to learn and understand at a very least in order to create some extension (for Uploadr or Firefox).
At first, I just started hacking and poking around, hopping I could do some tricks without diving too far into the XUL documentation. And that was true thanks to the powerful openness of Javascript and the data-driven nature of XUL.
But as soon as I wanted the "hacks" to be packaged into some kind of plugin (called extension here) I found myself a little bit lost as I didn't knew how to cross-communicate variables between XUL windows.
And so here I came reading and trying to find my way to reach this little piece of information so relevant to me at that moment. It took me some time of googling... I didn't knew that each XUL window had its own javascript execution context, so I couldn't even google "cross window context communication in XUL" (which would quickly gives relevant results for sure).
The answer came when I finally decided to start reading the documentation from the beginning as if I was planning to follow a 3-weeks XUL course.
The answer came when I finally decided to start reading the documentation from the beginning as if I was planning to follow a 3-weeks XUL course.
Sure once you know where to find this simple information the path looks bright and obvious and you just feel dumb not having started reading "the fucking manual", but if I hadn't said to myself "ok, you'll have to be prepared for a long run into that learning process", I would probably not found the correct way and just given up ('cause after all, my goal was not to get a degree in XUL programming!). The fact is I didn't had to invest 3 weeks into learning XUL at the end, but everything was like I should have been mentally prepared to do so.
The pain of "searching and learning" is intrinsic to big-frameworks. And this is not just about XUL, it's about almost any framework (and to be really sincere, XUL is pretty easy to learn in fact).
The bigger the framework is, the more you have to read the documentation in order to use it and fulfill even the simplest tasks.
The bigger the framework is, the more you have to read the documentation in order to use it and fulfill even the simplest tasks.
That's an ugly and tangible truth, and yet it seems to be a common sense shared by most programmers used to navigate among huge projects or huge companies...
And I can almost say it's hopeless because us, as programmers, we love to build solutions that would solve as many issues as possible, and we love to factorize algorithms so that one can serve many.
But the more we enlarge the scope of a framework, the bigger the framework becomes and the harder it is to be understood (that's the main reason we like to throw away other's work and reinvente the wheel again and again).
It seems obvious and natural to fall into this pattern, creating bigger and bigger... but if that was really the solution there should exist a godfather-framework, able to contain every kind of design pattern and providing kernel solutions suitable for any kind of program. This god-father framework would then get rid of the OS itself and become at the same time the OS and the unique programming language.
Such a framework would be to programs what the earth is to life: the most complex biosphere.
Most programmers can "feel" that such a thing would be a real nightmare to solve and maintain, and nobody would seriously think about creating this; because life (program) is intended to be functional and local to a given environment. There's no such thing as an ubiquitous intelligent machine driving everything, because life pops up everywhere and results in a local adaptation to the context.
So does a program.
If I was to get really extreme in that direction I would even say that there should only be environments (contexts) and tools (snippets); let the life (program) create its own complexity through DNA grammar (language).
Bigger frameworks means;
- Slower innovation to modify the framework (cautions has to be taken to maintain global coherence)
- Slower bug fixes (caution not to break any cross dependencies)
- Spending entire days glueing the framework together instead of implementing features and algorithms, or bug fixes.
- Cumbersome back-compatibility issues.
- Bigger latency to answer user requests (due to numerous time leaks)
- More time spent writing the documentation for the author (in order to glue concepts together and create a coherent hierarchy)
- More time spent reading the documentation for the user (as the user must find his way into the hierarchy and concepts)
- Steeper learning curve for anyone who wants to join the "big" project, or often just use it.
- Endless build processes.
- ... And so on.
I can't find as many arguments to sustain big-framework-addictions (but I do admit and understand there is positive arguments).
10 smaller frameworks/libraries will always give more satisfaction to authors than one unique Über framework -- unless you early dedicate yourself to the exclusive study of this Über framework and quickly become a Jedi master!
Did I said "satisfaction" ? Hey, who ever said software engineering was about satisfaction anyway [sic] ?
Ok, I will end up here this little digression, and for what it's worth, if you're looking for a complete data-driven, open source and robust framework to create cross-plateform applications, XUL/XULRunner seems to be a wise candidate (especially if you want to take advantage of the huge pre-existing Firefox extensions community).
... and would you be curious about this tiny-ugly extension of mine, just look at ZoomThumb Uploadr extension.
