What exactly is it that makes it a worthy replacement? (Yes, I'd like opinions on this; I haven't looked deeply at the guts of the matching algorithms.)
My guess: File size (in a brief check, Rainbow appears to be about half the size, unpacked), active development, and use of github (code-prettify is a few years old, hosted via SVN on Google code, and updated infrequently.)
However, prettify has a much broader range of languages already available for use.
This is what @export (and the related functions in the library for if you are not using annotations) are for. In the context of Closure, this is clumsy. But I expect that not all other minifiers offer the same flexibility.
No, it's not useless when it comes to advanced minimization when Rainbow.onHighlight might be minimized to Rainbox.a. By doing Rainbow['onHighlight'] ensures a method called onHighlight exists on the Rainbow object.
I ported a theme called Tricolre across which is much more subdued, the pull request just got accepted a few minutes ago. Hopefully I can get a few more themes done, they're very simple to create. The joy of open source is that if there's something you don't like about someone's code, you can just fork it and make whatever changes you want.
Is there a way to style dynamically inserted <code> blocks (say inserted via an ajax call) after the page loads? I did not see an equivalent of the prettify() function of google-code-prettify that lets you do this. Looks great otherwise.
This thing was written in ~2 weeks, so there's no way it can compete with a project that's 2 years old! It can either stagnate or evolve, but I think that the way the code is laid out will encourage a lot of collaboration. Personally, I love and use Highlight, but (I confess, as a textmate ho) I'd like to see rainbow improve. Competition is always good. Maybe you guys can/should help each other?
No one says you should. It's an alternate implementation. I don't understand the "competition" angle, is there a paid version for both of these projects that is forcing people to choose one over the other?
That's actually how I started this project! I started working on making a syntax highlighter that could pull in TextMate tmLanguage files, but then I ran into a lot of issues and decided to spin it off into this :)
That is why the syntax in Rainbow is pretty similar.
1. TM syntaxes are complicated. There's lots of undocumented features that bundles find ways to use in crucial places.
2. TM is slow. You don't see this so much because it's written in C++ and there's many clever optimizations (see point 1). But it's difficult to get around the fact that a syntax is hundreds of regexes that have to be run over the whole document in a pathologically slow manner. I hate to think what it would be like in JS.
3. Many TM language definitions are dependent on features of the Oniguruma regex engine, which is strictly more powerful than any JS one. So you basically have to compile Oniguruma (no mean feat) ...with emscripten.
This is very unfortunate, I'm never satisfied with syntax highliting and color schemes except in Sublime/TextMate. I've found it to support much more unique bits of grammar in code than vim's syntax highliting and there are tons of great themes available for it.