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

61–70 of 121 posts

Re: Why ClojureScript Matters

#61

Post by tomjen3 »

javajosh wrote: post #30
manishsharan wrote: post #18

Earlier quoted context omitted.

The split between backend and frontend is not arbitrary; it is based on client-server paradigm and it has worked well.

I'm not sure why you're getting downvoted, because you're right. To be more specific, server code has very different responsibilities than client code, not to mention very different runtime characteristics (e.g. servers are both trusted and under total central control, unlike clients). To say that the client/server split is "arbitrary" is rather silly. (That's not to say I'm not a fan of an end-to-end language. Meteo…

He is getting downvoted, and rightly so, because the person is replying to has clearly set up his system is such a way that some code runs on both the server and the client.

Which is very reasonable, btw, as it allows you to have a static site that renders for those whoes browsers doesn't run javascript and a more dynamic page for those whoes browser does run Javascript. You are guaranteed that everything renders the same way only if you excecute the same code (this can't be replaced by e.g a sensible template system because rendering might also be affected by how you, e.g, sort comments).

Re: Why ClojureScript Matters

#62

Post by smrtinsert »

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…

Honestly this is the part I hate most about Clojure. The tooling is always so convoluted to setup and by the time you start your next project something has changed again, requiring more changes which might break your tool chain. ClojureScript is especially guilty of this right now with all the recent repl changes.

I appreciate the The CS team trying to work with 3rd party repl developers right now, but it doesn't seem to be helping much. It's pushed me back to simple gulp based es6 dev using ramda, rxjs, immutablejs, etc - basically the parts of clojurescript I like. The only thing I sort of miss from Clojure are macros and homoiconicity - it sure is nice to look so uniform, but the tooling just drives me away.

Re: Why ClojureScript Matters

#63

Post by mordocai »

smrtinsert wrote: post #62
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…

Honestly this is the part I hate most about Clojure. The tooling is always so convoluted to setup and by the time you start your next project something has changed again, requiring more changes which might break your tool chain. ClojureScript is especially guilty of this right now with all the recent repl changes. I appreciate the The CS team trying to work with 3rd party repl developers right now, but it doesn't see…

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

Re: Why ClojureScript Matters

#64

Post by bryanlarsen »

murbard2 wrote: post #50
bryanlarsen wrote: post #41

Earlier quoted context omitted.

We have lots of code that runs on both the server and the client. It has the same responsibility whether it's run on the server or the client.

Can you provide some examples?

To oversimplify, if the user clicks on a button on our website, the app checks to see if the operation can be done client-side. If it can be done client side, it's done client side instantaneously. If it's too big to do client-side or requires access to resources that aren't available on the client, the app submits a job to the server, and shows the client a progress bar.

Re: Why ClojureScript Matters

#65

Post by bryanlarsen »

tomjen3 wrote: post #61
javajosh wrote: post #30

Earlier quoted context omitted.

I'm not sure why you're getting downvoted, because you're right. To be more specific, server code has very different responsibilities than client code, not to mention very different runtime characteristics (e.g. servers are both trusted and under total central control, unlike clients). To say that the client/server split is "arbitrary" is rather silly. (That's not to say I'm not a fan of an end-to-end language. Meteo…

He is getting downvoted, and rightly so, because the person is replying to has clearly set up his system is such a way that some code runs on both the server and the client. Which is very reasonable, btw, as it allows you to have a static site that renders for those whoes browsers doesn't run javascript and a more dynamic page for those whoes browser does run Javascript. You are guaranteed that everything renders the…

We're doing that too, but that's the boring part. That's just running client-side code on the server. It's still client-side code. You can do that in Rails too. See my other comment for more details.

Re: Why ClojureScript Matters

#66

Post by [deleted] »

jeremiep wrote: post #56
Touche wrote: post #43

Earlier quoted context omitted.

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

[deleted]

Re: Why ClojureScript Matters

#67

Post by rubiquity »

jeremiep wrote: post #17
rubiquity wrote: post #11

Earlier quoted context omitted.

Agreed. The client-server abstraction is one of the very best in the history of computing. I don't know why so many people are trying to do away with it.

The article doesn't mention doing away with client-server architectures but rather the separation of frontend and backend programmers which is indeed very harmful.

I think trying to write your apps in this way hides the underlying client-server architecture.

Re: Why ClojureScript Matters

#68

Post by warfangle »

jeremiep wrote: post #56
Touche wrote: post #43

Earlier quoted context omitted.

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 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-known aspect of V8 performance.

Re: Why ClojureScript Matters

#69

Post by warfangle »

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.

Certainly.

But if object instantiation / garbage collection is your bottle neck, you should be using an object pool, anyways.

You wouldn't put _every_ object in an object pool, though - only those which obviously impact performance after identifying them as a bottleneck.

I'd hope you optimize for maintainability before you optimize for performance, otherwise you'll end up optimizing bottlenecks that don't exist.

Re: Why ClojureScript Matters

#70

Post by sgrove »

mordocai wrote: post #63
smrtinsert wrote: post #62

Earlier quoted context omitted.

Honestly this is the part I hate most about Clojure. The tooling is always so convoluted to setup and by the time you start your next project something has changed again, requiring more changes which might break your tool chain. ClojureScript is especially guilty of this right now with all the recent repl changes. I appreciate the The CS team trying to work with 3rd party repl developers right now, but it doesn't see…

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.

Post reply on HN