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.
I came here to say the same thing. I had read about two paragraphs in and thought: "Wait, I thought this was supposed to colorize the code...ooooh nice."
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.
Why do people make pages highlighting colorizing things, and then make the subtitle of the page (and other text) be blue on black? This does not inspire confidence.
Purple and orange and green and white on dark blue. My eyes hurt reading this.
Pick a couple of colors with relatively high contrast, and make sure the text isn't lighter than the background.
I ported a theme called Tricolre across which is much more subdued, the pull request[1] 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.
Yeah I just have to make Rainbow.init() public and make it ignore blocks that have already been processed. Then this will work. Feel free to make a ticket for me on https://github.com/ccampbell/rainbow/issues
Hehe, I was just going to suggest running Rainbow against highlight.js's test suite. I doubt it would do nearly as well. Sagalaev's highlighter is awesome, he put a lot of work into it.
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?
Correction: highlight.js is 6 years old :-). And yes, I'm going to look into Rainbow more properly for useful ideas. And I encourage Craig to do the same. Isn't Open Source awesome? :-)
It is. And holy crap, 6 years, wow... time flies! I'm keeping track of both of you now. I know that collaboration on projects like these is almost impossible. Do you guys live near e/o? heh
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.
The main problem had to do with Javascript regex not fully supporting everything that most languages support such as negative/positive lookbehinds and (.*)
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.
I can't see the license specified anywhere, any chance you could add a LICENSE file or similar?