Comment by spion | Hacker News Reader

Comment by spion | Hacker News Reader

Quite amazing. This talk is not just about Om Next - its also about ClojureScript.next. Featuring:

  1. AMD, CommonJS, ES6 module support
  2. CLJS in CLJS (yup, that works - including the standalone nodejs based REPL)

Thise in combination are especially huge.

With core.typed being an option as well (once your system starts growing and the design solidifies) looks like the clojure ecosystem is really positioned to be one of the technically strongest available for web development.

And of course, replacing that awkward REST mess seems painfully obvious now (except for duplicated data which seems like something that might yet need solving). Hindsight is 20/20

Does 1) mean we can make use of advanced optimizations (like dead code elimination) on libraries written in one of these formats without any additional configuration?

If so, that would resolve what I consider to be one of the biggest barriers for CLJS/JS interop.

I'm pretty sure the answer is yes. I watched the video a few hours ago, but I think I remember him saying that.

Of course, just like the current state of affairs, your library has to not thwart advanced optimizations (using eval, accessing properties by strings, etc).

Yes, that’s what swannodette said in the talk. Skip to 33 minutes, or see https://github.com/clojure/clojurescript/wiki/Google-Summer-... and the blog posts at https://mneise.github.io

Are you aware of any performance benchmarks? Do you pay for the clojure abstractions?

An old talk (2012) so I'm not sure how accurate it is now, but Nolen discusses performance of ClojureScript. At the very least, you know someone cares and is thinking about it.

http://www.infoq.com/presentations/ClojureScript-Optimizatio...

I felt like it was all over the place. I am not sure if I really care about all the people who are using graphql like syntax for data retrieval, I am not interested datamoic, falcor ect.

Reply on news.ycombinator.com