Episode 149 of The SitePoint Podcast is now available! This week our regular interview host Louis Simoneau (@rssaddict) interviews Ross Boucher (@boucher), one of the co-creators of the Cappuccino Framework; to talk about his current work on a payment processing service called Stripe, as well as the current state of JavaScript web application development.
Download this Episode
You can download this episode as a standalone MP3 file. Here’s the link:
SitePoint Podcast #149: Drinking Cappuccino with Ross Boucher(MP3, 31:12, 28.6MB)
Episode Summary
Louis and Ross cover how the Cappuccino framework came about, what the Stripe team faced as challenges, how they got through those challenges and how javascript debugging in browsers has and continues to move forward.
Browse the full list of links referenced in the show at http://delicious.com/sitepointpodcast/149.
Interview Transcript
Louis: Hello and welcome to another episode of the SitePoint Podcast, my guest on the show today is Ross Boucher; hi, Ross.
Ross: Hey.
Louis: Ross is a web developer; the co-creator of the popular Cappuccino Framework for creating browser based web applications, and is currently working at Stripe. So, do you want to talk a bit about what you’re currently working on, Ross?
Ross: Sure. So I’m working at a company called Stripe, stripe.com, and we are payment processors, so we try to make it easy, as easy as possible to come and signup on our site and be able to start processing credit cards on your own site right away. And at the end of the day like this is kind of similar to what a lot of other people are doing, obviously you can do this with PayPal or a number of other companies, but we think that our software is both better, it’s easier to use than a lot of these other companies, and also we place a lot of importance on eliminating the amount of sort of manual effort involved, making integration as quick and painless as possible, and, as I mentioned, making signup really easy; you can come to our site and fill out the online form in probably just about two minutes and start charging real credit cards right away.
Louis: Right. Having recently spent, well, I didn’t personally, but another developer on our team has spent I think more or less the last month trying to get recurring payments working with PayPal; I can say that a one day or even a few hour turnaround sounds very impressive.
Ross: Yeah, we’ve heard a lot of similar stories, and a lot of people here come from backgrounds were they were doing other startups or working at other companies and experienced the same problems themselves, so I think a lot of the motivation for Stripe is born out of our own internal frustration.
Louis: Right. It’s always interesting to me; I talked with one of the guys from Shopify on the podcast last year. For those of us who develop web applications where we might sell products or just provide an online application for people, it does seem like stepping it up to another level when you’re dealing with credit cards because you have a lot of concerns that maybe other app developers don’t have to worry about so much.
Ross: Yeah, I think that’s definitely true. Stripe is even a bit different in that because we are essentially offering a piece of infrastructure for other companies, you know our primary product is our API; we’ve got an even different set of problems to worry about. I think API driven products tend to just have different problems, and, for example, reliability is paramount to us; we don’t want other people to ever have to worry about not being able to accept payments because our servers are down.
Louis: Yeah, absolutely. How long has Stripe been in operation?
Ross: Stripe has been processing payments for just about two years now, in fact, I was the first user of Stripe at my last company, but it’s only been public for about four months now, five months, September of last year.
Louis: Okay, so it’s fairly new on the market if anyone was looking for a payment gateway.
Ross: Yeah, it’s fairly new. And we also, I guess I didn’t mention this before, but Stripe integrates both the traditional payment gateway and merchant account features into one, so when you come to Stripe you don’t need to bring with you a separate gateway or merchant account, we just package that all into one simple product.
Louis: Right, so the payment that you receive, for example, go into a Stripe account?
Ross: When you get paid with us we hold your funds, actually our partner Wells Fargo holds the funds in your name, we’re never actually in control of them.
Louis: Right.
Ross: And then we transfer those funds to you to any bank account after seven days, seven days after each payment is made.
Louis: Alright. Yeah, I mean it’s really interesting, especially in a market where I think a lot of people tend to think a big player like PayPal is sort of the only option out there, and given the experience that most people have had dealing with PayPal’s support and API, I think it’s definitely a good space to have a bit more competition in.
Ross: Yeah, we’re excited about growing and about the challenges ahead.
Louis: I’m really looking forward t seeing it grow. I guess the thing you’re probably better known for is as co-creator of Cappuccino. Now, I think Cappuccino when it was first released was probably discussed on the SitePoint Podcast, though I was not doing the show at that time, but for anyone who’s unfamiliar with Cappuccino do you want to talk about what it is and how it came about?
Ross: Sure. So, to start out with a quick overview, Cappuccino is, as you said at the intro, a framework for building browser based apps, and what we mean by that is what’s I think come to be now known as like single page apps, or some people call them like fat client web apps, things like that. And the idea is an application like Google Docs or our own 280 Slides, or even to some extent Google Maps, is really something that you load once and most of the logic of running the app is happening in the client and it goes to the server just to fetch new data to act on that data. So that whole model of apps which I think we’ve seen become really popular over the last two years or so is what Cappuccino is really designed to build. And Cappuccino itself was started, well, it started in our college dorm room about 2005, but that was just really a hobby for a while, and then in 2008 we started working on it full time and started a company called 280 North to do that, and then we released it to the public I believe in August of 2008. So it’s been out for just a little over three years now.
Louis: Right. And it’s worth mentioning Cappuccino is open sourced software.
Ross: Yes, it’s open source, it’s on GitHub, it’s currently on version 0.9.5 I believe, and it’s licensed under the LGPL.
Louis: Right. So the idea behind Cappuccino was sort of from what I understand to somewhat recreate the experience of developing native apps in Cocoa and Objective-C for the desktop Mac environment —
Ross: Yes.
Louis: — inside the browser.
Ross: Right. I guess I should have mentioned that. When we were thinking about writing Cappuccino we were actually — the problem we wanted to solve was to build an app in the web browser, and we’d been working on that for a while, and as we got further along on each project we would hit these roadblocks and realize this is actually really hard, it’s really hard to build this kind of app in the browser. But the three of us that were working on it at the time also had experience writing Mac apps, and so we thought to ourselves why don’t we try to work on a framework that looks similar to Cocoa; Cocoa seems to work well in building these kinds of complex apps. So we started playing around with ideas that were modeled after Cocoa, and then eventually Francisco, one of my co-founders, had the idea that why don’t we just try to actually write Cocoa. And so he for fun wrote Objective-J, which is the language Cappuccino is written in, it’s a set of extensions to JavaScript that are compiled on the fly in your browser, so we added this set of language extensions to add certain features like code importing and classical inheritance and dynamic dispatch.
Louis: Right.
Ross: The same set of features that Objective-C added to C. And so after he’d done that we set to work on porting a lot of the actual Cocoa framework, and so that’s where Cappuccino is today.
Louis: Right. And you said that the compiling happens in the browser, happens on the fly, something like CoffeeScript where you put it through a pre-processor.
Ross: It’s actually extremely similar to CoffeeScript. We have the capability to do it both in the browser or ahead of time on the command line, which is something CoffeeScript has as well, I believe. And so typically the development cycle for a Cappuccino app will be to make changes to your .j files and refresh your browser just like you would normally and those changes will be compiled on the fly in your browser. But then when you deploy we recommend compiling ahead of time and running all of our various optimization scripts to get stuff as tight and fast as possible so that you’re not doing repetitive work every time one of your users loads your app.
Louis: Right. And this is — because it’s running in JavaScript and it’s compiling down to more or less straight up JavaScript, what’s the level of browser support that you get out of that?
Ross: So, officially I believe we’re supporting pretty much any browser, IE7 or newer. I think Cappuccino works in IE6 as well, but we don’t really support it because we used a lot of transparent PNG’s and not really interested in that problem.
Louis: It’s weird; it’s been long enough that until you brought that up right now I had forgotten that IE6 didn’t do transparencies.
Ross: Yeah.
Louis: And it was just like oh, wow, that thing was really archaic.
Ross: Yeah. Yeah, when we actually released, or when we wrote our first Objective-J, IE6 was the newest Internet Explorer, so we spent a lot of time figuring out how to make compiling this language in IE6 fast enough to be realistic.
Louis: Right. I mean that sounds — so, to me telling the story of how you came up with the idea on how you started working on it, it sounds totally like one of those things where oh, wow, it’s hard to write complex applications in JavaScript, it’s really easy to write complex applications in Cocoa, we should just rewrite all of Cocoa in JavaScript, and then you’d spend like a day trying to do that and then realize that that was really hard and stop
Ross: (Laughs)
Louis: So big props to you guys for not doing what I think I would’ve done in your shoes.
Ross: Yeah. It was definitely fun and interesting and challenging and probably harder than any of us thought, but it was also a really good learning experience, I know a lot more about how JavaScript works and about how Cocoa works as a result, and I definitely enjoyed that aspect of it.
Louis: Are you still working with Cappuccino in your day-to-day work or on any of your projects you’re working on at the moment?
Ross: I keep active on the Cappuccino mailing list and with some of our bug and pool requests, but I haven’t really had a lot of time in the last year or so to do Cappuccino development myself. At Stripe I’ve been working on a lot of different things, including a lot of backend code, but we also re-wrote our front-end recently, and we chose to go with CoffeeScript and Backbone, and then a custom framework that we built on top of that.
Louis: Right.
Ross: So, I’m not actually developing Cappuccino stuff at Stripe.
Louis: Right. I was actually going to ask you how you felt that Cappuccino played against or sat in relation to something like Backbone, because it seems like they’re both sort of in a way trying to solve a similar problem, although I guess Cappuccino has a lot of UI components that Backbone doesn’t really concern itself with.
Ross: Right.
Louis: But the idea of dealing with sort of more complex apps that run in the browser.
Ross: In some ways they’re trying to tackle a similar goal, in some ways they’re actually kind of complimentary. Backbone doesn’t really make any attempt to do anything on when it comes to the view layer, there’s, you know, a few handy little functions in there to help define events, but there’s not really a whole lot going on there. And the real strength of Backbone, I guess, is just making it easy to tie models and collections together with like a restful backend, and with as little code as possible; I see that as probably Backbone’s strongest point. And Cappuccino actually as it stands now doesn’t really try to do much about that, it tries to be pretty backend agnostic, our goal was really, you know, we want to write this front-end, front-end focused thing, and then however you want to get data back and forth will be up to you. On the other side of the spectrum, Backbone is a really tiny — I think it’s 10k of JavaScript, or something, framework, and Cappuccino without images I think approaches some 300k or possibly more. So there’s definitely a size difference there, Cappuccino has a lot of functionality built into it, a lot of different view components, a lot of image resources, because as you said, you know, we have sort of our own full style that you can use.
Louis: Right. And does Cappuccino work in a way that’s similar to say jQuery UI where you’ve got this set of interface components but they can be switched out with whatever other custom set you might come up with?
Ross: In some ways it does, yes, so, but in other ways it’s actually pretty different. So, one of the things that jQuery UI is focused on, and Backbone and really all the other frameworks are doing that kind of thing, is that they still want to be using HTML and CSS to define sort of the individual style of things and the organization of their elements. Cappuccino takes I guess some might call it a radical approach of not using CSS or HTML at all, so you’re never writing CSS or HTML code when you interact with Cappuccino, everything’s a JavaScript object; in Cappuccino it’s called a CP View, which obviously sort of maps to the NS View hierarchy. And so, you know, in some ways I actually think Cappuccino makes it much easier to share components with other people, because one of the problems with traditional web apps and with sharing your view components is that everything in CSS and HTML is really tied together, the structure of your CSS can be broken really easily if you change the layout of your HTML; you have to have a lot of knowledge about how the HTML is ordered and nested and how the CSS applies to that, and you have to carry a lot of these sort of dependencies across with you, across different places. And Cappuccino doesn’t really have that problem because everything is written in code.
Louis: Right.
Ross: And Cappuccino does lose some flexibility there because you lose the expressiveness of CSS to declare like static visual style, which can be nice, but Cappuccino does have a theme system that we added that lets you do — that adds some of those features back in so you can use standard view components but modify the way they look with our theme system.
Louis: Right, yeah. You mentioned that in your work at Stripe you’ve also been doing some backend stuff, what sort of server side code are you working with at Stripe?
Ross: Most of code is written in Ruby, usually on top of Sinatra, though not always. And I’ve been doing a lot of work on our API and designing sort of the structure of the API and the actually interface that we expose to the users, not so much the implementation of specific functionality, I’ve done some of that, but a lot more of that was there before I started.
Louis: Right.
Ross: The most recent thing that I’ve been working on is we just released this week a new Webhook feature which works pretty similarly to GitHub’s post-receive hooks, if you’re familiar with that. So you can just signup and arbitrary number of URLs in your Stripe account, and we’ll send events to those URLs anytime something interesting happens, so you can, without having to pull us, track the history of changes across all your Stripe objects.
Louis: Can you give an example of what kind of thing that would be used for or how that plays into a regular use case?
Ross: Sure, so one of the things that people use it for most commonly is we have a recurring billing system, and a lot of people will want to add usage charges at the end of the month, so you charge your user for some month, let’s say you’re charging cell phone minutes, and then they use all of their cell phone minutes plus another 60 minutes, so you want to add an additional charge based on that extra 60 minutes, so we will send you a web hook telling you that their billing period is over, we’ve created an invoice for them, and all the details about that invoice and sort of the dates that it’s affected for, and we give you an opportunity to send a message back to us saying, okay great, add this amount of money to the invoice before you try and pay it.
Louis: Right. Yeah, that sounds really good. And so in your work with Ruby you said you’re working a lot with Sinatra, and I guess because you don’t have to deal with as much of a full ViewStack as a traditional web app because you’re working more with an API, or since your main product is an API, as you were saying earlier, it made sense to go with something light like Sinatra instead of a fuller framework like Rails?
Ross: Yeah, I mean I think that’s an accurate description. Rails definitely has some nice features I think even if you’re writing an API, but for us, both in terms of what we’re working on and our own needs, it just wasn’t the direction we wanted to head in. So we used Sinatra for our API, and we also use it for our website, our management website, and we actually use our API for that management website, so, as I said, it was written in Backbone, Backbone is actually just calling out to our regular API, the same API that our customers use. So, most of the features that we expose on the website we expose in a way that would let users build their own competing dashboards if they wanted to, and that’s actually been really helpful for us in understanding the right features to build in the API, and also where the biggest performance problems are.
Louis: Right. I actually thinks that’s a really interesting approach, and it’s something that I haven’t heard of anyone doing before. I guess most people’s approach to building a Web app that includes an API is to build the app with some views and then do the API that renders out XML or JSON, or what have you, but I guess if you’re building an app or a dashboard that is entirely sort of like one of these one page JavaScript apps, then simply consuming your own API is first of all a great way of ensuring that the design or your API is sensible and that’s it’s easy for other developers to use, and as you said, to pinpoint any problems that might exist in it.
Ross: Yeah, that was our goal, the first verson of the site was not written that way, it was a much more traditional website, and when we did this rewrite as a single page app one of the things we thought we could really win out of doing that, on top of just sort of the standard, you know, make it more responsive, make it faster loading, etcetera, was this ability to communicate directly with the API and use the same JSON data exchange to really make sure that our users would have a good experience using the API.
Louis: Yeah, that’s really good, I’ll definitely keep that in mind the next time I’m working on something like this. So, in the kind of situation where you’ve got your entire front-end is built on Backbone and you’re consuming an API, does that mean you’ve sort of abandoned the non-JavaScript support for your dashboard?
Ross: We have, yeah. I think you could build the site in such a way without changing much from what we have now that it would work without JavaScript. All of our stuff is written in the front-end with Eco, which is the CoffeeScript templating language, and we could run that in Node on the backend and generate first page and send you that HTML if we wanted to. We decided that based on our users, based on the functionality we wanted to offer it really wasn’t going to be that big of a deal to require JavaScript, in terms of SEO it’s not a problem because the site is behind a login wall, so for us we decided it wasn’t really worth the development time, but I think you could build a similar system and have it still render if JavaScript is disabled.
Louis: Right. So how do you feel about that in the broader Web, I know you were mentioning specifically relating to your users and the type of service you’re creating, but do you feel the trend is moving towards whereas a few years ago most people who were web developers who were blogging about this would’ve said you have to make a site that works with JavaScript disabled, it’s an accessibility concern, it’s all these things; do you think that that has changed significantly or is changing? Do you think that there will be a time when every website will assume JavaScript all the time?
Ross: Uh, that’s a good question. Right now I would say it’s definitely not — the thing is it depends a lot on what you’re building, if your site is primarily content and it’s primarily about getting people to link to you and have Google pick up your content, you know you really do need to run without JavaScript. To some extent the browser, the search engine’s going to get better at that, right, and so if Google was able to really accurately pull pages that had JavaScript required apart and get the right content, maybe that’ll even become a non-issue; I’m not really sure if that’s a problem they’re working on. But, in terms of other concerns like accessibility, you know the screen reader software and really all the browsers have gotten so much better at that kind of problem, all the mobile browsers that are coming out these days support JavaScript really well, so I think it’s less of a technical concern, it’s less of a concern from a usability standpoint. Some people may choose to run with JavaScript disabled, and for some, for a lot of websites it probably still makes sense to offer them some experience, but I do think right now the real motivator between working without JavaScript is search engines and sort of the ability to index content.
Louis: Right. It’s probably also fair to say that you’re reaching a point when if you had JavaScript disabled on your browser a lot of the Internet would be frustrating to you.
Ross: Oh, yeah. I’m pretty sure Facebook doesn’t really work that well without JavaScript, I’m not sure how well new Twitter fares. But, yeah, I mean it’s definitely the case that a lot of major sites would not work very well without JavaScript.
Louis: And so you mentioned in there accessibility and screen reader software getting better, is that something you guys have played around with and tested a bit?
Ross: It’s not really something we’ve played around with at Stripe, though it was something I paid attention to when I was working full time at Cappuccino; as you can imagine because Cappuccino is not even using HTML, it’s doing everything in JavaScript, it gets particularly difficult to interact with screen readers, they have a pretty difficult time because of some of the tricks that we’re doing. And one of our goals was to make that as good as possible, unfortunately back then when I was working on this about two years ago, the accessibility spec ARIA was just sort of getting started to be implemented in browsers, and so it wasn’t a ton that we were able to make happen. But I’ve talked to some people recently, and my understanding is that they’re working on some newer features in ARIA, or in the next version of an accessibility spec that could be really interesting for frameworks likes Cappuccino that want a lot of control.
Louis: Right. Yeah, I did have a look at ARIA when I was working with SitePoint on the HTML5 and CSS3 book, and it seemed like it was definitely a really good step in that direction, of course it remains to be seen how quickly browsers and screen readers are able to adopt that.
Ross: Yeah, I’m not sure what the state of adoption is, but I definitely know that it’s getting better than it was two years ago.
Louis: Yeah, and I think with all of the browsers moving as quickly as they are now it’s something that’ll really be moving along a lot faster than those of us who’ve been working in the Web for any length of time are accustomed to.
Ross: Yeah, actually I’m really excited about the pace that things are moving in the Web, you know IE6 is pretty much a non-factor for most people these days, even IE7 seems to be pretty low traffic on most sites, probably unless you’re doing something like explicitly corporate Internet or targeting specific countries it won’t be very long before IE7 isn’t a major concern for most people. And you know IE10 I think is the next one coming out, and it’s supposed to have really good JavaScript performance, and they’ve got Canvass support now, and so I think we’re moving a lot faster in the Web world than we had been for a really long time.
Louis: Yeah, finally. Yeah, I mean that’s been sort of the opinion of everyone I’ve spoken to on the podcast over the past year is just that level of excitement about not only the movement in the browser space, but also in the specifications and in the kind of playfulness in general experimentation that’s going on in the Web.
Ross: Yeah, and at the same time I think we may be headed for some rocky times ahead because there’s a lot of fragmentation I think going on, not necessarily in a bad way, but like you said, playfulness, there’s a lot of experimentation with things that Google’s putting into Chrome and stuff that Firefox is putting into Mozilla, and those don’t always match up. And I think that there’s been more sort of negative opinion of standards bodies, which I can’t really blame people for because they are part of the reason why things move so slowly, though I guess there’s pretty good reasons for why they move so slowly. But, yeah, I don’t want to — I worry a little bit that we’ll end up in a world where the Web will go back to a sort of ‘works best in this browser’ mode, and I definitely don’t want to see that happen.
Louis: Yeah.
Ross: But there’s a lot of pressure obviously from native apps on mobile platforms like iPhone and Android, so, it’ll be an interesting next few years.
Louis: Yeah, definitely. Although it feels to me like there’s some movement towards that kind of thing on the more experimental edge, you know people will make a demo of something that only works in Firefox, only works in WebKit, because they’re using some new feature that’s just been added. But it doesn’t seem like it has the potential to spread out into the broader Web in the same way you saw those kinds of built for Netscape Navigator 4 banners on actual clients’ sites, right?
Ross: Yeah. Yeah, hopefully not. You know the biggest potential things I worry about are sort of the future of JavaScript, you know Google’s working on their Dart effort, the next version of ECMA is sort of making its way through committee and there’s still a fair amount of disagreement about what features to put in, yeah, (laughter). But, you know, yeah, I’m pretty optimistic, it seems like — I’m sure everyone remembers the past, it wasn’t really all that long ago, so I don’t think people will be rushing into the same mistakes.
Louis: Yeah, definitely. Speaking of the speed of browser releases, as we record this the latest release of Firefox came out yesterday; have you had a chance to look at the new developer features in it?
Ross: I actually have not looked at it at all.
Louis: Alright.
Ross: Truthfully I haven’t.
Louis: I only ask because it happened to come out yesterday and I happened to have you on the line, and it’s a big leap because previously there were no built-in, or very few built-in developer tools, and it was sort of relying on Firebug to provide that.
Ross: Yeah, I know they’ve been away from the Firebug model I think for a lot of reasons, one is that all these other — or a lot of other browsers are coming with built-in tools that are really good, and I think Firebug was also having trouble sort of getting resources to keep working on it.
Louis: Yeah, and keeping up with the faster release schedule.
Ross: Right. Truthfully, though, I haven’t been a big Firebug user since Chrome came out, and in particular I think the developer tools in Chrome are really great, I’m really impressed with how far they’ve come in the last few years. I can remember a time when there was no other option but alert to bugging, and now I think Chrome is really a better debugging experience than Ruby, and then really most of the things I’m doing on the server side.
Louis: Hmm, yeah, that’s a valid point, working on the server side you often wind up with almost the equivalent of alert debugging in the sense of just dumping something out and refreshing a page. Whereas working in JavaScript you really do have the power of the console, and that’s one of the things I find interesting about the new Firefox tools is with the addition of syntax highlighting and coding in the new scratchpad thing, it looks like it really has the potential, and they’re taking it in a different direction, not really just copying Firebug or copying the Web Inspector. Obviously it’s only been out 12 hours, and I was sleeping for most of those, so I haven’t actually played with it very much, but it does look promising, so.
Ross: Yeah, I’m actually definitely interested in looking at it because definitely more competition in the tool space is what’s helped us to get as far as we’ve come now, so it definitely will be exciting to see that pick up.
Louis: Yeah, absolutely.
Ross: I’ve always actually been really surprised by how little people know about the tools that are available in the Chrome debugger and the general Web Inspector; people have been using Firebug for so long I think they may not have been looking at how much stuff has happened in Chrome and Safari, and they’ve got a keep analyzer, they’ve got all kinds of tools to tell you about memory problems that you’re having, to tell you about performance problems, it’s sort of like a YSlow equivalent that’s sort of built-in, and you know you’ve got the CPU profiler, there’s really just actually a lot of great stuff in there.
Louis: Yeah, I remember again back working on the HTML5 book for SitePoint that I was using Chrome a lot because at that point Firebug didn’t have any way of looking at local storage, or is it the — does it have Web DB access in the Web Inspector, I think it does.
Ross: I think they do, yeah, and you can inspect definitely all of local storage and session storage if that’s still in there, and cookies; you can also set like breakpoints on events now, like on DOM events, so you can say like break on events of this type, or break on like HXR’s to this URL, it’s really flexible.
Louis: Hmm, yeah, it’s fantastic. And although I haven’t been working — I’ve been working exclusively on the server side for some time, I’ve been sort of looking enviously over into the JavaScript camp watching things like Backbone come onto the scene, and as the debugging tools become so much better, and then sort of getting a little bit itchy to maybe get back on the front-end at some point.
Ross: Yeah, you should.
Louis: Well, it’s been a pleasure having you on the show, Ross.
Ross: Yeah, it’s definitely been great to talk to you.
Louis: And so if listeners want to find you online what are the main points of contact?
Ross: You can find me on Twitter at my last name, so that’s @boucher, if you can’t spell it it’s b-o-u-c-h-e-r.
Louis: (Laughs)
Ross: I don’t know if you want to put that in at all. I have a website, rossboucher.com, I don’t really put very much up there but I’m working on rebuilding that, so hopefully some day I’ll do that. So, yeah, I guess Twitter is the main way, my email address, and any multiple ways of getting in touch with me are on my website.
Louis: Alright, well, thanks very much, again, we look forward to seeing what comes out of Stripe, and I’m very excited about having other alternatives for payment online because it’s as I mentioned something that we’ve definitely struggled with, so yeah, best of luck going forward with that, and I look forward to seeing what comes out of it.
Ross: Thanks.
Louis: Cheers.
Ross: Cheers.
Louis: And thanks for listening to this week’s episode of the SitePoint Podcast. I’d love to hear what you thought about today’s show, so if you have any thoughts or suggestions just go to Sitepoint.com/podcast and you can leave a comment on today’s episode, you can also get any of our previous episodes to download or subscribe to get the show automatically. You can follow SitePoint on Twitter @sitepointdotcom, that’s sitepoint d-o-t-c-o-m, and you can follow me on Twitter @rssaddict. The show this week was produced by Karn Broad and I’m Louis Simoneau, thanks for listening and bye for now.
Theme music by Mike Mella.
Thanks for listening! Feel free to let us know how we’re doing, or to continue the discussion, using the comments field below.
Louis SimoneauLouis joined SitePoint in 2009 as a technical editor, and has since moved over into a web developer role at Flippa. He enjoys hip-hop, spicy food, and all things geeky.
