11–20 of 51 posts
Author here. Happy to answer any questions/concerns.
ClojureScript is so different from JavaScript that it makes sense write a more native DOM library for it. As someone with a lisp background, it's very cool to see a high-profile company like Prismatic using it. However, macros for javascript are being worked on. sweet.js is coming along really well, and just needs to continue ironing out bugs and maturing. http://sweetjs.org/ I believe that it could have a profound e…
Other languages can totally have macros, but unless you have homoiconicity, which lisp languages do, macros aren't easy to use or support. In ClojureScript, macros are built into the language.
sweet.js figured out how to do that in javascript, so we have full syntax-case macros just as easily.
Whilst I'm sure this is clever - I guess I'll never understand the obsession with micro DOM optimisations. When, ever, are we severely held back by the 'speed' of our selectors? It just doesn't happen!
I'm not saying that all sluggish performance in web apps is caused by inefficient DOM manipulations, but having a DRY and efficient way to express DOM manipulations could help a lot in that regard =D
Author here. Happy to answer any questions/concerns.
How mature is ClojureScript these days? I remember people saying it and Clojure on Android was rough when I was exploring Clojure a while back. Does the compiler eliminate unused code from the final output?
Seems to be pretty mature, there are apps in App Store written in it, and there are companies, using it for their front-end (i.e. Prismatic :)).
> Does the compiler eliminate unused code from the final output?
That's done by Google Closure Compiler in advanced mode.
Earlier quoted context omitted.
Other languages can totally have macros, but unless you have homoiconicity, which lisp languages do, macros aren't easy to use or support. In ClojureScript, macros are built into the language.
That really only applies to `define-macro` style macros. You can have syntax-case style macros if the language can disambiguate reading and parsing, which a lot of them have trouble with, and why they don't support them. sweet.js figured out how to do that in javascript, so we have full syntax-case macros just as easily.
Earlier quoted context omitted.
That really only applies to `define-macro` style macros. You can have syntax-case style macros if the language can disambiguate reading and parsing, which a lot of them have trouble with, and why they don't support them. sweet.js figured out how to do that in javascript, so we have full syntax-case macros just as easily.
Wait so does sweet.js support arbitrary JS execution in macros now?
So I should have said syntax-rules (for now). My bad!
ClojureScript is so different from JavaScript that it makes sense write a more native DOM library for it. As someone with a lisp background, it's very cool to see a high-profile company like Prismatic using it. However, macros for javascript are being worked on. sweet.js is coming along really well, and just needs to continue ironing out bugs and maturing. http://sweetjs.org/ I believe that it could have a profound e…
Other languages can totally have macros, but unless you have homoiconicity, which lisp languages do, macros aren't easy to use or support. In ClojureScript, macros are built into the language.
In Groovy, for example, you have the equivalent of macros in the form of AST Transformations †, that look just like Java annotations, but can actually convert the code their are applied to (or, more specifically, the AST node) and transform it into something else at compile time. Writing AST Transformations in Groovy is not as smooth as writing macros in Lisp, as you have to deal with the AST nodes as objects (there are DSLs for this fortunately), instead of using the same language syntax directly, but they provide awesome metaprogramming capabilities as well. The Groovy standard library includes some very useful AST Transformations and frameworks like Grails use them to a great extent too.
So, i think that, even though macros (or equivalent code transformations) are not very accessible to the average programmer if the language does not have homoiconicity, they can be of great value for library writers. As the linked article shows, they could be used to make something that looks like jQuery but generates much more efficient code :D
† http://groovy.codehaus.org/Compile-time+Metaprogramming+-+AS...
Whilst I'm sure this is clever - I guess I'll never understand the obsession with micro DOM optimisations. When, ever, are we severely held back by the 'speed' of our selectors? It just doesn't happen!
This is super impressive. I'm going to use this for my frontend work now. On a side note, what's the idiomatic structure, or "design pattern" for cljs front end code? I would assume something based on MVC, with models comprising of atoms with watches, Views consisting of hiccup templates and controllers gluing dom events to models and views. Am I close?
This is super impressive. I'm going to use this for my frontend work now. On a side note, what's the idiomatic structure, or "design pattern" for cljs front end code? I would assume something based on MVC, with models comprising of atoms with watches, Views consisting of hiccup templates and controllers gluing dom events to models and views. Am I close?