Question

Note: I'm a backend (Java) developer by trade and work in Clojure in my spare time, so forgive me for my ignorance.

I'm trying to get my head around Clojurescript and how it could potentially fit in with projects I'm working on, or plan to work on in the future. As I've grown up with the "classic" web development mindset (e.g. Clojure running the backend, distributing data to the frontend via JSON to be processed in JS or returning a HTML page for the browser to render), I'm having trouble trying to understand how Clojurescript might make things better than this model.

Could anyone explain to me what the general approach to Clojurescript/Clojure development would be, seeing as the "Clojurescript One" project moniker signifies that application development will be unified under one language (as such)

  • What tasks would normally be done in the Clojurescript portion of the application?
  • What tasks would normally be done in the Clojure (e.g. backend) portion of the application?

Any help would be appreciated, or if anyone can point me towards some diagrams or explanations or anything - that would be great too!

Was it helpful?

Solution

I think Clojure/ClojureScript applications will be structured very similarly to X backend technology + JavaScript.

One big benefit with architecting applications with Clojure and ClojureScript - a richer data format than JSON (you can represent hash-maps and sets with arbitrary keys) without losing compactness.

JavaScript is a fine, fine language but ClojureScript offers quite a few benefits. It's semantically simpler (functional), ships with a rich standard library, a robust battle tested application library (Google Closure), and all the benefits you get from the tasteful application of syntactic abstraction via macros.

That said, it's still very much alpha software and the tooling still needs a lot of work.

OTHER TIPS

A bit of background about me, I have developed with Clojurescript, JQuery, Vaadin, Servlets, JSP, and many other web technologies.

1) Clojurescript is much harder to learn than any other web technology I have used as you need, Java, Clojure, Closure (with an s ;), Closure Lib, and Closurescript specific knowledge.

2) Clojurescript doesn't make sense for a small app. It only makes sense when you will have ALOT of client side processing

3) Clojurescript's only use as far as I see is as a better javascript (which is why it is better suited to larger apps) as the minifier part of Clojurescript is available for javascript too

4) Only the client end would be written in Javascript, the server would be in Clojure/Java servlets

Maybe Ganelon micro-framework (which incidentally I am author of) will suit your needs - the execution model is similiar to Vaadin's: server-side Clojure code pushes UI updates to the browser through AJAX/JavaScript, but we don't store application state in session by default.

The demo and docs are available at http://ganelon.tomeklipski.com/

For me, clojure and clojurescript offers cleaner code than mixed stack. There is only one language to think of and code is quite easy to read.

At the backend clojure does things that java usually would do. Input validation, saving to database and above all, implementing business logic. Our backend also validates incoming / outgoing data by types using prismatic schemas.

Frontend in short: We get pretty code using ClojureScript and it is fast to write. We are using ClojureScript version of material-ui when writing UI components. We have to write less code when compared to the JavaScript and I find our UI component code to be easier to read than JavaScript counterpart. One of the main reasons is shorter closing tags and less noise by coding language. Development with ClojureScript is quite fast.

Of course ClojureScript is used for simple imput validation like RegExp for phone numbers etc.

One of the disadvantages of clojure which you have probably noticed is long lines after giving proper names to the functions. I havent found silver bullet how to cope with that.

As dnolen said: ClojureScript is still developing. It is way better now than it was 6 months ago, so you'll have to keep checking its maturity now and then.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top