Hacker News Reader

Comment by saosebastiao | Hacker News Reader

I love the concepts behind React, and I agree this is a huge deal...I just wish it weren't javascript. It is a terrible language, and the languages that compile to javascript are a poor substitute (bloated code sizes, interop issues, poor runtime performance, etc). For a framework that is all about state machines (a good thing! All UIs are state machines), I hate that there aren't better ways to model them in the language. I would kill to be able to do React in F# or OCaml.

View on HN

Pretty sure Om[1] for React Native is coming.

>bloated code sizes, interop issues, poor runtime performance, etc

I've heard about no such problems about ClojureScript. In fact there's less code size than you'd usually have because Google Closure Compiler advanced more works with it out of the box[2]. It's also fast because immutability.

[1]: https://github.com/omcljs/om

[2]: http://swannodette.github.io/2015/01/06/the-false-promise-of...

Om is fast at checking if a component's state has changed because you can do a very fast identity comparison on the persistent hash map holding state, but persistent data structures are not faster than their mutable cousins simply because of immutability. That immutability leads to significantly more objects being allocated, which means to really take advantage of these features in a managed language you need a VM with a very high performance garbage collector. This is partly why Clojure on the JVM works so well. That being said, non JIT compiled JavaScript VMs generally provide terrible performance for ClojureScript. I do not believe JavaScriptCore JITs anything, so I don't know how immediately useful ClojureScript with React Native will be outside of toy examples.

> That immutability leads to significantly more objects being allocated

What about shared immutable data structures?

Clojure uses structural sharing of course, but that was taken in to account in the parent comment. It's still a lot of allocation.

Fair points.

I like Clojurescript in general, but the code bloat problems and runtime speed problems still exist even with advanced optimizations. The big problem is that you have to use code that is Closure-compatible. If it isn't, there are hacks to make it work, but you end up killing the ability to remove dead code. And no matter what, you are going to end up shipping portions of the Clojure code as a runtime within the javascript runtime.

I have used cljs for non-mobile web interfaces, but the performance of Om in Phonegap on mobile hardware was terrible enough that I scrapped it for Xamarin.

First, all ClojureScript code is Closure compatible, you don't have to worry about that.

Secondly, Om in a Webview and Xamarin are not fair comparisons.

> It is a terrible language

As Douglass Crockford says, JS is a great language with some terrible parts. I don't understand why some people can't get past that.

Well, then. What about the language should make me think "wow, this actually is a great language"? And I mean the actual language itself, not the ecosystem around it.

With the exception of the bad parts that you have to remember to stay away from, it is a very simple language.

By definition, if I have to remember to stay away from the bad parts, it can't possibly be that simple.

Except that it's not.

Having many different parts by itself is enough to make a language bad. The fact that some of the most important of those parts are basic makes it terrible.

Because many people use the terrible parts.

Start shooting: http://funscript.info/

Have you given CoffeeScript a try? Bloated code size and interop issues are essentially nonexistent. Poor runtime performance is a non-issue with most C2JS languages because, well, they're compiled.

> I would kill to be able to do React in F# or OCaml.

Websharper (http://websharper.com/) for F# is now Apache-licensed and comes with the UI.Next framework that provides a really nice reactive paradigm for creating web UIs. Unfortunately it doesn't help with mobile apps as React Native does but is still pretty good.

> the languages that compile to javascript are a poor substitute (bloated code sizes, interop issues, poor runtime performance, etc)

js_of_ocaml has good code size and performance in my experience. Interop with js is variable -- some js libraries are inherently typed and are easy to bind to in a well typed way, others use very dynamic typing and those are difficult to bind.

You're probably looking for Elm - http://elm-lang.org/

That shouldn't be a big problem.

Since the JS execution is isolated on a single thread and communicates with the main thread via a bridge, it should be possible to implement the rendering code, vDOM diffing, bridge etc in any language you want. That might take some effort, but I can't see any fundamental reasons why it wouldn't work.

That's my concern as well. ObjC and Java both have weaknesses. I routinely think about what is wrong in the mobile frameworks (Activity is a god object, null is a pain in the ass in Java, the various lifecycles you have to constantly worry about...) but if anything JavaScript looks like a big step back.

There's js_of_ocaml?

I write React components in Coffeescript - no JSX. Concise, easy to read and write - just works beautifully.

I use CoffeeScript with JSX. It's even more easy to read and write. https://github.com/jsdf/coffee-react

Reply on news.ycombinator.com