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

101–110 of 121 posts

Re: Why ClojureScript Matters

#101

Post by imsofuture »

bad_user wrote: post #42
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'…

The danger of having people who aren't specialized is just as great as the danger of having people too specialized.

Backend and frontend concerns are completely different, and it's fiction that you can simply wave those concerns aside and write the same sort of software anywhere in your stack.

Re: Why ClojureScript Matters

#102

Post by danneu »

netcraft wrote: post #91
Kiro wrote: post #81

Earlier quoted context omitted.

> but the majority runs on both What does this mean exactly? What kind of code needs to run on both?

I tend to agree with you, but there are things that can/should run on both - validation of input for one. But I'd like to hear other things - I hear "use the same code on the server and client" all the time, but I haven't found a lot of use for that personally.

Another common example is something like a Markdown/BBCode parser.

Re: Why ClojureScript Matters

#103

Post by rymndhng »

I'm still waiting for stable tooling support. With Clojure 1.7, the introduction of Reader Conditionals via `.cljc` is a step in the right direction.

The tooling still isn't quite ready yet. I've tried porting some `.cljx` code over, but it's not quite working for me yet with leiningen.

Re: Why ClojureScript Matters

#104

Post by fnordsensei »

escherize wrote: post #94
emidln wrote: post #76

Earlier quoted context omitted.

React literally does this out of the box. Om does it (based on react). Reagent does it (based on react). Using js/React (raw js interop) does it. There is actually nothing to do. You exec your js in a nashhorn thread. That gives you some html. You ship it your browser on initial GET, then initialize react on it. This is identical to what you'd be doing on react+node. With a macro or two, it's easier than anything nod…

Do you have a link to these macros?

Here's a spot to start from: https://github.com/DomKM/omelette

EDIT: The example in the link provided builds on the now deprecated CLJX, so it's not entirely up to speed. (CLJX was the way to write clj/cljs in the same codebase until "reader conditionals" came along).

Re: Why ClojureScript Matters

#105

Post by [deleted] »

Kiro wrote: post #81
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.

> but the majority runs on both What does this mean exactly? What kind of code needs to run on both?

[deleted]

Re: Why ClojureScript Matters

#106

Post by Touche »

emidln wrote: post #76
Touche wrote: post #72

Earlier quoted context omitted.

It really does. Isomorphic is the new standard. Doing it in a very manual way is not good enough. Every new JS framework is expected to do this out of the box and the older frameworks are scurrying to gain support.

React literally does this out of the box. Om does it (based on react). Reagent does it (based on react). Using js/React (raw js interop) does it. There is actually nothing to do. You exec your js in a nashhorn thread. That gives you some html. You ship it your browser on initial GET, then initialize react on it. This is identical to what you'd be doing on react+node. With a macro or two, it's easier than anything nod…

> React literally does this out of the box. Om does it (based on react). Reagent does it (based on react). Using js/React (raw js interop) does it. There is actually nothing to do. You exec your js in a nashhorn thread. That gives you some html. You ship it your browser on initial GET, then initialize react on it.

You're being disingenuous, I read the ClojureScript mailing list, this subject comes up regularly. People are still figuring it out, Nashorn is not well documented and the use of it for this purpose is not well documented. Please don't pretend like something is a common thing when it's not.

Re: Why ClojureScript Matters

#107

Post by KurtMueller »

straws wrote: post #47
javajosh wrote: post #28

Earlier quoted context omitted.

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…

Thanks for pointing me to his blog. He's a great read. Got anything else by him I should read/watch/listen?

Re: Why ClojureScript Matters

#108

Post by tomjen3 »

bryanlarsen wrote: post #65
tomjen3 wrote: post #61

Earlier quoted context omitted.

He is getting downvoted, and rightly so, because the person is replying to has clearly set up his system is such a way that some code runs on both the server and the client. Which is very reasonable, btw, as it allows you to have a static site that renders for those whoes browsers doesn't run javascript and a more dynamic page for those whoes browser does run Javascript. You are guaranteed that everything renders the…

We're doing that too, but that's the boring part. That's just running client-side code on the server. It's still client-side code. You can do that in Rails too. See my other comment for more details.

If you are running client side code on the server you use a very different definition of client side code than most other people, which is bound to be confusing.

Re: Why ClojureScript Matters

#109

Post by bad_user »

imsofuture wrote: post #101
bad_user wrote: post #42

Earlier quoted context omitted.

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

The danger of having people who aren't specialized is just as great as the danger of having people too specialized. Backend and frontend concerns are completely different, and it's fiction that you can simply wave those concerns aside and write the same sort of software anywhere in your stack.

I disagree and I think that treating the frontend and backend as different concerns is one cause for the big balls of mud we end up with. For example, many treat the backend as if it doesn't require design or taste for good user experience and many treat the frontend as if it doesn't require solid engineering. They are wrong of course.

Re: Why ClojureScript Matters

#110

Post by aidenn0 »

Kiro wrote: post #81
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.

> but the majority runs on both What does this mean exactly? What kind of code needs to run on both?

Aside from things like general libraries (e.g. serializing/deserializing data to/from the client), anything you want to happen client-side that you don't trust the client for, you will need to re-run on server side.

A simple one is validation of forms, but also doing rapid UI updates without having to do network round-trips.

Post reply on HN