Hacker News Reader

Comment by modarts | Hacker News Reader

Honestly, at this point, since the JS community seems to have fallen back on just lifting all of the good ideas from the Clojurescript community, why not just go straight to the source and start learning some Clojure?

- You don't need to bring your own persistent data structure lib (ImmutableJS/mori/etc,)

- Don't need to bring a functional utility lib (lodash/ramda/etc)

- The build ecosystem revolves around a really solid piece of software in Leiningen (that has a ridiculously high level of adoption)

- Hot reloading (mainly through Figwheel) is simply magical (it's stable and "just works".) The amount of work to get a hot reloading environment setup and maintained with Webpack and various loaders is way too much, and often involves actual changes to application code to support it, which is unacceptable.

- The language itself is designed from the ground up to be functional

This is just what I can think of off the top of my head after a few glasses of wine, but there's a ton of reasons why we as JS developers should start taking a hard look at Clojurescript again.

View on HN

I was hired to write JS code on a team of people who know JS, by a company that is comfortable writing significant chunks of code in JS. If I try and check in some Clojure into our repo, I'll fail code review. If I suggest adopting Clojure on a new project, it'll be shot down. And for good reason; nobody here knows Clojure, we're not a Clojure shop, we don't even know the right questions to be asking about risks and issues of adopting Clojure, much less the answers.

If we were going to adopt a new language, I think I could make a solid case for Typescript that might get accepted. I could see making a case for Elm or Purescript, but I don't think either will fly. But Clojure is a lot further out there in terms of adding it to an existing team of PHP/JS/HTML/CSS devs.

In addition, while you note that the JS ecosystem is basically just playing catchup with Clojure, it is (slowly!) catching up. More to the point, ES6 is the future of browsers; we're using Babel and polyfills as a stopgap, but the code we're writing is code which is increasingly capable of running on the browsers on our dev machines. Clojurescript is, let's be honest, never going to be natively supported in Google Chrome. JS, as a language, is getting better, JS build tools are getting better, and the JS ecosystem is getting better. It may have a long way to go, and it may be slow, but it's getting there. From where I stand, the gap between JS and Clojure is just going to get narrower (it's always easier to copy than innovate after all). Why shouldn't I just wait and get the benefits for free?

(Disclaimer: I love the idea of Clojure, and I actively looked for Clojure/Clojurescript jobs the last time I was on the market. But what I found was a job writing ES6/React/Redux, which is almost as good as the hypothetical Clojure job, and has the advantage of existing.)

>Clojurescript is, let's be honest, never going to be natively supported in Google Chrome.

Not quite sure what you mean by this, but source maps, syntax highlighting and other native extensions were added by the Chromium team over the last year specifically for Clojurescript support.

But, as far as a language running natively in Chrome, none of the languages that transpile to JS do, not Elm, Purescript, etc, so I'm not sure what exactly you are referring to.

He is referring to the fact that his language of choice, es6, will be running natively in chrome, since it's just new javascript.

However, since ClojureScript transpiles to Js I don't really have to care about this do I. From my perspective Js is effectively bytecode.

<Rant>

I tried that for 6 months then went back to JS only to discover that within those 6 months Facebook and half of the React community had moved on to ES6, and even ES7, which meant that I just missed half a year of the most important phase in the evolution of JS. Great job, says me. I'm having to make up for it now.

What nudged me out of my love affair with CLJS is when I needed to implement a really simple async pattern in CLJS. Everyone pointed me to core.async (later on someone mentioned the cats library which uses monads etc) It didn't feel right to use core.async's syntactically and conceptually complicated CSP pattern to solve a truly simple problem that can be solved far more elegantly with a much simpler and more general pattern using ES7's async/await.

And now that we have decorators, typed data structures, iteration protocols and a myriad of other tools available to us in ES6/ES7 the only thing that is missing is NATIVE immutable types.

</Rant>

> What nudged me out of my love affair with CLJS is when I needed to implement a really simple async pattern in CLJS.

What? Async/await in CLJS is:

(defn async-fn [] (go true))

(go (<! (async-fn)))

How is that syntactically and conceptually complicated compared to async/await?

Why don't you go further and try/catch that to make it usable in a real app? How do you handle async errors?

Install an exception handler on the channel or return exceptions on the channel. The latter is more common. I've written my own macros to make the latter case pleasant (<10 loc), but I believe the go-catching and <? macros from glossop provide the same functionality.

(defmacro go-catching [& body] `(go (try ~@body (catch js/Error e# e#))))

(defmacro <? [chan] `(let [res# (<! chan)] (if (instance? js/Error res#) (throw res#) res#)))

Used like this:

(go-catching (<? (async-fn)))

Can you expand that to the concurrent scenario?

Show us how you implement this simple and very common concurrent pattern with ClojureScript. I've seen stuff that implement this in ClojureScript and it ain't pretty (to say the least) Impress me! :)

In ES7:

async function fAsync() {

try { var results = await Promise.all([asyncOpA, asyncOpB, asyncOpC]) } catch (e) { ... } }

impressed? :) https://funcool.github.io/promesa/latest/#error-handling

I couldn't find example in the docs for that library showing concurrent async ops with simple try/catch type error handling. So it's still not clear to me how you would rewrite the above shown async/await concurrent scenario using this library.

Just use promesa/all then catch :)

Moreover, it has funcool/cats bindings, so you can use promises in mlet and alet macros if you are into monad thing ;)

Oh right, that makes sense but does not make async code organize the way synchronous code does (as async/await sugar enables) but is a fair deal if you don't mind your async code using a different organizing pattern or if you specifically want it to be that way... :)

Re: cats

Not a big fan of abstractions that don't contribute to code simplicity. What is the percentage of programmer who dig monads? Less than 1% probably.

You're just cherry picking though. When it comes to complexity there's plenty more of it in Js than there's ever likely to be in ClojureScript.

I am biased. Just as you are.

Objectively speaking, Js is a far more complex language than ClojureScript.

It's a trivial matter to wrap promise/all in a core.async channel, providing the exact orginzation pattern you're looking for.

Show me the code! Go ahead and let's see how pretty that is, and son't forgeg error handling and concurrency.

I've provided all the code you need to put the pieces together quite trivially. Using go-catching, <? and the promise library (or just the core.async snippet I wrote earlier), you should be able to write the following:

(go-catching (<? (async-all [asyncOpA asyncOpB asyncOpC])))

And yes, that handles errors exactly like synchronous code does. The total number of lines for implementing go-catching, <? and async-all shouldn't take more than 20-30 loc, if not less.

Now, if 20-30 loc is too much for you to write, then by all means use JS.

So what you're saying is that you can't be arsed to spend 15 minutes to learn a library, but you're ok gobbling up all of ES6/7 without problems?

That's an argument plot, not a genuine question. :)

ah so just trolling then :P

From reading core.asyncs documentation, it sounds like this should do the trick:

(go (try (let [ops [asyncOpA asyncOpB asyncOpC]] (core.async/take (count ops) (apply core.async/merge ops))) (catch js/Error e ...)))

Where asyncOp* uses go-catching.

This is a really strange line of argument. While core.async is popular, nothing precludes you from using other libraries such as promesa https://funcool.github.io/promesa/latest/ that have semantics you seem to prefer.

Second, ClojureScript has great interop with Js, so there's absolutely nothing stopping you from using a Js library/feature if you so choose.

>And now that we have decorators, typed data structures, iteration protocols and a myriad of other tools available to us in ES6/ES7 the only thing that is missing is NATIVE immutable types.

It boggles my mind that somebody could see this as a positive. The biggest problem with ES6 is that JavaScript just keeps growing as a language. It has lots of features and quirks already, and more are getting added. This is what you end up dealing with when using ES6 + React (https://i.imgur.com/AjSTP20.png).

I think the problem with this is that it adds mental overhead when you're reading and writing code. Something that looks like it might be doing one thing does something subtly different. This leads to hard to debug errors and wastes you time. It also distracts you from the actual problem you're solving.

promise-a by itsef does not solve callback hell it simply turns it into a never-ending-chain-of-thens but async/await (built on top of promise) does make things easily comprehensible. How do i use async/await in CLJS? More importantly why shouldn't i use something like ESLisp if I am into lisp but want to work with JS features directly? Why would I want to mix JS with CLJS amd require everyone who maintains my code to know both? I'd recommend checking oit ESLisp on github, although they're still working on adding ES6/7 support.

To each their own Dimitri :) i gave up on CLJS after it was evident to me that JS is maturing and has copied a lot of the stuff I like from CLJS plus some stuff from C# like async/await. Haskell is cool and so is Elm but all of these will ultimately be copied in pieces by the most dominant language on the web (JS) so it's easier to be on the receiving end of all that goodness as opposed to being stuck in any of those niche languages. Appologies. It's just my opinion.

How is "never-ending-chain-of-thens" fundamentally different from async/await? It's still the very same code but with different (and somewhat disconcerting) sugar. I've been using promises long before ES7, and it's actually harder for me to read async/await functions and reason about them because they look so much like ordinary functions but aren't. There are useful features in ES6/ES7, to be sure: fat arrows, destructuring, imports/exports. Classes and spreads are useful too if you do a lot of React and JSX. But async/await, decorators and generators are just fancy and questionable ways to perform routine functional stuff one can easily do in shaggy pre-ES5 Javascript. I write a lot of ES6/ES7/JSX at work and CLJS at home and 100% prefer the latter. I want immutable values with destructuring, lazy sequences, suit of threading macros, decent cond|p/case, protocols and whole CLJS ecosystem. I've adapted to ES6/ES7/Redux/RxJS and often even could write code near-identical to CLJS/Reagent/Re-frame/Reagi stack. But it is definitely more painful and limiting experience.

Async/await doesnt lead to a long chain of thens with a trailing catch. It gives you proper synchronous semantics like any other synchronous code, while allowing you to specify concurrent logic. Its syntax is very understanable. You're missing out! I think you don't actually have a clear idea if you think async/await is a step backwards. You're arguing for the sake of arguin, right? Else, give me some examples in code. Thanks.

Perhaps you could instead provide an example of a concrete problem that you believe to be difficult to tackle with CLJS.

@yogthos

Nothing is hard to do in CLJS but finding the right way to do things can be hard. For example, why doesn't core.async include promises and even better some async/await equivalent? Why does core.async push CSP as the built in async model to the exclusion of all other async patterns? Why are those only found in some 3rd party libraries?

>Nothing is hard to do in CLJS but finding the right way to do things can be hard.

So you're saying that you have to learn the language and its ecosystem. Please explain how that's different from any other language.

>For example, why doesn't core.async include promises and even better some async/await equivalent?

Because it has different design goals.

>Why are those only found in some 3rd party libraries?

Because most people find the core.async approach to work well. However, since such libraries exist and have great documentation, I fail to see the problem.

In fact, not baking things into the language itself is one of the greatest benefits of Clojure. The language itself is minimal and makes very few assumptions. This means that it can be extended through libraries to many kinds of domains. The more assumptions the core language makes the more rigid it becomes.

The thing is many people try ClojureScript and end up leaving while many others do stay. I am in the former group and my reasons are exactly what i stated but you are right to point out that my reasons may not be everyone's reasons, which I never assumed. Hence the Rant tag. Fair enough, some people find use of CSP for simple scenario of concurrent wait-for-all async management a natural fit but i find it an overkill. Promises are fine but I find async/await syntax much more easy to understand.

I do hope CLJS stays a strong niche language but any hope of it taking over the world is unlikely, IMO.

I'm not saying that ClojureScript is for everybody. Obviously, different people like different things and that's why we have so many different languages available.

However, the reason that async/await is difficult to do in ClojureScript as the main reason for leaving it is a strange one. It's clearly still very easy to do, even if ES7 version might be slightly cleaner at the cost of being baked into the core language semantics.

When you compare all the things that are much uglier in JavaScript compared to ClojureScript, it's a bit of a silly argument to cherry pick async semantics in my opinion.

I wouldn't expect ClojureScript to take over the world either. It's obviously never going to displace JavaScript, but it's reasonable to expect that it will continue to grow in popularity and that anybody who wants to work with it will be able to do so professionally.

I didn't leave because of core.async being exclusively CSP. That was a big annoyance (and couldnt find the promise library) I left because ES7 and next year ES8 and year after ES9 are bound to give us what we need from a modern language without resorting to coding in a Lisp-like labguage, ClojureScript is extremely expressive but something about the Lisp form makes me spend too much time thinking about the code rather than the problem domain (product features) It does produce tight code so it is a better medium for expressing algorithms but I found that it moves my focus from thinking about features to thinking about algorithms (a strange attractor?) and in the end very few people (Lisp users mostly) will be able to maintain the code... So what am I doing writing a web app in a Lisp like language unless i really enjoy thinking about algorithms more than UX... What matters to me is having a good modern language with large enough eco system and that I could use to build kick ass UX. Modern JS and React-Flux-Immutable suffice. When i want to do heavy data processing I would probably miss ClojureScript and Clojure but the UI is not where I would want to do heavy data processing... I really thought about it based on all these factors and decided to jump back to JS. That was my choice. I don't expect it to be everyone else' choice...

>I left because ES7 and next year ES8 and year after ES9 are bound to give us what we need from a modern language without resorting to coding in a Lisp-like labguage

I'm not sure what that's supposed to mean exactly. I don't really understand what the "resorting" part refers to here. Clojure is a modern language with that has excellent syntax with tangible advantages over syntax found in most languages.

The syntax is very uniform and follows the principle of least astonishment well. The s-exps provide additional visual information about relationships in code making it more scannable. Finally, the syntax facilitates structural editing making it much easier to manipulate in the editor.

>ClojureScript is extremely expressive but something about the Lisp form makes me spend too much time thinking about the code rather than the problem domain

Perhaps that might have something to do with the fact that you've only used Lisp for 6 months, while you probably have years of experience working with Algol style syntax you're familiar with.

There's absolutely nothing inherent in Lisp syntax that distracts from the business logic. If anything, my experience is that it puts you closer to the business logic as there's a lot less syntactic noise.

>and in the end very few people (Lisp users mostly) will be able to maintain the code

That's completely false. My team has been using Clojure for the past 5 years and we've never had trouble hiring people to work with it. None of the people we've hired over the years had any experience with Clojure or even FP for the most part. The average learning curve to becoming productive tends to be a couple of weeks. We also hire co-op students every 4 months and all of them have learned the language quickly and enjoyed working with it.

A new hire doesn't have to become an expert to start doing useful things. Learning the basics takes very little time, and they can pick up new concepts as they need to. Personally, I wouldn't hire somebody who was unwilling to work with a new language as it implies the sort of rigidity that antithetical to the developer mindset.

> So what am I doing writing a web app in a Lisp like language unless i really enjoy thinking about algorithms more than UX

That's funny since ClojureScript provided the first environment for developing web apps where you could get instant feedback on the UI making it much easier to focus on UX.

Having a live environment with a REPL makes it much easier to experiment as it cuts down the time between making a change and seeing the effect. This is one of the greatest tools for being able to experiment with the UI and provide the a good UX.

>What matters to me is having a good modern language with large enough eco system and that I could use to build kick ass UX

This is precisely why I, and many others, use ClojureScript. If Js is your idea of a modern language I simply don't know what else to say here to be honest.

Again, if you prefer working with Js that's perfectly fine. However, your rationalization of that decision is flimsy at best, and really boils down to the fact that you'd rather use something you're more familiar with.

You are vested in Clojure/Script and biased toward it. Obviously you are biased due to the heavy investment you hve made. I see so many disadvantages in ClojureScript: Lisp is super small in terms of adoption. Lisp is like using an RPN calculator, for uber nerds not for everyone. Who will maintain my code? The few people I know who know ClojureScript? How hard is it to find a ClojureScript dev or anyone interested in working on it? Can my company hire hundreds of engineers who love it and are easy to replace if they leave. If you say yes then you are contradicting actual experience i have had and dismissing it due to shear bias, not based on objective facts and data-supported evidence. Clojurescript's biggest problem, however, is that it has people like yourself who want to shove Lisp Is The Truth down everyone else' throat which people like myself have no tolerance for :)

>Lisp is super small in terms of adoption

Sure, but that's not very interesting in and of itself. The question is whether there's enough of a community to make the language viable and whether you can get a job using it.

Thousands of people are happily working with ClojureScript today, and lots of companies make accommodations such as remote work.

>Who will maintain my code? The few people I know who know ClojureScript?

I've always found this argument very strange myself. My experience is that the language is usually a small aspect of what's involved in maintaining a project. You have to learn tools, libraries, and the architecture around the project. This tends to vary greatly place to place. Learning the language is just a small aspect of that and anybody who's not capable of learning a new language probably won't do a good job with the rest either.

So to answer the question, the person you work with and train to use the language usually. As I've already pointed out, I've trained lots of people to work with Clojure and it doesn't take long for people to become productive.

>How hard is it to find a ClojureScript dev or anyone interested in working on it?

Not very, lots of people apply specifically because they want to try a new language. Last guy we hired had prior experience working with PHP and C#, and never touched a functional language in his life. His reason for applying was precisely that he wanted to try working with Clojure. He finished his first project and put it in production in his first 6 months on the job with minimal supervision.

>Can my company hire hundreds of engineers who love it and are easy to replace if they leave.

The fact of the matter is that good engineers aren't easy to replace when they leave. This has nothing to do with their choice of language.

> Clojurescript's biggest problem, however, is that it has people like yourself who want to shove Lisp Is The Truth down everyone else' throat which people like myself have no tolerance for :)

I'm not shoving any truth down your throat, at no point did I suggest that you should switch back to ClojureScript from Js. In fact, I've repeatedly stated that you should use Js if you like it.

I'm just pointing out the fallacies that you're stating when you're fumbling to justify the reason you switched back. Something nobody asked you to do by the way.

You started out complaining that core.async is hard to use. When I pointed out that there's a promises library you pivoted to complaining that libraries are hard to find, even though it's the first result for "promises clojurescript" on Google. When I asked you what specifically was hard to do, you said that it's just "an argument plot", and now you've moved on to some vague notions regarding difficulty of hiring developers to work with ClojureScript.

Why don't you just say that the actual reason that you like Js better is that you're more comfortable using it. That's a perfectly fine answer.

Oh, yeah, it replaces that cumbersome

.then(() => doSome(thing)) with bare doSome(thing)

and

.catch(err => doOtherThing(err)) with catch (err) {doOtherThing(err)}

A breakthrough indeed!

I just don't see how's that fundamentally different and why one should have synchronous-like semantics for async operations.

Moreover I do a lot of RxJS and like stuff and it's perfectly normal for me to have async computations steps wrapped in functions. Luckily no one tried to "improve" JS syntax specifically for RxJS.

So I totally get async/await syntax and semantics but it forces me to switch mental context for no good reason and thus is useless and disconcerting.

And it's ridiculous to see this minor "feature" as a reason to switch from CLJS to ES6/ES7

You seem oblivious to the advantage of organizing your async code in the same manner you organize your sync code. But the bigger reason I gave up on CLJS (besides core.async and its CSP model being a ridiculous over kill for simple async management yet being the primary choice the language gives you out of the box) was that ES6/7 are advancing at a much rapid pace than all of those Compile-to-JS languages and no one I know in the JS world would want to program a web app in a Lisp-like language (it's like using an RPN calculator rather than a normal one to do your taxes) for advantages that are disappearing fast relative to JS.

The Extensible Web Manifesto embraces the Babel inspired iterate-before-you-approve spec development model and that just makes JS evolution go so much faster.

So there is no hope for any niche language to unseat JS, and staying with a healthy and growing mainstream standard is far more appealing to me than writing web apps in Lisp-like language that once was a great choice (compared to ES5) but is no longer in that position.

I hope ClojureScript continues to be a niche strong language but I'm really hapoy with the progress being made with JS as a language and ecosystem. Fatigue (what the article is about) is self inflicted IMO.

>promise-a by itsef does not solve callback hell it simply turns it into a never-ending-chain-of-thens but async/await (built on top of promise) does make things easily comprehensible. How do i use async/await in CLJS?

There's a long discussion here, which I'm pretty sure you're already aware of, on the tradeoffs:

https://groups.google.com/forum/#!topic/clojurescript/LBy0yi...

Each approach has its downsides, but clearly core.async and promises work just fine here.

>More importantly why shouldn't i use something like ESLisp if I am into lisp but want to work with JS features directly? Why would I want to mix JS with CLJS amd require everyone who maintains my code to know both?

Language semantics is why. ClojureScript has much cleaner semantics than Js and languages that provide syntax sugar on top of it. It's immutable by default, has clean and consistent syntax, and far less gotchas than Js.

Nobody actually mixes Js with ClojureScript. People write libraries backed by Js internally, but the users of these libraries don't have to know or care about that.

The real question is why would somebody want to learn the giant clusterfuck that ES6/7 constitutes when far saner alternatives are available.

> i gave up on CLJS after it was evident to me that JS is maturing and has copied a lot of the stuff I like from CLJS plus some stuff from C# like async/await.

Adding features to an already poorly designed language does not make it better. You end up with a giant kitchen sink language that takes inordinate brainpower to work with. We've already seen that this is a bad idea with languages like C++ and Scala. And no, you can't just learn a snae subset of the language, because sooner or later you have to deal with code written by other people.

If working with a giant quirky mess that looks like this https://i.imgur.com/AjSTP20.png is you cup of tea then who am I to stop you, but I certainly question that it's a rational choice. :)

I'm basically saying this. At work we've started to move from Ember to React over a year and a half ago, directly because of the work David Nolen has done in the space. And now we have Redux wrapping an Immutable.js map, and are trying to piece together the rest of the stack that is om.next. It would be wayyyyyyy easier and better and less hacky to just write clojurescript. Getting people on board is sadly super difficult

Any write ups why your team moved from Ember to React? Seems like the recent tenets of Ember coincide with Reacts's componentized architecture and one-way data. Also if you were able to convince the team to go from Ember to React, appears as though the opportunity to switch to clojurescript was there (although react is the hotness right now so convincing was probably easier).

Question (from a newbie): Why didn't you stay with Ember, now that it has a similar engine as React yet comes with a CLI tool and strong community conventions that get rid of any build tool frustrations?

I'll assume the main keywords are "one and a half year ago". Me personally, I like the fact that React is a library wheras Ember is a framework. React doesn't dictate how you code your program, while Ember does.

Also you don't really need to use a flux library or Redux if you're using Reagent, it's pretty much all set up for you.

I've been using ClojureScript/Reagent for about a year now and all this JS tooling talk goes way over my head, I haven't needed to use any tooling other than lein cljsbuild for a while now, and it's glorious. If the Clojure community / ClojureScript was more approachable to beginners I think ClojureScript would be taking over right now.

Honestly, I think it's more approachable than Js tooling for somebody who's not familiar with either. You can have a working ClojureScript project up and running in literally 1 step, and only have to install 2 things to do that:

Install OpenJDK: http://www.azul.com/downloads/zulu/

Install Leiningen: http://leiningen.org/

Create a new project and run it:

lein new reagent myapp cd myapp

lein figwheel

Once figwheel starts, you can edit src/cljs/myapp/core.cljs and any changes you make will be reflected live in the browser without having to reload the page. Now consider what you'd need to setup to get the same thing with Js/React.

I think the problem is that a lot of people are already familiar with Js and tooling around it, so integrating more tools piecemeal doesn't feel as hard as diving into a whole new ecosystem.

Lisp is just a non-starter for a lot of people. Maybe it's an irrational bias but it's also widely prevalent.

I think Lisp in all its flavors is in the same bucket with Haskell, i.e. not a language that will ever go mainstream but an important laboratory for exploring ideas that eventually trickle down into more mainstream languages.

Clojurescript is a case in point. Statistically its userbase is zero but it's been the source of several useful techniques.

The relative numbers of users to other languages are not really interesting. The question is whether there are enough people using ClojureScript for it to be viable long term and can you get a job using it.

The answer to both questions is a yes. There are thousands of people working with ClojureScript today and there are lots of companies hiring for Clojure/Script jobs at this very moment.

In fact, the demand appears to outpace supply resulting in benefits such as accommodation for remote work (https://www.reddit.com/r/Clojure/comments/3yhm7k/looking_for...).

Thanks to the irrational bias against Lisp you're also competing against a smaller pool of developers when you look for Clojure jobs. Seems like a win to me.

I've been hearing this argument since I was heavily into Common Lisp in the early 2000s. Personally I like lisps so I hope Clojurescript does establish a viable niche.

But it's not the case that number of users is irrelevant. If I commit to Clojurescript (or Haskell, or any other niche language), I'm cutting my prospective job market down by 95%+. This means fewer companies I can work with, fewer places I can live, and fewer gigs available overall. Some might consider the tradeoff worth it but I don't.

I didn't say that the number of users is irrelevant. There needs to be a minimum user base to make a language viable, however beyond that it's just tradeoffs.

While you might be cutting down the job market, you're also focusing on companies that are forward thinking, get to work with great technology, and get perks such as remote work. The most exciting part for me is that you get to shape the future of the ecosystem. Being on the ground floor of a new technology means that you get a lot of say in how it will evolve. For me the tradeoff was absolutely worth it, but I can understand how it's not for everyone.

Isn't Om Next built on ideas pioneered in Relay and Falcor, not the other way around?

To be fair, there's been quite a bit of cross-pollination, but the original surge in popularity for React came about because of the pioneering work by David Nolen to show how to fully unlock the promise of React's approach when coupled with immutable data structures and a functional mindset (Basically everything presented in the original version of Om.)

Reply on news.ycombinator.com