5 ms·

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

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.

danabramov 12y ago
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 https://github.com/omcljs/om [2]: http://swannodette.github.io/2015/01/06/the-false-promise-of-javascript-microlibs/ http://swannodette.github.io/2015/01/06/the-false-promise-of...
- saosebastiao 12y ago
  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.
  - Touche 12y ago
    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.
- adrianm 12y ago
  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.
  - danabramov 12y ago
    Fair points.
  - amccloud 12y ago
    > That immutability leads to significantly more objects being allocated What about shared immutable data structures?
    - tree_of_item 12y ago
      Clojure uses structural sharing of course, but that was taken in to account in the parent comment. It's still a lot of allocation.
driverdan 12y ago
> 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.
- recursive 12y ago
  Because many people use the terrible parts.
- marcosdumay 12y ago
  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.
- pdpi 12y ago
  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.
  - woah 12y ago
    With the exception of the bad parts that you have to remember to stay away from, it is a very simple language.
    - pdpi 12y ago
      By definition, if I have to remember to stay away from the bad parts, it can't possibly be that simple.
tel 12y ago
There's js_of_ocaml?
andyl 12y ago
I write React components in Coffeescript - no JSX. Concise, easy to read and write - just works beautifully.
- martco 12y ago
  I use CoffeeScript with JSX. It's even more easy to read and write. https://github.com/jsdf/coffee-react https://github.com/jsdf/coffee-react
rattray 12y ago
Start shooting: http://funscript.info/ 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.
mands 12y ago
> I would kill to be able to do React in F# or OCaml. Websharper (http://websharper.com/ 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.
cwp 12y ago
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.
lpw25 12y ago
> 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.
sanatgersappa 12y ago
You're probably looking for Elm - http://elm-lang.org/ http://elm-lang.org/
on_and_off 12y ago
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.

danabramov 12y ago

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 https://github.com/omcljs/om [2]: http://swannodette.github.io/2015/01/06/the-false-promise-of-javascript-microlibs/ http://swannodette.github.io/2015/01/06/the-false-promise-of...

saosebastiao 12y ago
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.
- Touche 12y ago
  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.
adrianm 12y ago
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.
- danabramov 12y ago
  Fair points.
- amccloud 12y ago
  > That immutability leads to significantly more objects being allocated What about shared immutable data structures?
  - tree_of_item 12y ago
    Clojure uses structural sharing of course, but that was taken in to account in the parent comment. It's still a lot of allocation.

driverdan 12y ago

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

recursive 12y ago
Because many people use the terrible parts.
marcosdumay 12y ago
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.
pdpi 12y ago
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.
- woah 12y ago
  With the exception of the bad parts that you have to remember to stay away from, it is a very simple language.
  - pdpi 12y ago
    By definition, if I have to remember to stay away from the bad parts, it can't possibly be that simple.

tel 12y ago

There's js_of_ocaml?

andyl 12y ago

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

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

rattray 12y ago

Start shooting: http://funscript.info/ 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.

mands 12y ago

> I would kill to be able to do React in F# or OCaml. Websharper (http://websharper.com/ 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.

cwp 12y ago

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.

lpw25 12y ago

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

sanatgersappa 12y ago

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

on_and_off 12y ago

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.