Rainbow.js - code syntax highlighting in 1.2kb(craig.is)
craig.is
Rainbow.js - code syntax highlighting in 1.2kb
http://craig.is/making/rainbows
10 comments
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.
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.
It's under Apache 2.0. Just not specified in a LICENSE file yet.
https://github.com/ccampbell/rainbow/blob/master/js/rainbow....
https://github.com/ccampbell/rainbow/blob/master/js/rainbow....
Ah, thanks, didn't spot that.
Wonderful presentation with the fade in.
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."
Rainbow["onHighlight"] = Rainbow.onHighlight;
https://github.com/ccampbell/rainbow/blob/master/js/rainbow....
This is because I'm using Google Closure Compiler in advanced mode so all methods that do not get used get renamed.
In order to preserve the methods and keep them public you have to reference them like this.
In order to preserve the methods and keep them public you have to reference them like this.
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.
[1]: https://github.com/ccampbell/rainbow/pull/3
[1]: https://github.com/ccampbell/rainbow/pull/3
I like the declarative way of defining/extending the highlighters in code. Clean, direct and easy to grok if you're familiar with regexps.
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.
Looks to me like Rainbow.init() would do it.
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
Thanks! Looks like Issue#6 has already been created.
So... why should I use this instead of http://softwaremaniacs.org/soft/highlight/en/ ?
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.
You shouldn't. There are just too many errors in highlighting.
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?
I believe if you are making some new application solving problem which has existing solution you should at least provide some clues why it was done.
This is fantastic. Beautiful presentation and beautiful code.
Thanks!
Thanks!
[deleted]
I would love to see a javascript highliter that consumes TextMate syntax definitions.
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 (.*)
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 (.*)
The problems I see are:
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.
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?