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

41–50 of 121 posts

Re: Why ClojureScript Matters

#41

Post by bryanlarsen »

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…

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.

Re: Why ClojureScript Matters

#42

Post by bad_user »

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…

That's a nice myth, however in practice what happens is exactly the opposite, mostly because people lose sight of the whole picture and end up super specialized on small pieces of the puzzle. This is what happens in corporations, where the whole reason for why projects succeed is because of the invested resources, work still being done on the model of the Egyptian pyramids, with thousands pushing large bricks. There's a reason for why micro-services that don't start as a monolith are failing - people have this impression that micro-services are imposing clearer boundaries, which is of course wrong.

Re: Why ClojureScript Matters

#43

Post by Touche »

warfangle wrote: post #25
jeremiep wrote: post #21

Earlier quoted context omitted.

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

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.

Re: Why ClojureScript Matters

#45

Post by sooheon »

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?

Re: Why ClojureScript Matters

#46

Post by manishsharan »

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…

(apologies for replying to my own comment, but I want to highlight some reasons by division of labour between backend and frontend development work is important).

Typically, backend developers need to have specialized knowledge of the enterprise security system which needs to be invokoked for authorization requests. Also the backend developers need to worry about availability/clustering issues. They also have to be familiar with caching subsystems in place , observe or predict the api requests patternt and implement caching strategies. They have to deal with a 'different scale' of concurrency issues than normal ui devs. The there is the issue of api versioning: there will be clients/user who will not upgrade and the backend development team has to figure how to support multiple versions of the same API. Then there is the issue of deployment and packaging: not every development shop lets developer push deployment into directly into production.Then there is the issue of database queries : you will have to optimize those heavily in consultation with your database admin. If you are using JVM, you have to optimize that for your application. The frontend development work has its own set of equally vexing challenges.

There is no doubt that any competent developer can handle all these tasks but it won't be the kumbaya singing utopian happy habitable code paradise that this blogger is seeking. Division of labor between backend and frontend is a life saver for developers. I would actually want to go home and not spend my life in this "habitable" place.

Re: Why ClojureScript Matters

#47

Post by straws »

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.

Nikita Prokopov has presented a pretty cohesive vision for front-end programming in the cljs community. Even if you don't agree with all of his opinions, he's one of the only people assembling a big picture about how to write apps in this way. It's worth reading his blog:

http://tonsky.me/

An emphasis on low-level tooling and not enough discussion around high-level architecture/examples has hurt the react+cljs combo adoption from my point of view. It's the nature of Lisp to come up with your own abstractions around application architecture, but the community would be wise to talk more about solving common web patterns and how to cleanly break away from those patterns when necessary.

Re: Why ClojureScript Matters

#48

Post by spion »

outworlder wrote: post #35
Cshelton wrote: post #7

While clojureScript is awesome and gets you to think differently when writing javascript, I think a more interesting thing people should check out it es6 (or ecmascript 6, or es 2015, w/e it's called now.). It brings many new things to javascript that people from other languages will be used to...likes the "class" syntax. Right now you can write near 100% es6 standard with a pre-compiler. Most use babel. Soon it will…

I think the 'class' keyword is a mistake. People were happily creating class-like constructs before. But the exposed javascript "objects" made it clear it wasn't a traditional "class" found in other languages. Also, how is ES6 more interesting than ClojureScript?

There is no single "traditional class" in other languages. Pretty much every language has its own flavor of classes with different restrictions and internals.

Re: Why ClojureScript Matters

#49

Post by bostonOU »

okal wrote: post #19
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 use it every day, but there's always some aspect of its behaviour that it turns out I didn't understand the first time round. Perhaps that's because I jumped into the project with only a very rudimentary understanding of Om, just enough to complete a certain ticket. I've since then spent a lot of time going through the docs, but it just conceptually doesn't sit well with my brain. Sorry I can't give a more useful a…

While not a specific answer, "feels" is a valid response IMO. Like mentioned elsewhere, using reify seems to throw people off, which falls in to the "feels" category I think.

Re: Why ClojureScript Matters

#50

Post by murbard2 »

bryanlarsen wrote: post #41
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…

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?
Post reply on HN