The Changelog: Software Development, Open Source - RaphaëlJS and Running an Open Source Project (Interview)

Episode Date: May 25, 2010

Wynn caught up with Dmitry Baranovskiy to talk about his project RaphaëlJS, running an open source project, and why living in Australia is better than living anywhere else in the world.

Welcome to the changelog episode 0.2.5. I'm Adam Stachowiak. And I'm Winn Nevelin. We cover what's fresh and new in the world of open source. If you found us on iTunes, we're also on the web At thechangelog.com We're also up on GitHub You can check out some training repos, some feature repos from our blog As well as our audio podcasts If you're on Twitter, you can check us out at

Changelogshow, not the changelog And I'm Adam Stack And I'm Penguin, P-E-N-G-W-I-N-N I had fun talking to Dimitri Baranovsky From Raphael JS this week That's quite the name, huh? It is. You know your name's long when Twitter truncates your name

and you try to choose it as a screen name. Oh, man. Cool project from Dimitri, Raphael, and its counterpart, Grafael, which I didn't get at first. I kept calling it G-Raphael, and he finally said, you know, Grafael. That's funny. Because when Raphaelffial does, it's a cool graphics library for JavaScript

and Graffial does graphs based on that. Oh, wow. It's pretty cool. Some nice looking graphs. It uses SVG under the hood instead of Canvas, which is kind of old school, but it's got some advantages as Dimitri gets into. Speaking of JavaScript, we'll be at Texas JavaScript June 5th.

That's right, over in Austin. Yeah, I'm looking forward to that one. It's got quite the lineup. I mean, it's in our backyard we have to go, right? It's going to be a lot of fun. It's not quite JSConf, but hey, everything's bigger in Texas, right? That's true. That's true. Cool. Well, I bet you're ready to see what we talked about. Let's get to the episode, yes. Let's do it. All right, we're joined by Dmitry Baranovsky from Raphael.js. Dmitry, I want you to tell the folks who you are and a little bit about Raphael. Okay. I'm a local software architect at AXT.S. Dimitri, I want to tell the folks who you are and a little bit about Raphael. Okay.

I work as a software architect at AXT.js. And Raphael started as my side project about two years ago. It's pretty much an adapter for vector graphics on the web. So it's a JavaScript library to draw some extra stuff. So what sort of project were you creating when you created Raphael to solve the problem? There were no any projects. I just created as a side, you know. Just for fun?

Yeah, just an experiment. I was playing around. I was creating, like, drawing stuff. It would be fun to draw something cross-browser. I have been playing with SVG a long time ago in year 2002

or something like that. And I was like, I could use SVG now here, here and there. And Explorer has VML, so maybe I could create function circle, which will draw a circle for me across browser. So I did, and oh, now I could do this, now I could do that. And then I showed it to my colleagues,

especially to Lachlan Hardy, who heavily supported me. He's like, oh, dude, it's awesome. You should create a library from it. Oh, sure, okay, well, you know, it You should create a library from it. I'm like, oh, sure, okay. Well, you know, it still has lots of bugs and lots of things not covered. But because it has such a great support,

I decided to actually release it after probably about two months working on it. I think it's ready to show it off. So that's a lot of work for a side project, especially to manage the cross-platform nature between SVG and VML. So did you set out to support VML for Internet Explorer out of the box,

or did that come later? No, it was in the beginning, because as a web developer, I feel like if I can't do this, whatever I'm doing, cross-browser, then it's just a toy. It's not real. And if I will do something, okay, I can do it, you know, draw these amazing things in Canvas, but it only works in Chrome, for example,

then it's just a toy. Yeah, okay, good. Can you use it really somewhere? No. So... For the folks that might not understand, haven't dealt with graphics and JavaScript that much,

explain the difference between Canvas and SVG and the different approaches. Right. So that's basically why I choose SVG instead of canvas because i had a choice of canvas and svg and i could pick up anything and i choose svg because it's closer to vml because in difference to canvas svg allows you to create elements just like any dom elements like you could create div and span the same way you could create circle and rectangle.

And then, you know, change the attributes. So in Canvas, you just separate these pixels. You create a model of circle, then you say paint this circle on Canvas, and you have just a bunch of pixels. You can't really take it back and update. You have to keep your model and basically redraw a circle if you want to make it, I don't know, red. You have to clean the canvas, draw it again with new shapes.

And in the SVG, you actually operate with DOM elements. As a result, you could attach on click events to circles, on mouse hover to curves, or whatever else you could think about. And the VML is basically the same. The VML is historically a grandfather of SVG, so they share the same concept. It's only that VML has a terrible

API. Just a terrible API. So recently you released 1.4 of Raphael, and it includes touch event support. Was this just for fun, or did you have a need to take this project to the mobile platform? This already was not basically for fun because I was doing another project for AXT, and it was like a small side project, I need to have drag and drop in iPad.

And, you know, I was writing just a code for this because you could just write everything straight in JavaScript. And then I decided, well, it would be nice to have it actually as a part of the library as soon as I'm writing it anyway. So I just included it into the library, make it more generic, make it nicer, and then just decide to release it. You've got one of the better demo pages for a lot of JavaScript plug-ins,

or any plug-ins for that matter. Do you have any sort of design background, or how did you create such sexy charts? Well, I was a senior designer once in my career, but I quit this job because I hate to be a designer. It's very unthankful because everybody has their opinion on everything, if it's about design. When it's about code, it's people less opinionated.

You could create perfect code. I mean, imagine you would like to create a function which adds to numbers. I'm pretty sure you could write a code which is perfect. When you need to draw a circle, and everybody thinks, oh, it's too big, it's too small. What color it should be? It should be black, it should be red. I like green, and it's such a nightmare, so I quit the design job.

Because I like to code as well, so I just start more coding less designing I obviously have lack of experience in design because of that but that's okay I have enough design you know knowledge to just roll up a site which looks not ugly and that's enough

so you were telling me earlier that the project, I guess, is a little over two years old now that the first release was on 8.08 of 8. When did the graphing component of G. Raphael begin? The graph I held began when I was doing some, well I was working for Atlassian and I was doing some charting solutions for I was about to do chatting plugins for a long time, and I did some preparation, and this kind of kicked off for me to actually do some real coding. So as a part of my work, I also was coding this chatting solution, and I released it. I think it didn't end up to be in Crucible at the end,

but now we have this chatting thing. I hope to come back to it and actually work on it, because I really like it, and I didn't have time to write a citation. I hope to the moment when this will be online, I will write something.

I try not to promise anything, because I'm just one guy with a family and a day job. This is all side things. We should mention that you're in Australia. So what's it like running an open source project from the other side of the globe and enlisting users via Twitter and social media?

Well, you know, it's like if you never experienced anything else, it's pretty much okay. So I wake up in the morning, I read the tweets, and then during the day nothing happening, I could just work. And then next day I have another tweet. So I can't reply to people straight away, but, you know, it's not that bad. Not much difference to being in Australia.

It's actually kind of annoying that you kind of have to be in Silicon Valley to do something. It's not much happening outside. And why not? It's just internet, right? Sure. So it should be, like like possible to do it anyway it's just for some reason everything's concentrated geographically in u.s and silicon valley in

particular absolutely you know uh it seems like there's been a pattern of uh really sharp rubius that i've met in uh in new South Wales even. And that's where you're located, right? Yeah, I know a couple of people from Ruby development and they're pretty smart and they're doing great things. And I don't know, it's like living in Australia is better than in the US. I'm pretty sure about that. Otherwise, I would move. But it's much better to live here.

I'm working currently for XTGS, and this is a company based in Silicon Valley, but I work remotely. It works pretty good so far. Is JavaScript your primary language, or are you in other server platforms?

No, JavaScript is my only language, which I name when people ask me about languages I know because, well I know a bit of PHP, a bit of Ruby, a bit of XSL, but obviously HTML, CSS, but I never mentioned that and just, yeah I know JavaScript, that's it. Because JavaScript I know, the rest I just have a quintessence of language. I'm not really happy to be a PHP developer, for example. What about Node.js? Have you played with that already? Well, yeah, I played a bit.

And I had a nice chat with Ryan on JSConf recently. It's a bit low level for me at the moment, not in terms of language, but in terms of what you can do, because I'm front-end with design exposure, not a front-end developer with back-end exposure as much. So Node.js for me is just like, it's great that I could write in a language I know, and that's pretty much it. Sure. I'm sorry.

Yeah, I'm pretty sure there will be lots of things emerging in the Node.js, like lots of frameworks on top of it, and later or soon I'm like holding my hand on the pulse and I'm pretty sure that I will, you know, encounter it again in my career anytime soon. I'm holding my hand on the pulse, and I'm pretty sure that I will encounter it again in my career anytime soon. Coming back to the client side for a moment, you're really pushing the envelope with both of these projects from an interactive standpoint of what traditionally is a Flash or even Java

space, right? But you're doing this in straight-up JavaScript and SVG. So what are the limits, as you see them, in doing this sort of thing in the browser? What sort of applications are still not quite available to the front-end JavaScript developer? Well, the limits are in the browser itself, so the performance is an issue. The SVG is not, I don't think there's a lot of work done by browser vendors on optimizing SVG at the moment.

So like making it render faster, do things faster, because it obviously lags when you put a lot of objects in SVG because the page, in general the page will run slowly if you put like 10,000 DOM elements on it and will try to animate them at once. But it's not something which happens when you're building the web pages, but in case of SVG, in case of graphics, there's something which could happen. You could animate a lot of objects at once, but there's not much optimization done on the browser side. I heard about IE9.

We're going to use some hardware acceleration for rendering. That would be awesome, but that's like a future. That's pretty much it. Apart from that, as soon as HTML5 became a reality with video tag, with audio tag, with SVG full support, and ability to embed video inside SVG, Opera does pretty good at this point in supporting the Edge standards. But again, if all this became reality,

if performance will have as a big hit as JavaScript performance, for example. Like recently, as you know, we have lots of big, fast JavaScript engines coming out. But that's not enough. JavaScript is fast, but DOM rendering is still quite slow. As soon as it will be faster, I don't know, there are like not much limits left. What's your favorite browser to work with from both a

development standpoint and from a performance standpoint? Well, I work with Safari. That's my default browser. But that's like unusual choice, I know. I'm developing in Firefox

most of the time because of Firebug, obviously. And basically I develop in Safari and Firefox because Firebug has issues and Web Inspector has issues, but fortunately they have usually different issues.

So you could kind of cover things with both. And, well, yeah, I'm testing other browsers. But I'm not really a fan of Chrome. I don't like it. Just personal. From a rendering aspect or from just a usability aspect? No, the rendering aspect is good. I just don't like UI of it, but, you know, it's just me.

I know everybody likes Chrome. Everybody I know likes Chrome, but me. I don't like Chrome. What level of debug support is available in both Firebug and the development inspector inside of the WebKit browsers for SVG? Well, the latest Firefox is pretty good. You could click on the circle to inspect element. It will give you

the circle thing. I think Firebug doesn't highlight it properly at the moment. While Safari highlights it, but it has bugs with figuring out where the bounding box of an element in case of SVG.

But in general, yeah, it works pretty well. I mean, it's just a DOM, so you could open it up, you could change its coordinates and stuff, just writing Firebug or Web Inspector.

Regarding generic JavaScript debugging, it's, well, it's well-known things. It's pretty much average everywhere at the moment. So, yeah. Do you have a favorite JavaScript framework? Raphael? Outside of the graphics area yeah well I use jQuery

if I need to do something quickly but well I'm not a big fan of jQuery because I think it has some issues somewhere well but I'm just a developer and I know that everything has issues. And Raphael has lots of issues.

I haven't seen perfect frameworks so far. So the thing about jQuery has a very nice API. If you use Raphael, you will notice I will just take this API and use it in Raphael, trying to make it as funky. In terms of Rafael, you will notice I will just take this API and use it in Rafael,

trying to make it as funky. In terms of possibilities if I need to develop a web app, well, of course, I like XTGS, but I'm a bit based. Yeah, that's pretty much it. I don't really look into other frameworks outside of it. You said you mentioned that this was created as a side project early on. Is it still just a side project, or you've got some items in production with this framework?

It's still a side project. It's still just me working on it. So as soon as it's just one developer, you can't call it a serious project. It's still a side thing. But, you know, it's like my hobby. I'm passionate about it. So, you know, when you're passionate about something,

it changes everything. It doesn't matter how many people are on it, if you like it. Closing in on a thousand watchers on GitHub, how has the community for Raphael grown since GitHub, since you moved your code over to GitHub?

Well, not much, I should say. Not as much as I expected. I know there are some people who like it. I know there are people who love it even. But I can't really see much contributions to the project. So I was hoping that, you know, I will release it on GitHub and people will say, like, hey, I found a bug and here's a patch for it.

And it will happen, like, each week at least once. I will lie if I will say nobody will ever submit me a useful patch, but if there was like five, it's a good number. I think it was less than that. So lots of patches coming which are totally useless, and I could see some people just submitting the patch for sake of submitting a patch. And, you know, like, oh, I submit the page to Raphael, yeah.

But most of the time I reject them because they're useless. And if I like them, usually I rewrite them, and not really a page, but actually just fixing the bugs my way because I'm quite picky about the code, especially in Raphael, because I want it to be perfect in my vision, because it's the only place where I can do that. Everywhere you work, you have work-related standards, and you should be able to write the code

so the other developers in the team will understand it. In the case of Raphael, I don't care much about understanding this by other developers as soon the team will understand it. In case of Raphael, I don't care much about understanding this by other developers as soon as I can understand it. So I'm pretty sure that in a year I could open it up and I could understand everything. So that's enough for me. Somebody else could not understand it,

but that's not my problem really. And it also serves like a saving from having even more stupid patches. I'm pretty sure a lot of people who just open code say, like, I don't even know how it works and close it up. And that's good. So they don't deserve to be listened. Sort of a benevolent dictator there for your own project.

That's a good thing. You should be a dictator otherwise your project will die in vain. I'm very, very strong on it and I have run into some conflicts with the guys who are telling me hey, it's open source

why can't I add this feature to it? And well, it's open source meaning you can read it and it doesn't mean you're able to write anything you wish because otherwise it would be a mess and chaos,

because everybody has their opinion. Raphael is an opinionated project, as well as Graphio. I receive people complaining that, when you're creating a pie chart, you can't put more than 10 segments on the pie. And I say yes, because I don't want you to create ugly charts with my library.

I love it. I love it. Can't create ugly charts with my graphing library. Nice. Because people will create ugly things with Raphael. I'm pretty sure about that. I saw a couple. You can't prevent this from happening,

but I can do as much as I can to prevent this from happening. Well, have you added that to your license that you can use this code as long as you don't create ugly pie charts? I should probably, yes. Well, I see about 10 plugins for Raphael. Do you have an official plugin API, or are these just extractions

that you built along the way? Well, there is a plugin API for Raphael, as well as jQuery has, so you could write rafael.fm.methodname and put the function or rafael.el.methodname put function on elements.

So it's all documented. It's all official. I have a plan to create a plugin page in rafaeljs.com, so people could search for plugins and submit some plugins to some centralized location. Just a question of time. I have this plan.

I know something which would be awesome to have. Just, you know, I have it on my to-do list, but not the next point. So I will do it eventually. I'm taking a peek inside of your test folder here to see if I could see a favorite testing framework, because testing JavaScript is always a challenge. Do you have one?

No. I don't look at test folder. I should delete it. It's legacy folder I created once, but it's really I'm not using. Well, the thing is about Raphael, I still can't find a good solution to test the framework because it's so visual. And if you create a circle, for example, and you ask Dom, is circle there? Dom will say yes. But is circle actually looking good is it actually visible

on the screen, is it actually Circle, is it anti-aliased is it like all these things you can't really ask God for this, you have to look at it you make an animation, is animation smooth is it really going the right path when you're doing the animation? Is it like there's so many things.

Basically, I use like the demos on the page is pretty much my test here. So I run the demos across all the browsers before each release, and they should work because they're kind of covering the whole aspects of Raphael because they were emerging as soon as I was adding new features. Look at the demos, you could see how they're coming up. So as soon as I add a new feature, I create a new demo and I put the demo on the page.

So each demo kind of tests for the new feature of the library. And running all the demos together will pretty much cover all the features the library has. What's the variance between each browser out there? I know that there's subtleties in even the way that each browser renders fonts and things, and as a designer, that bugs me to no end. What about for SVG?

Are there subtleties in a way a circle is drawn well if you talk about svg then svg supported browser does things pretty pretty good i can't really spot the difference much the vml has obviously its own way of drawing stuff and like the biggest thing if you will notice if you start using Raphael is if you draw a rectangle and stroke it with one pixel line, the line will be between two pixels. It wouldn't match the pixel grid in SVG because the middle of the line is laying between pixels.

And when you make one pixel width of the line, you're trying to kind of draw it between pixels so it actually looks like a two pixel line but grayed a bit because of anti-aliasing and the VML will try to match pixel grade to actually make it one pixel and this is a small inconsistency I don't really know how to fight.

I was trying to do it before, and I just rolled back my changes because it didn't work. People start complaining, hey, why all my drawings shifted half pixel? Because I'm trying to emulate VML, but it's not always worked as well, so it's much more complicated, and maybe I will find a solution one day.

But in case of VML, yeah, the rendering is quite different. The SVG-based browsers are pretty much rendering these things the same way. There are lots of inconsistencies in support of features of SVG, like filters, for example, are not really well supported at the moment like some other things but they generally if you draw a circle or square

you wouldn't spot the difference between Safari and Firefox for example Well to keep this episode commute friendly for those folks that are listening on the way to the office we'll need to wrap it up and we do that at the end of each episode

by asking our guests what's on their open source radar so are there any open source projects that have you excited that you really want to play with that you haven't yet all of them and especially the ones I didn't find yet do you play mostly with just JavaScript or well mostly with JavaScript yes

but I'm usually I like to pick up something open source and usually approach any open source project and then I dig into code and sometimes I'm like oh and then I sometimes say, oh, it's not actually as bad. What about templating? Something like Mustache.js

or any of those templating frameworks? I had a discussion just yesterday about templating. And basically, for three years, I worked as an XSLT developer, which is basically templating CHI. And I have my very strong opinion that templates shouldn't have logic inside.

And that's like, we could discuss another 30 minutes on that. But just to be sure, I'm pretty sure this is a disaster. It's like a hole which is going to be bigger and bigger and bigger. As soon as you have some logic, it's like bad. And I suggested recently the templating mechanism, which is a very small framework, about 100 lines of code, which just uses strings as templates, and all logics belong in JavaScript.

Which makes sense because logic should be written in the language which was designed to write logic. And you don't need to know yet another language to do this. And there are lots and lots of things. I know it's like, if I blog about it, I will have like 10,000 comments that I'm an idiot. But I don't care.

I know that I'm right because I was working with templates and I know that having logic is always a problem because people are trying to put there a lot of things, much more than templates should handle. And then you have to read it, you have to have double parsing in your head. So you have to parse template into whatever HTML it generates, for example. And then you actually need to parse HTML to understand what it does. And that's like double parsing is not really something humans are doing well.

So I am big, big, big on the point that templates shouldn't have logic inside. So should we look for a new tip-building framework from Dimitri soon that has no logic built in? I wouldn't release this framework if I didn't expect that people will hate me for that and it wouldn't be ever popular at all. So I probably wouldn't. I could release it.

It's already written. I don't know. Altogether, it's 200 lines of code, probably, with examples. But I don't think it's something which people will appreciate. Well, throw it out there, and then when people fork it, then you don't have to accept the patches, right? Yeah. We'll see.

It's not a project that you need to support then. I have problems with graphael i was trying to find a somebody who will you know support just you know hold the graphael i was twittering like hey who want to own graphael i gave it to you for free and nobody you know and people reply yeah i Okay, could you write documentation for it? And yeah, maybe next year. Yeah, so nobody did. So I, okay, I have to do things myself if I want to do this proper. So I will work on documentation.

Free framework to good home and documentation. Thanks for joining us, Dmitry. Thanks for taking time out of your lunch hour over there and sitting down with us. Thank you. Thank you for listening to this edition of The Change Log. Point your browser to tail.thechangelog.com to find out what's going on right now in open source. Also, be sure to head to github.com forward slash explore to catch up on trending and feature repos, as well as the latest episodes of The Changelog. As if no passion shown Was mine alone

I'm open I'm open All roads to drive Bring it back, bring it back to Open I'm open Bye.