Why ClojureScript Matters • Hacker News Board

Re: Why ClojureScript Matters

#21

Post by jeremiep » Mon, Jun 29, 2015, 2:08 PM UTC

Cshelton wrote: post #16

warfangle wrote: post #14

Earlier quoted context omitted.

'class' is one of the most commonly mentioned but least useful constructs available in ES6. Things that win out over it? Destructured assignment, sane module syntax, arrow functions, true block scope variable declaration, and constants.

Yes, but people coming from java or c# or something will like it. Despite it being just syntactical sugar. I wasn't about to list out all the benefits of es6, that would take several entire blog posts.

I would rather see ES6 with no class support whatsoever and having people learn to code without them instead of adding features to satisfy the lowest common denominator.

I've used classes in CoffeeScript and regretted it every single time. Once your web project starts to grow in scale classes quickly become your first pain point. Especially given how functional JS libraries have become nowadays.

Re: Why ClojureScript Matters

#22

Post by eropple » Mon, Jun 29, 2015, 2:11 PM UTC

aardvark179 wrote: post #5

bobajeff wrote: post #2

By the time JavaScript is being compiled down to WebAssembly you'll probably also be able to have the full Clojure, Scala, Java and other JVM based languages (also .Net languages) compiled down there as well.

That's going to be long time coming. To be a suitable target for higher level languages wasm is going to have to gain GC, method dispatch instructions (preferably with the sort of machinery invokeDynamic on the JVM provides, because method dispatch isn't identical across languages), dynamic code loading, threads, and probably a bunch of other stuff. Wasm is definitely a good start, but it is only a start right now. I…

I'm not sure why you say that a traditionally JITed language won't benefit from this. We've had AOT compilers for the JVM and for .NET for years.

The perf may be slightly worse, but we've had good-enough perf forever.

Re: Why ClojureScript Matters

#23

Post by jeremiep » Mon, Jun 29, 2015, 2:13 PM UTC

manishsharan wrote: post #18

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.

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

They're talking about the split of programmers, not of concerns. The client-server model is definitely here to stay but having separate groups of people handling each side is a sure way to greatly lower the quality of the product.

Re: Why ClojureScript Matters

#24

Post by jeremiep » Mon, Jun 29, 2015, 2:14 PM UTC

Frozenlock wrote: post #20

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?

It was mostly the whole reify dance, which I never had to do in any other clojure/clojurescript project.

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

Re: Why ClojureScript Matters

#25

Post by warfangle » Mon, Jun 29, 2015, 2:17 PM UTC

jeremiep wrote: post #21

Cshelton wrote: post #16

Earlier quoted context omitted.

Yes, but people coming from java or c# or something will like it. Despite it being just syntactical sugar. I wasn't about to list out all the benefits of es6, that would take several entire blog posts.

I would rather see ES6 with no class support whatsoever and having people learn to code without them instead of adding features to satisfy the lowest common denominator. I've used classes in CoffeeScript and regretted it every single time. Once your web project starts to grow in scale classes quickly become your first pain point. Especially given how functional JS libraries have become nowadays.

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

Re: Why ClojureScript Matters

#26

Post by woah » Mon, Jun 29, 2015, 2:20 PM UTC

rubiquity wrote: post #11

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…

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.

It's not an abstraction, it's an accidental byproduct of physical hardware placement.

Re: Why ClojureScript Matters

#27

Post by Frozenlock » Mon, Jun 29, 2015, 2:23 PM UTC

jeremiep wrote: post #24

Frozenlock wrote: post #20

Earlier quoted context omitted.

It was mostly the whole reify dance, which I never had to do in any other clojure/clojurescript project.

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

Re: Why ClojureScript Matters

#28

Post by javajosh » Mon, Jun 29, 2015, 2:23 PM UTC

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.

Re: Why ClojureScript Matters

#29

Post by MikeOfAu » Mon, Jun 29, 2015, 2:29 PM UTC

bostonOU wrote: post #10

Frozenlock wrote: post #6

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

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?

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, inexcusably complected hairball.

Don't get me wrong. I really like clojurescript. I program in it daily, on purpose. It is just that I'm shocked at the level of devotion and adulation for OM when there are really lovely alternatives like Reagent and Rum.

Re: Why ClojureScript Matters

#30

Post by javajosh » Mon, Jun 29, 2015, 2:29 PM UTC

manishsharan wrote: post #18

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.

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. Meteor shows what you can do with this. Maybe ClojureScript can do this, but with a better language.)