Why ClojureScript Matters • Hacker News Board

Re: Why ClojureScript Matters

#81

Post by Kiro » Mon, Jun 29, 2015, 5:28 PM UTC

bryanlarsen wrote: post #13

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…

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?

Re: Why ClojureScript Matters

#82

Post by serve_yay » Mon, Jun 29, 2015, 5:28 PM UTC

bryanlarsen wrote: post #9

Much more relevant than WASM in 2015 is that modern Javascript development is also moving towards compilation. There's little fundamental difference between compiling ES7 via babel.js vs compiling clojurescript.

I had a similar thought, though for me that's a reason to keep using Babel and ES.next rather than ClojureScript. I find lispy syntax difficult to read.

Re: Why ClojureScript Matters

#83

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

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 fidelity to the native language, I've found Scala.js to be much better.

I can't wait for WebAssembly though... it will be a game changer for people that prefer strong static typing for managing logical complexity.

Re: Why ClojureScript Matters

#84

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

woah wrote: post #26

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.

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

Client server is about having more than one consumer that needs to share and mutate the same data. In other words, collaboration. In general the pattern doesn't care where the hardware is located.

Remote hardware just accentuates issues that are only obvious due to high latency. A local system for example could get away with a less sophisticated locking mechanism... until it doesn't.

Re: Why ClojureScript Matters

#85

Post by KurtMueller » Mon, Jun 29, 2015, 5:32 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.

One of the concepts I really like about cljs frameworks like Om and Reagent is the concept of a single hierarchical data structure that components read from/write to. This concepts makes thinking about my app and its structure so much easier.

Re: Why ClojureScript Matters

#86

Post by tracker1 » Mon, Jun 29, 2015, 5:35 PM UTC

bryanlarsen wrote: post #15

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…

Splitting teams along the API boundary is a sure way to get crappy API's. To get good API's you need to dogfood the API. In other words the team that writes the server side should be writing at least one of the clients consuming the API.

I'll go a step farther... the consuming API client should be in a different language/idiom than the server-side implementation (assuming multiple languages are going to be used in your environment).

Too often I try to access Java or PHP web services from .Net, where the tooling is very strict, and it just falls apart. Or I'll have to use something via JS that is just excessively painful to use in practice for no good reason.

I've also seen time and again layers of indirection or other design patterns used without any consideration of why they are being used in that instance. You don't have to hide your data tier behind factories of repositories. You don't have to make everything an interface. If you aren't going to test anyway, make the code as simple as possible. I tend to favor only adding complexity if it makes those complicated pieces easier to use in practice, and even then not all the time.

Sorry for the rant, I just see time and again certain levels of complexity without flexibility or consideration for why.

Re: Why ClojureScript Matters

#87

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

MikeOfAu wrote: post #29

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?

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…

I think it's mostly a matter of personal preference. There are multiple React interfaces in ClojureScript: Om, Reagent, Rum, Quiescent being the most popular. Pick whichever you like.

I looked at Om, found it too verbose, and switched to Reagent. I then found it too limiting, so I ended up using Rum, which I think is the most flexible and the most minimalistic. I think it's great that we have the choice and that we can cross-polinate ideas between various libraries.

Re: Why ClojureScript Matters

#88

Post by mikerichards » Mon, Jun 29, 2015, 5:37 PM UTC

Taking the 'splitting' argument head on, I don't believe that having a planned split between 'front end' and 'back end' developers is a good idea at all.

I don't like that he seems to have to concoct that argument to sell ClojureScript. The argument seems artificial.

There's lots of reasons to decouple the front-end development from backend development. In fact, once you start using a client framework and use the backend as a service layer you can really decouple your layers. Doing web stuff, I primarily work in ASP.NET MVC and I'm trying to get rid of razor completely.

In fact, If I had my way, I'd have css/photoshop jockeyes (with a little angular/whatever knowledge) in charge of the client, a javascript/Typescript guy doing the client MVC, and a data guy doing Web API.

Agile tends to frown on these distinctions. I don't buy it , just like I don't buy a lot of the Agile dogma. Oh well.

Re: Why ClojureScript Matters

#89

Post by mikerichards » Mon, Jun 29, 2015, 5:39 PM UTC

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.

Then we go full circle and go back to Web Forms?

Re: Why ClojureScript Matters

#90

Post by mikerichards » Mon, Jun 29, 2015, 5:40 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…

You're right, but current agile dogma frowns on that. I think a lot of us like being a "full stack" developer too. It's part of our ego that we like going from our procs to the css