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

11–20 of 121 posts

Re: Why ClojureScript Matters

#11

Post by rubiquity »

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.

Re: Why ClojureScript Matters

#12

Post by warfangle »

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…

Having a well defined and documented API is not an artifact of splitting development roles between front and back end. There are many, many projects out there with split roles that have terribly defined and ill-documented server interfaces.

It's an artifact of having competent developers, be they full stack or not.

Re: Why ClojureScript Matters

#13

Post by bryanlarsen »

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.

Re: Why ClojureScript Matters

#14

Post by warfangle »

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…

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

Re: Why ClojureScript Matters

#15

Post by bryanlarsen »

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.

Re: Why ClojureScript Matters

#16

Post by Cshelton »

warfangle wrote: post #14
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…

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

Re: Why ClojureScript Matters

#17

Post by jeremiep »

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.

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.

Re: Why ClojureScript Matters

#18

Post by manishsharan »

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.

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

Re: Why ClojureScript Matters

#19

Post by okal »

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?

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 answer. Reagent on the other hand, which I haven't used in production, just "feels" better every time I play with it.

The thing that helped my understanding most was a recent project where I got to work with React directly. Also, reading the source.

So yes, it's mostly because I'm a little lazy, but Reagent doesn't seem to punish me for that same laziness. 😆

EDIT: More details.

Re: Why ClojureScript Matters

#20

Post by Frozenlock »

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?

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