4 ms·

I went into irc's #clojure to ask if I should use clojurescript for developing a html canvas based game. Most of the people in the chatroom dissuaded me. Thei

by tieTYT 13y ago

I went into irc's #clojure to ask if I should use clojurescript for developing a html canvas based game. Most of the people in the chatroom dissuaded me. Their main concerns were: 1) there's no source maps. IE: a browser stack trace does not map exactly to your clojurescript code so it can make things hard to debug. 2) finding and fixing performance issues in your clojurescript would be very challenging, especially if you're not an expert in javascript already (which I'm not) I took their advice but a personal issue I had along the way was, where the hell is the "hello world" getting started guide!? I was never able to find documentation that said, "write this simple file and type this simple command and now you've just built your first clojurescript example". Keep in mind I cut my research short, but I did put at least 2 hours into it. So I decided to use coffeescript instead. I think it's closer to the raw javascript but it's more concise. I haven't had any performance issues and even though coffeescript is supposed to have source maps, I haven't needed to use them yet. It's giving me confidence to try clojurescript for my next project. I think it'll be an even better experience than coffeescript. The ability to write your program in one language, front and backend, is really appealing.

swannodette 13y ago
We already had have rudimentary support for source maps - in fact it seems people have already used it to successfully debug their programs. It's not good enough yet for step-by-step debugging - we're getting there. This is a fantastic tutorial - http://github.com/magomimmo/modern-cljs http://github.com/magomimmo/modern-cljs RE: performance. I don't know who you talked to, but they are misinformed we spend a ridiculous amount of time on performance. It's certainly possible to do an HTML 5 canvas game in ClojureScript - http://swannodette.github.io/2013/06/10/porting-notchs-minecraft-demo-to-clojurescript/ http://swannodette.github.io/2013/06/10/porting-notchs-minec.... It is true that if you want to do a computationally intensive game you need to know something about JavaScript performance - but that's to be expected.
- tieTYT 13y ago
  That tutorial link alone was worth me making my comment :) Yeah I feel comfortable trying clojurescript next time. Thanks for the info.
adrianm 13y ago
I'm finding Three.js with an idiomatic Clojure veneer to be quite enjoyable. I find one of the biggest "wins" of any Lisp is how natural it is to build a DSL for whatever your problem domain happens to be. For example, right now I'm toying around with a declarative syntax for specifying arbitrarily complex mesh animations in terms of partial functions. To illustrate, instead of having a render loop where conceptually you are modifying something globally in a once per frame, iterative fashion, instead you would feed your rendering context a hash-map that both specifies animatables to be animated, and applies these partial functions onto the specified properties of the animatable object. Trivial example: {:animatable some-planet :animation {:rotation {:y (partial + rotation-speed) } } } Anyway, I suppose my advice is to not give up on using ClojureScript here because the potential for making the development of your game a thoroughly enjoyable experience is, for one, a huge win. Aren't we supposed to be enjoying this stuff at the end of the day? Take advantage of the language and be creative. I have never run into a situation where ClojureScript has somehow bottlenecked performance in any way, and I honestly can't really imagine that being a real concern. This is doubly true in a WebGL graphical context where most of the potentially awesome looking stuff (www.shadertoy.com) is being offloaded to the GPU and has absolutely nothing to do with Javascript or ClojureScript. My last piece of advice: figure out how often you want to deal with native javascript objects instead of Clojure data structures early on, and stick to it as a convention. The little differences in how the language treats the two (in a collection/sequence sense) will drive you (or me) crazy. I personally prefer to take any JS object I'm going to make considerable use of and turn it into a full fledged Clojure object until I'm finished with it. Obviously this advice doesn't apply to short lived objects, or simple method calls.

by tieTYT 13y ago

swannodette 13y ago

We already had have rudimentary support for source maps - in fact it seems people have already used it to successfully debug their programs. It's not good enough yet for step-by-step debugging - we're getting there. This is a fantastic tutorial - http://github.com/magomimmo/modern-cljs http://github.com/magomimmo/modern-cljs RE: performance. I don't know who you talked to, but they are misinformed we spend a ridiculous amount of time on performance. It's certainly possible to do an HTML 5 canvas game in ClojureScript - http://swannodette.github.io/2013/06/10/porting-notchs-minecraft-demo-to-clojurescript/ http://swannodette.github.io/2013/06/10/porting-notchs-minec.... It is true that if you want to do a computationally intensive game you need to know something about JavaScript performance - but that's to be expected.

tieTYT 13y ago
That tutorial link alone was worth me making my comment :) Yeah I feel comfortable trying clojurescript next time. Thanks for the info.

adrianm 13y ago

I'm finding Three.js with an idiomatic Clojure veneer to be quite enjoyable. I find one of the biggest "wins" of any Lisp is how natural it is to build a DSL for whatever your problem domain happens to be. For example, right now I'm toying around with a declarative syntax for specifying arbitrarily complex mesh animations in terms of partial functions. To illustrate, instead of having a render loop where conceptually you are modifying something globally in a once per frame, iterative fashion, instead you would feed your rendering context a hash-map that both specifies animatables to be animated, and applies these partial functions onto the specified properties of the animatable object. Trivial example: {:animatable some-planet :animation {:rotation {:y (partial + rotation-speed) } } } Anyway, I suppose my advice is to not give up on using ClojureScript here because the potential for making the development of your game a thoroughly enjoyable experience is, for one, a huge win. Aren't we supposed to be enjoying this stuff at the end of the day? Take advantage of the language and be creative. I have never run into a situation where ClojureScript has somehow bottlenecked performance in any way, and I honestly can't really imagine that being a real concern. This is doubly true in a WebGL graphical context where most of the potentially awesome looking stuff (www.shadertoy.com) is being offloaded to the GPU and has absolutely nothing to do with Javascript or ClojureScript. My last piece of advice: figure out how often you want to deal with native javascript objects instead of Clojure data structures early on, and stick to it as a convention. The little differences in how the language treats the two (in a collection/sequence sense) will drive you (or me) crazy. I personally prefer to take any JS object I'm going to make considerable use of and turn it into a full fledged Clojure object until I'm finished with it. Obviously this advice doesn't apply to short lived objects, or simple method calls.