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

Why ClojureScript Matters

blog.juxt.pro

Post reply on HN
Print view View original

51–60 of 121 posts

Re: Why ClojureScript Matters

#51

Post by jeremiep »

Frozenlock wrote: post #27
jeremiep wrote: post #24

Earlier quoted context omitted.

reify is usually a low-level construct in Clojure. A lot of libraries use it under the hood, I wouldn't be surprised if you use a few of them :)

Probably, but it still left me feeling a little alienated. Not to take anything from Om tho, people using it seem to enjoy it a lot! I guess I'm just less smart ;-)

I wouldn't say less smart, it took me some time to get used to reify before feeling comfortable using it too. Think anonymous classes in Java for example, its almost the same thing.

Re: Why ClojureScript Matters

#52

Post by straws »

Frozenlock wrote: post #6

If Om hurts your brain, I can't recommend Reagent enough: http://reagent-project.github.io/

Reagent presents a very simple api at the expense of a lot of complex/magical bookkeeping to link components and their update cycles to a framework-specific application atom. If you're really looking to demystify how clojurescript can wrap React, I can't recommend reading through the source code of Quiescent enough:

https://github.com/levand/quiescent/blob/release/src/quiesce...

That said, I've really enjoyed Reagent for prototyping, and the magic is the good kind of magic. It's just that Quiescent feels so much like a clojure library, trading ease for simplicity — and is often a better brick to build your own abstractions on top of.

Re: Why ClojureScript Matters

#53

Post by jwr »

sooheon wrote: post #45
jwr wrote: post #4

As a data point, I've just written a significant ClojureScript application, using React (Rum for bindings, Datascript for client-side db). It's amazing how quickly one can create complex apps with impressive performance out of the box. If you haven't used ClojureScript, it is definitely worth looking at.

I'm curious if this is a project you could share?

PartsBox, https://partsbox.io/ — but the app itself isn't public yet, it's in a private beta for now.

Re: Why ClojureScript Matters

#54

Post by bostonOU »

glenjamin wrote: post #33
bostonOU wrote: post #10

Earlier quoted context omitted.

Can you explain why Om hurts your brain? I've heard other people say similar things, but I've never quite understood why. Is it cursors? Local component state?

I think part of the reason some people feel this way about Om is that it was built as an experiment - specifically an experiment about handling immutable state in React. I find that Om has very strong opinions about doing state the clojure way, but is a very thin wrapper around the rest of React's API - which leads to a feeling of inconsistency. Some of the stuff David's suggested will be part of "Om next" I think wi…

The inconsistency part makes sense, I guess I just never thought it was a big deal. If you're going to use WillMount, it's either going to be with reify (Om) or meta (Reagent). Doesn't seem like an important distinction to me, but obviously it is to some people. And that's totally legitimate.

Re: Why ClojureScript Matters

#55

Post by jwr »

javajosh wrote: post #28
jwr wrote: post #4

As a data point, I've just written a significant ClojureScript application, using React (Rum for bindings, Datascript for client-side db). It's amazing how quickly one can create complex apps with impressive performance out of the box. If you haven't used ClojureScript, it is definitely worth looking at.

How did you select your components? I've never heard of Rum or Datascript, for example.

It's true that it isn't that easy to discover new libraries, especially as there seem to be lots of them popping up. You generally hear about these things from the community (which is great, btw!), or public talks. Nikita Prokopov is a brand by now, so I tend to watch his work closely.

Re: Why ClojureScript Matters

#56

Post by jeremiep »

Touche wrote: post #43
warfangle wrote: post #25

Earlier quoted context omitted.

Composition over inheritance wins, so hard. (edit: downvote for a typically well-thought-of idiom, especially with regard to a language like js? .. if you disagree, why not talk about it?)

Classes are unavoidable in JavaScript if you care about performance. Recreating redundant functions inside a closure in performance critical code is a sure way to have slow apps.

Creating an object and creating a closure both need to allocate memory in the VM, but the closure doesn't need to expose its internals the way an object does and therefore can be further optimized by the runtime.

If you need to write performance critical JavaScript, then allocating new objects will be just as slow as creating new closures. In either cases you should allocate them ahead of time and then closures are still the clear winner.

Re: Why ClojureScript Matters

#57

Post by nickik »

jwr wrote: post #4

As a data point, I've just written a significant ClojureScript application, using React (Rum for bindings, Datascript for client-side db). It's amazing how quickly one can create complex apps with impressive performance out of the box. If you haven't used ClojureScript, it is definitely worth looking at.

Can I somewhere find a good Rum/Datascript ClojureScript application that is easy to understand? Maybe something with a blog post that goes into how to set up such a project.

With ClojureScript I always have probelems to get running, and how to devlop effectivly. All the information are old and outdated.

I love the idea of DataScipt/React but I have not really done to much until now.

Edit: I know of the creaters blog, but I would like more.

Re: Why ClojureScript Matters

#58

Post by emidln »

Touche wrote: post #44

One thing Clojure/ClojureScript desperately needs is an answer for progressive-enhancement.

No it doesn't. You can literally do the same thing you did with PHP in 2007 if you want to (have a controller that outputs xml to be transformed into jquery commands if an ajax call or renders html if not ajax). You could also do something less silly like share your templates (maybe via hiccup and its many cljs implementations or via enlive/enforce/kioo (or via Soy, or anything else really)). If you want to get really fancy, you can actually just render your js server side via nashhorn and then rebind whatever modern rendering library you choose (React, Ember, etc) onto the rendered html at runtime. This is all ignoring the fact that nothing prevents you from serving html from server-side templates and keeping your cljs codebase completely separately ala most web apps (then progressively enhancing with whatever you normally would).

Re: Why ClojureScript Matters

#59

Post by chowes »

I've come to appreciate some of the new ES6 features (anonymous functions, lets) much more after using their equivalents in ClojureScript.

Also, The interactive REPL based workflow that a lot of the LISP languages utilize is extremely appealing. I've been thinking a lot about how to bring this back into the JS world. I have yet to find any good literature on it, but I will be exploring this area more.

For those curious, here are some blogs that convinced me to finally give Clojure a spin:

- http://rigsomelight.com/2014/05/01/interactive-programming-f... (seems like this is the stereotypical "you should try ClojureScript because... " post)

- http://thinkrelevance.com/blog/2013/06/04/clojure-workflow-r... (a bit code-heavy, but an admirable workflow)

- http://swannodette.github.io/2013/11/07/clojurescript-101/ (dealing with asynchronous code)

I'm curious HN, anyone out there making strides in interactive JS development, akin to the 2nd blog post I referenced above?

Re: Why ClojureScript Matters

#60

Post by thiago_fm »

swannodette wrote: post #36
MikeOfAu wrote: post #29

Earlier quoted context omitted.

OM components are complex. There are global transaction/message channels, component local state, an OO backpane, lifecycle functions, functional zippers, hierarchy organised data, etc. I can't understand how anyone could claim it to be simple. Look at this example code, apparently held in such high regard that it is referenced off the front page of OM: https://github.com/swannodette/om-sync To me that is a ghastly, i…

Some inaccuracies here about Om. There are no message channels. There are no functional zippers. Component local state and lifecycle are critical React integration points. Hierarchy organized data is not required - people have succeeded at integrating DataScript. om-sync isn't even an official thing, just got tired of people asking me about a basic example :) If you don't like Om, that's really OK. The real goal of O…

I also feel that Om is very complex. I'm sure I've spent over 20 hours trying to wrap my head around it but didn't manage to do anything.

From the people that know it well, they all love it. But I don't seem to have the required knowledge to understand it. I feel somehow dumb by that. The docs aren't good also.

After that, I've tried reagent for 30 minutes and ended up with a lot of progress and I'm currently writing my first cljs small app. Everything seems to work and it's like clojure.

You have an atom and just have to write views in a hiccup style, everything magically works.

Maybe I will try Om later and get it, but it's not simple. I've been able to wrap my head around a lot of concepts with easy in my life, but Om felt too much.

Post reply on HN