Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bringing functional to the frontend – Clojure and ClojureScript for the web

blog.getprismatic.com

Post reply on HN
Print view View original

11–20 of 64 posts

Re: Bringing functional to the frontend – Clojure and ClojureScript for the web

#11

Post by vemv »

willismichael wrote: post #5
aria wrote: post #2

Author here. Happy to answer any questions or comments.

I really want to like ClojureScript, particularly since the idea of using the same language all around the app appeals to me, but it's not quite the same language. Have you found this to be a pain in practice? I'm specifically wondering about require-macros and lack of support for ~ and ~@, although I'm also curious if you were bit by any of the other differences between Clojure and ClojureScript.

I'd say that not having "the whole language, all the time" is only (potentially) a pain regarding the development process/experience itself, not the quality of the resulting programs - which is what matters at the end.

Re: Bringing functional to the frontend – Clojure and ClojureScript for the web

#12

Post by weareconvo »

vemv wrote: post #11
willismichael wrote: post #5

Earlier quoted context omitted.

I really want to like ClojureScript, particularly since the idea of using the same language all around the app appeals to me, but it's not quite the same language. Have you found this to be a pain in practice? I'm specifically wondering about require-macros and lack of support for ~ and ~@, although I'm also curious if you were bit by any of the other differences between Clojure and ClojureScript.

I'd say that not having "the whole language, all the time" is only (potentially) a pain regarding the development process/experience itself, not the quality of the resulting programs - which is what matters at the end.

In general, I believe people underestimate the importance of development time, as well as ease of training/hiring new programmers - one language is nearly always better as far as both of these things are concerned (unless that language is something like Malbolge).

Re: Bringing functional to the frontend – Clojure and ClojureScript for the web

#13

Post by Rauchg »

"The above is valid Clojure code, not another language whose syntax you have to learn or separate compiler to use."

Even though this is a fair point, the comparison between the Jade solution and the Clojure one is invalid. Jade was conceived as a whitespace-significant language. Its biggest benefit over plain HTML (or HTML-based template engines like Moustache) is the usage of indentation to determine hierarchies.

The comparison would be more valid with something like http://domo-js.com, which is solving the exact same problem: using a single language (JS) for markup production – and even replacing CSS.

Re: Bringing functional to the frontend – Clojure and ClojureScript for the web

#14

Post by martinced »

weareconvo wrote: post #3

I really love Clojure, but it still feels a bit heavy-weight for anything but numerical computation. However, I'd ignore that if the performance gains were significant. What are the performance advantages of ClojureScript server-side templating compared to client-side Javascript templating? The vogue style these days seems to be a one-page app where the clicks take barely any time, because the jQuery/Zeppo/Underscore…

"I really love Clojure, but it still feels a bit heavy-weight for anything but numerical computation."

That is really weird. If there's one area where Clojure feels a bit strange to me it is numerical computation. I haven't fully looked into it yet but there's the whole underlying Java idiosynchrasies issue : for example where you need to wrap inside unchecked-int to dodge overflow issue or the fact that you need to be careful to be sure to fall back to primitives if you don't want to kill your perfs, etc.

In addition to that a lot of intensive computation do work really best when using mutable data structure. Which is sharp contrast with Clojure's main philosophy that favors avoiding mutability. Note that it cannot be done, it can, but it kinda feels "weird".

Then your question gets weirder: you ask about the advantages of ClojureScript server-side templating when the article specifically mentions using Clojure on the server and ClojureScript on the front-end (if I'm not mistaken).

Re: Bringing functional to the frontend – Clojure and ClojureScript for the web

#15

Post by martinced »

Semi-related question but...

One of the thing that I love when developing under Emacs is that I can get real-time validation of my XML (eg XHTML) based on, say Relax NG. This even works nicely with multiple-major-mode (eg I can get realtime validation of the XML part, yet see JavaScript as JavaScript inside the same source file).

Now my question: with all these templating libraries like Jade, aren't you losing feature like real-time validation?

And when such a templating library comes out, it means every editor out there as to be modified so that it supports it?

Or is there some kind of a schema that can be used to perform real-time validation + auto-completion?

My point is: I definitely see the point as replacing Jade by Clojure because you can then manipulate your templates as data, which is gorgeous. But I don't see the point of using Jade in the first place...

Re: Bringing functional to the frontend – Clojure and ClojureScript for the web

#16

Post by aria »

Rauchg wrote: post #13

"The above is valid Clojure code, not another language whose syntax you have to learn or separate compiler to use." Even though this is a fair point, the comparison between the Jade solution and the Clojure one is invalid. Jade was conceived as a whitespace-significant language. Its biggest benefit over plain HTML (or HTML-based template engines like Moustache) is the usage of indentation to determine hierarchies. Th…

That's a fair point. Really, I think we're making the argument that we prefer data approach to templates (i.e., language-native data structures (maps, arrays, strings)) represent html structure.

You can certainly take that approach in JS. domo-js isn't quite that, it would look more like:

["html" ["head" ["title" {class: "class1"} "Welcome to Domo"]]]

As we say in the post, you can totally pull all this off in JS, but I think if you're going to be manipulating nested data structures, it's better to have immutable data structures built in and the suite of functions that can manipulate them. Clojure makes building template structures really easy: persistent data structures, map/seq argument destructuring, keywords, sets, etc.

Re: Bringing functional to the frontend – Clojure and ClojureScript for the web

#17

Post by aria »

martinced wrote: post #15

Semi-related question but... One of the thing that I love when developing under Emacs is that I can get real-time validation of my XML (eg XHTML) based on, say Relax NG. This even works nicely with multiple-major-mode (eg I can get realtime validation of the XML part, yet see JavaScript as JavaScript inside the same source file). Now my question: with all these templating libraries like Jade, aren't you losing featur…

The nice thing about dommy (github.com/prismatic/dommy) is that emacs doesn't need to be changed at all to use it. It's just clojure and all the highlighting and the emacs major mode work.

Also out of the box, you get a repl to live test and evaluate template functions and data structure. It would only take a few lines of emacs lisp to take a string from the repl and pipe it through XHTML validation.

Re: Bringing functional to the frontend – Clojure and ClojureScript for the web

#18

Post by [deleted] »

martinced wrote: post #15

Semi-related question but... One of the thing that I love when developing under Emacs is that I can get real-time validation of my XML (eg XHTML) based on, say Relax NG. This even works nicely with multiple-major-mode (eg I can get realtime validation of the XML part, yet see JavaScript as JavaScript inside the same source file). Now my question: with all these templating libraries like Jade, aren't you losing featur…

[deleted]

Re: Bringing functional to the frontend – Clojure and ClojureScript for the web

#19

Post by pelle »

We use ClojureScript (and Clojure) at http://economi.co and I'm really enjoying it.

Maybe one of the most difficult things coming into it is trying to relate it to something like BackBone.

However generally speaking in Clojure the culture is more about libraries than frameworks.

C2 http://keminglabs.com/c2/ which on the outset looks just like a ClojureScript version of d3 is actually a great library to use instead of a traditional front end framework.

Check the example implementation of the class TodoMVC list here: https://github.com/lynaghk/todoFRP/tree/master/todo/c2

It's uses normal Clojure data structures within atoms as the data model (https://github.com/lynaghk/todoFRP/blob/master/todo/c2/src/c...) and uses C2 to automatically update the UI (https://github.com/lynaghk/todoFRP/blob/master/todo/c2/src/c...). Very elegant.

I'm just starting to explore this area myself, but have already found it useful for a few smaller parts of our site.

Re: Bringing functional to the frontend – Clojure and ClojureScript for the web

#20

Post by ibdknox »

aria wrote: post #17
martinced wrote: post #15

Semi-related question but... One of the thing that I love when developing under Emacs is that I can get real-time validation of my XML (eg XHTML) based on, say Relax NG. This even works nicely with multiple-major-mode (eg I can get realtime validation of the XML part, yet see JavaScript as JavaScript inside the same source file). Now my question: with all these templating libraries like Jade, aren't you losing featur…

The nice thing about dommy (github.com/prismatic/dommy) is that emacs doesn't need to be changed at all to use it. It's just clojure and all the highlighting and the emacs major mode work. Also out of the box, you get a repl to live test and evaluate template functions and data structure. It would only take a few lines of emacs lisp to take a string from the repl and pipe it through XHTML validation.

In terms of performance, wouldn't it be far faster to use strings and turn those into document fragments or setting innerHTML? I've been looking at ways to make crate much faster and it seems that would be the fastest solution by far.
Post reply on HN