Why ClojureScript Matters • Hacker News Board

Re: Why ClojureScript Matters

#91

Post by netcraft » Mon, Jun 29, 2015, 5:41 PM UTC

Kiro wrote: post #81

bryanlarsen wrote: post #13

Earlier quoted context omitted.

Sure, any large code base needs to be modular, but why impose an arbitrary split? We've got a large Node.js codebase. Some of the code runs only on the server, some runs only on the client, but the majority runs on both. Our code is split into modules for functional reasons.

> but the majority runs on both What does this mean exactly? What kind of code needs to run on both?

I tend to agree with you, but there are things that can/should run on both - validation of input for one. But I'd like to hear other things - I hear "use the same code on the server and client" all the time, but I haven't found a lot of use for that personally.

Re: Why ClojureScript Matters

#92

Post by jeremiep » Mon, Jun 29, 2015, 5:50 PM UTC

Touche wrote: post #73

jeremiep wrote: post #56

Earlier quoted context omitted.

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 s…

> If you need to write performance critical JavaScript, then allocating new objects will be just as slow as creating new closures. No, it won't. This code: function createThing() { return { doSomething: function(){} }; } Performs much worse (at scale) than this code: new Thing(); And it consumes a lot more memory since Thing.prototype.doSomething is 1 function in memory and the former is N functions.

I try to avoid OOP in my JavaScript code like the plague, I'd probably write it like this:

    function doSomething(obj){}

    var objs = [{},{},{}];
    objs.forEach(doSomething);

If I need late binding I'll use something like clojure's multi-methods. Both closures and prototypes aren't needed for this :)

Re: Why ClojureScript Matters

#93

Post by jeremiep » Mon, Jun 29, 2015, 5:52 PM UTC

warfangle wrote: post #68

jeremiep wrote: post #56

Earlier quoted context omitted.

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 s…

> 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. Actually... creating an object instance via a constructor lets the runtime use an internal class, which improves performance (as long as you don't modify its properties post-construction). This is a well-k…

Even with an internal class you're still doing lookups for properties. A closure can instead use local variables which are accessed by index. Why do you think its good practice to pull properties out of objects and into local variables before a tight loop?

Re: Why ClojureScript Matters

#94

Post by escherize » Mon, Jun 29, 2015, 5:52 PM UTC

emidln wrote: post #76

Touche wrote: post #72

Earlier quoted context omitted.

It really does. Isomorphic is the new standard. Doing it in a very manual way is not good enough. Every new JS framework is expected to do this out of the box and the older frameworks are scurrying to gain support.

React literally does this out of the box. Om does it (based on react). Reagent does it (based on react). Using js/React (raw js interop) does it. There is actually nothing to do. You exec your js in a nashhorn thread. That gives you some html. You ship it your browser on initial GET, then initialize react on it. This is identical to what you'd be doing on react+node. With a macro or two, it's easier than anything nod…

Do you have a link to these macros?

Re: Why ClojureScript Matters

#95

Post by jwr » Mon, Jun 29, 2015, 5:52 PM UTC

nickik wrote: post #57

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…

Nikita's blog posts are pretty good. I found this one to be informative: http://tonsky.me/blog/datascript-chat/

Re: Why ClojureScript Matters

#96

Post by jimbokun » Mon, Jun 29, 2015, 6:20 PM UTC

thiago_fm wrote: post #60

swannodette wrote: post #36

Earlier quoted context omitted.

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…

"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."

When I get this feeling, it's often because I haven't yet experienced the problems the new thing is trying to solve. Is it possible Om is an attempt to solve problems you haven't encountered?

I have no personal experience with Clojurescript (love Clojure, though), so this is just a generic comment.

Re: Why ClojureScript Matters

#97

Post by jimbokun » Mon, Jun 29, 2015, 6:25 PM UTC

manishsharan wrote: post #8

I think that the main argument presented in this blog -- "avoiding splitting" is wrong :Splitting the development into frontend and backend is essential for developing maintainable code for large projects. Having a well defined communication api between backed and frontend defines responsibility for front end and backend developers and also enable better (j)unit test cases. The communication overhead and associated d…

I think Clojure owes much of its success to the acceptance of using multiple languages in the same project.

Maybe breaking off a small piece of functionality in a Java project to try implementing in Clojure.

Maybe implementing a service with a REST API in Clojure accessed from clients written in other languages.

So I find it a little ironic, and maybe short sighted, to hear "write everything in one language" used as an argument for using Clojurescript.

Re: Why ClojureScript Matters

#98

Post by malcolmjuxt » Mon, Jun 29, 2015, 6:41 PM UTC

saosebastiao wrote: post #83

So I tried Clojurescript and I liked it as a language. In terms of fit for a compile-to-Javascript language, it is probably the best implementation out there, partially due to Javascript's dynamic lispy origin. But it has a a major problem: It's not Clojure. It might be a Clojure-like language, but its not Clojure. So you still end up "splitting", but when you split you have to squint harder at the details. As far as…

I haven't used Scala.js, but I find Clojure and ClojureScript to be so damn close to identical I'm surprised at this comment. When I'm doing ClojureScript, everything I use from syntax, sequences, persistent data structures, core.async, protocols and records (the list seems endless) is the same as Clojure. The only thing that trips me up is regular expressions. In fact, I find there's a great deal more difference in the Scala written by any given two Scala developers than between Clojure and ClojureScript.

Re: Why ClojureScript Matters

#99

Post by grayrest » Mon, Jun 29, 2015, 6:50 PM UTC

chowes wrote: post #59

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 curio…

> 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.

The JS equivalent of figwheel is React Hot Loader[1]. There's a port of core.async[2] but I've also seen people using Babelized ES7 async/await for avoiding callbacks. The reloaded workflow is just a pattern around building objects with a topological sort for order initialization. I expect you could build a JS version in ~200 lines of code.

[1] https://github.com/gaearon/react-hot-loader [2] https://github.com/ubolonton/js-csp

I'm unaware of editor integration between an editor and browser runtime a la slime/nrepl. I think LightTable had a basic implementation but it's been a while and I could be remembering it incorrectly.

Re: Why ClojureScript Matters

#100

Post by sbensu » Mon, Jun 29, 2015, 6:51 PM UTC

sgrove wrote: post #70

mordocai wrote: post #63

Earlier quoted context omitted.

I can agree with that with clojurescript, but I disagree that clojure itself has this problem. Clojurescript -should- be calming down soon. It is in a stage of changing constantly ATM but that should calm down once some of the underlying tech is stabilized (like clojurescript bootstrapped from clojurescript).

I get the same impressions. Even working with ClojureScript professionally for ~3 years, contributing to the compiler (a tiny, tiny bit), and diving deep into a lot of the libraries... the tooling story is way too chaotic for me. But I'm somewhat OK with it, as the changes generally seem to be positive, and I have hope that the stability will coalesce around a good, rather than rotten-but-papered-over, core.

I feel the same way. The ClojureScript compiler routinely makes the conceptually sound choices even in the face of breakage. This leads to unstable tooling but the quality of the underlying code allows for bigger and better conceptual improvements.