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

71–80 of 121 posts

Re: Why ClojureScript Matters

#71

Post by sgrove »

thiago_fm wrote: post #60
swannodette wrote: post #36

Earlier quoted context omitted.

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…

I also feel that Om is very complex. I'm sure I've spent over 20 hours trying to wrap my head around it but didn't manage to do anything. From the people that know it well, they all love it. But I don't seem to have the required knowledge to understand it. I feel somehow dumb by that. The docs aren't good also. After that, I've tried reagent for 30 minutes and ended up with a lot of progress and I'm currently writing…

Pairing with someone who's built a few Om apps should get you up to speed in no more than 45 minutes. I've done it a few times now, and it just takes a few examples, building some components, and composing them together.

Re: Why ClojureScript Matters

#72

Post by Touche »

emidln wrote: post #58
Touche wrote: post #44

One thing Clojure/ClojureScript desperately needs is an answer for progressive-enhancement.

No it doesn't. You can literally do the same thing you did with PHP in 2007 if you want to (have a controller that outputs xml to be transformed into jquery commands if an ajax call or renders html if not ajax). You could also do something less silly like share your templates (maybe via hiccup and its many cljs implementations or via enlive/enforce/kioo (or via Soy, or anything else really)). If you want to get reall…

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.

Re: Why ClojureScript Matters

#73

Post by Touche »

jeremiep wrote: post #56
Touche wrote: post #43

Earlier quoted context omitted.

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.

Creating an object and creating a closure both need to allocate memory in the VM, but the closure doesn't need to expose its internals the way an object does and therefore can be further optimized by the runtime. If you need to write performance critical JavaScript, then allocating new objects will be just as slow as creating new closures. In either cases you should allocate them ahead of time and then closures are s…

> If you need to write performance critical JavaScript, then allocating new objects will be just as slow as creating new closures.

No, it won't. This code:

   function createThing() {
     return {
       doSomething: function(){}
     };
   }
Performs much worse (at scale) than this code:

   new Thing();
And it consumes a lot more memory since Thing.prototype.doSomething is 1 function in memory and the former is N functions.

Re: Why ClojureScript Matters

#74

Post by outworlder »

spion wrote: post #48
outworlder wrote: post #35

Earlier quoted context omitted.

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.

Perhaps a better term would be "popular"? As in, what's in use by Java and C#.

Re: Why ClojureScript Matters

#75

Post by reitzensteinm »

rubiquity wrote: post #67
jeremiep wrote: post #17

Earlier quoted context omitted.

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.

I think trying to write your apps in this way hides the underlying client-server architecture.

I've written a clj/cljs app with source sharing, and there are many downsides. Tooling, lack of progressive enhancement, debugging, download sizes.

I feel the benefits are worth it for my use case, but it's not all roses.

But hiding the client server architecture is just a bizarre criticism to me, because it's not at all what writing one of these projects is like, and I'm not sure how you're even getting that impression.

The degree to which you share code depends on how much functionality you are replicating, and is code that you would literally be cut paste porting if you were using another toolset. Or just avoiding writing altogether, like speculative updates.

Just because you can theoretically attempt an antipattern doesn't make a tool bad; you can write shit in any language. And many do.

Re: Why ClojureScript Matters

#76

Post by emidln »

Touche wrote: post #72
emidln wrote: post #58

Earlier quoted context omitted.

No it doesn't. You can literally do the same thing you did with PHP in 2007 if you want to (have a controller that outputs xml to be transformed into jquery commands if an ajax call or renders html if not ajax). You could also do something less silly like share your templates (maybe via hiccup and its many cljs implementations or via enlive/enforce/kioo (or via Soy, or anything else really)). If you want to get reall…

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 node provides.

As an aside, isomorphic isn't a new anything. We were rendering pages on the server, rendering updates on the server with the same templates, sticking them in xml representing jquery dom manipulation, and pipelining those in a single request since at least 2007 (when I first encountered the technique and shipped with it, I believe we used a javascript library called Taconite, maybe since 2005 from looking at the sourceforge account). Progressive enhancements were rendered off the same templates and inserted asynchronously, automatically, based on whether the controller on the server detected it was an ajax request or a bare GET. This incidentally made things very cacheable.

Re: Why ClojureScript Matters

#77

Post by serve_yay »

I notice the author employing a bit of jiu-jitsu I see sometimes -- basically, that you shouldn't worry about designers not understanding ClojureScript (or whatever), because that is insulting to the designers.

But how about designers have 18,000 other things to deal with and maybe they aren't interested in learning (in their estimation) the latest wacky-ass way web developers invented to generate HTML. The point isn't that they couldn't understand it if they tried, the point is that they would have to try, perhaps to the exclusion of something they would consider more useful.

Re: Why ClojureScript Matters

#78

Post by chowes »

smrtinsert wrote: post #62
chowes wrote: post #59

I've come to appreciate some of the new ES6 features (anonymous functions, lets) much more after using their equivalents in ClojureScript. Also, The interactive REPL based workflow that a lot of the LISP languages utilize is extremely appealing. I've been thinking a lot about how to bring this back into the JS world. I have yet to find any good literature on it, but I will be exploring this area more. For those curio…

Honestly this is the part I hate most about Clojure. The tooling is always so convoluted to setup and by the time you start your next project something has changed again, requiring more changes which might break your tool chain. ClojureScript is especially guilty of this right now with all the recent repl changes. I appreciate the The CS team trying to work with 3rd party repl developers right now, but it doesn't see…

Have you looked into Mozilla's SweetJS? I haven't had enough Clojure experience to get into something where macros would prove useful, so I'm wondering if utilizing macros in Javascript (which I'm much more comfortable in) would be worthwhile.

Re: Why ClojureScript Matters

#79

Post by KurtMueller »

thiago_fm wrote: post #60
swannodette wrote: post #36

Earlier quoted context omitted.

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…

I also feel that Om is very complex. I'm sure I've spent over 20 hours trying to wrap my head around it but didn't manage to do anything. From the people that know it well, they all love it. But I don't seem to have the required knowledge to understand it. I feel somehow dumb by that. The docs aren't good also. After that, I've tried reagent for 30 minutes and ended up with a lot of progress and I'm currently writing…

I'm learning clojurescript in addition to (eventually) learning Om. I feel like Om provides you a lower level of abstraction than Reagent which is good for building some complicated web apps. However, as a CLJS beginner, Reagent and the re-frame framework have been easy to dive into.
Post reply on HN