David Nolen

I completely agree. When viewed from the right angle almost everything is a combination of some "VM bytecode" and a "compiler" targeting that bytecode. Greenspun's tenth rule applies to anything large enough. That's not what I'm getting at.

What I'm getting at is that when you have a bunch of problem solvers well versed in programming language design and theory the programming language at that point is no longer relevant. Standard Chartered doesn't have all that software because Haskell somehow gave them superpowers. Standard Chartered has all that software because a bunch of PhDs chose Haskell to write it in and along the way Lennart wrote another compiler because why not, the man is good at it. So instead of being a case study in how to apply a functional language to solve problems this is really a presentation about what kind of people you want to hire to build systems, i.e. PhDs, MScs, and MDs (apparently).

Imagine if the title of this post was "PHP in the large". Would anyone take it seriously? Does anyone really believe PHP is a great language to build large systems in? No, everyone would immediately jump on the fact that all of it is running on HHVM and there are bunch of smart folks optimizing the hell out of it. Same here.

The metapoint here is really a quote by Rich Hickey from a David Nolen talk/blog post - "Not everything is awesome". There are few hidden gems in the presentation when concessions are made by including Any type and re-inventing a lot of Erlang…

I agree that it sucks when the "worse" technology wins, but your points on why React is an example of one of these "worse" technologies are seriously misinformed regarding its shortcomings and have largely glossed over some of its most significant merits over existing technology.

> React seems to be designed to ignore 40 years of accumulated software best practices.

Best practices in software is not set in stone. Sometimes you need to break from existing best practices of the past in order to arrive at truly powerful new approaches to solving problems that may not seem intuitive at first, but eventually manage to redefine best practices through their technical merits.

The Virtual DOM and re-rendering on every change is one such approach popularized by React, but it's definitely not the only one, nor is it even the most significant one, in my humble opinion.

Before React, mutable models was the only game in town. Angular imposed mutable models, Ember imposed mutable models, Backbone imposed mutable models, your average custom ad-hoc JQuery framework probably also imposed mutable models. Everyone blindly followed this "best practice" simply because this was the status quo ever since the earliest days of UI development.

React is the first JS UI framework that does not impose a mutable model. And as a result, the ClojureScript community was able to build on top of it and show the world that change detection can be implemented as a constant-time reference comparison when…

They use a mostly functional subset of javascript (You are not allowed loops). It is much more readable than scheme if you ask me but not necessarily more powerful. You get the benefits of the very powerful and ubiquitous javascript compilers that exist nowadays which I like.

I played with it and you are somewhat limited right now. The first issues is that you quickly hit the top of the javascript stack because of the recursive style (remember: no loops). The most elegant solution to that would be for browsers to support tail call optimisations which is in the ES6 standard (Are you listening Mozilla or Google? If you implement this part of the spec sooner you could be leading the way for the most promising area of AI and maybe of computing in general). Although there are possible work around namely if the webppl compiler were to use trampolines or "promise" like structures. IMO, it would clutter the code and be much less elegant than native ES6 TCO.

The second limitation is that you are not allowed mutability. There is a git branch with support for mutability partly implemented. I'm not sure they should go that way though. I've never really been into functional programming style but in the case of probabilistic languages, I really see the value. It's much simpler and easier to follow what is going on when debugging. Supporting mutability also makes the compiler more complex and memory usage high as you have to copy the whole memory footprint of your program at each…

This is definitely some impressive performance. In Firefox 24 the core.async example is significantly faster than When.js on average (though in repeated trials, the running times vary over wide (and overlapping) ranges).

Some commenters seem to assume David's point is "use core.async because it's faster than promises". I don't think so. My takeaway from this post is that, having been persuaded core.async is awesome and will give me joy as a programmer (and see David's other posts for evidence of that, e.g. [1]), performance concerns should not prevent me from going for it, because it's competitive.

For me personally, Clojure and ClojureScript still have a long way to go to catch up with JavaScript-based development using Node.js and say, Angular. A smaller community, fewer libraries and less mature tools makes it kind of a bummer from a social perspective. I'm also not impressed with the Clojure/ClojureScript code-sharing story, which requires hacks[2] to use the same code on the client and server. Here, Node frameworks like Derby[3], which emphasizes sharing nearly all your code, and Airbnb's Rendr[4], seem light-years ahead.

But when you consider that this is an early release of a language and async lib written by a surprisingly small team, with basically no corporate backing, it's a pretty amazing accomplishment. I love ClojureScript in theory and I'm eager for the day when I can love it in practice too.

[1]…

Since this thread/Clojurescript is getting some love I'd like to express something to a hopefully receptive audience:

There was a point where Clojurescript and Javascript sort of walked hand-in-hand during the advent of when React started to make sense in the minds of the community[0].

It felt really exciting because of the cross pollination that was happening between the two languages, Redux felt very familiar, and we have re-frame for clojurescript.

There was a ton of promise with Apollo.js and an improvement on the `connect` functionality by upgrading to a proper query language for getting state into a component versus wrapping functions around multiple `state.some.path` `state.some.other.path`.

David Nolen built om.next around that very idea, it was basically Apollo.js lite, and it was very exciting scientifically but never quite caught on because maybe it was a little clunky. But using datomic pull query syntax to fetch state for use in a component was thrilling. (if you got this far and decided you hate me and your eyes are rolling so hard I get it lol)

And this was all years ago now. All that excitement and progress and effort seems to have been trapped inside of Typescript, and React hooks, and did everyone forget?

0: https://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/

I recommend reading swannodette's The Future of JavaScript MVC Frameworks[1], which was the article which first got me to try React, after earlier passing it by. This meant I was coming to React via good examples of how to use it in an optimisable way, already thinking about reference equality of the props I was passing, and whether changes within state object structures were observable in my application (mutation vs copying etc).

Now that React has had a large recent influx of new users, hopefully these key concepts are not lost in the deluge of new blog posts and demo applications. Those who are championing React within groups and organisations should try to make sure developers who are more passively following are made aware of such useful ideas. Javascript (and software engineering in general) has a long history of collectively forgetting important ideas only to rediscover them later, but it would be better to be proactive than to leave it up to the archeologists.

[1] http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/