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

31–40 of 121 posts

Re: Why ClojureScript Matters

#31

Post by fendrak »

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.

I recommend using https://github.com/Prismatic/om-tools, if only for the defcomponent macro: https://github.com/Prismatic/om-tools#defcomponent

This abstracts out all the reify stuff and makes for far cleaner component definitions.

Re: Why ClojureScript Matters

#32

Post by [deleted] »

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.

[deleted]

Re: Why ClojureScript Matters

#33

Post by glenjamin »

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 think part of the reason some people feel this way about Om is that it was built as an experiment - specifically an experiment about handling immutable state in React.

I find that Om has very strong opinions about doing state the clojure way, but is a very thin wrapper around the rest of React's API - which leads to a feeling of inconsistency.

Some of the stuff David's suggested will be part of "Om next" I think will address this.

Re: Why ClojureScript Matters

#34

Post by pbowyer »

I disagree with some of the statements about developer pride. I was reading https://speakerdeck.com/garann/code-is-a-job this morning and it's a position I have a lot of sympathy with.

Not having the backend developer/fronted developer split is good; while each will have its own specialities, they shouldn't be siloed into separate teams.

Re: Why ClojureScript Matters

#35

Post by outworlder »

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?

Re: Why ClojureScript Matters

#36

Post by swannodette »

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…

Some inaccuracies here about Om. There are no message channels. There are no functional zippers. Component local state and lifecycle are critical React integration points. Hierarchy organized data is not required - people have succeeded at integrating DataScript. om-sync isn't even an official thing, just got tired of people asking me about a basic example :)

If you don't like Om, that's really OK. The real goal of Om was always to inspire people to consider and research alternatives to traditional client-side MVC. 16 months in I would say with the large number of excellent alternatives, Om very much succeeded.

I hope Om Next accomplishes the same broad goal and convinces people to seriously consider the big ideas behind Relay/GraphQL, JSONGraph/Falcor, and Datomic.

Re: Why ClojureScript Matters

#37

Post by qzcx »

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…

The one thing that I don't understand about his argument is why having dedicated QA is bad? Having QA doesn't mean you shouldn't test your own code, but you have blind spots when it comes to testing your own code. It is easy to make assumptions about how your code should work.

Re: Why ClojureScript Matters

#38

Post by pbowyer »

qzcx wrote: post #37
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…

The one thing that I don't understand about his argument is why having dedicated QA is bad? Having QA doesn't mean you shouldn't test your own code, but you have blind spots when it comes to testing your own code. It is easy to make assumptions about how your code should work.

The post has a good core, but is wrapped in opinions like this which detract. I agree with you entirely: I produce my best code when I test everything, and then someone else tests and discovers the parts I excluded from 'everything'.

Re: Why ClojureScript Matters

#39

Post by qzcx »

pbowyer wrote: post #34

I disagree with some of the statements about developer pride. I was reading https://speakerdeck.com/garann/code-is-a-job this morning and it's a position I have a lot of sympathy with. Not having the backend developer/fronted developer split is good; while each will have its own specialities, they shouldn't be siloed into separate teams.

Thanks for sharing. Good read.

Re: Why ClojureScript Matters

#40

Post by MikeOfAu »

swannodette wrote: post #36
MikeOfAu wrote: post #29

Earlier quoted context omitted.

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…

Some inaccuracies here about Om. There are no message channels. There are no functional zippers. Component local state and lifecycle are critical React integration points. Hierarchy organized data is not required - people have succeeded at integrating DataScript. om-sync isn't even an official thing, just got tired of people asking me about a basic example :) If you don't like Om, that's really OK. The real goal of O…

No zippers? Why then does the official OM docs say "Cursors are conceptually related to functional lenses and zippers". Remember this thread relates to how simple or easy OM is to grok.

And no message channels? Why then does the intermediate tutorial plunge straight into the use of core.async?

I have no problem with OM being considered a grand experiment. I wouldn't use it but it has been an interesting idea generator. Please remember context here - I was responding to someone who claims astonishment that OM could be considered difficult to understand.

But, in terms of grand experiments, let's remember that Reagent came out at exactly the same time as OM. And Hoplon lead the way on Reative (FRP) long before either. So, having lived through it, I'd feel very uncomfortable with any overreaching claims about OM succeeding in inspiring all the others into the alternative MVC holy land. The others were there already.

Post reply on HN