Web devs will keep reimplementing parts of React elsewhere; but at least, be inspired by some other parts of React please.
Web devs will keep reimplementing parts of React elsewhere; but at least, be inspired by some other parts of React please.
So wannabe functional programming in JS ? I always wondered why Facebook didn't just go all-in on clojurescript when they did React, they have the resources to deal with any compiler/technical issues, heck they could reimplement the compiler themselves they already maintain a bunch of PHP VM/language stuff. It does everything react tries to do but better and by default.
You can take 'good parts' from functional programming without going 'all in'. Many of us don't agree that the 'all in' is actually better.
(See Gary Bernhardt's 'Boundaries' talk [0] for an amazing explanation of what I mean by taking the good parts of FP).
React isn't really about functional programming, it's very object-oriented. And where the parent comment refers to 'composition', they mean composition of components/view code, not pure functions as you may have interpreted it as.
Personally my dive into the Clojure community has been very frustrating, I find very few answers on how to actually compose large apps, and the answers I do find basically point back to OOP (but implemented in a syntax-less, ad-hoc manner [1]).
If I've got this wrong, please tell me, I'm dying for better answers.
[0] https://www.destroyallsoftware.com/talks/boundaries
[1] Stuart Sierra - Components Just Enough Structure - https://www.youtube.com/watch?v=13cmHf_kt-Q
Also you can keep that representation as datastructures, do operations on it to transform and diff it, no need for custom objects or what not. Updates are also really nice because clojure datastructures are immutable an mutation is already isolated in to special constructs. The OO aspect of React is just a sad consequence of JS - clojure has different ways to deal with polymorphism.
My impression is that all the stuff FB guys did (React, persistent data structures, unidirectional dataflow) already exist or are more natural in clojurescript than hacking it in to JS but I'm not the authority on the subject.
People (at least the ones I talk/work with) do understand the value of lisp. And I myself am a defender of that Hiccup-style syntax (https://github.com/facebook/react/issues/2932) and a huge Cljs fan. But judging from this comment and previous, it seems that you underestimate the value of getting work done in an already established environment.
Like they already have a JS preprocessor, have their persistent datastructures, etc. and have to deal with a lot of stuff they wouldn't need to deal with in a functional programming language.
> I always wondered why Facebook didn't just go all-in on clojurescript when they did React, they have the resources to deal with any compiler/technical issues, heck they could reimplement the compiler themselves they already maintain a bunch of PHP VM/language stuff. It does everything react tries to do but better and by default.
You're not correctly estimating the resources required. Every Facebook endeavor I've heard of was an attempt to keep their millions of lines of production code unchanged with the added benefit to have new code be better. (eg. PHP->Hack, Untyped JS->Flow, DOM Manipulation->React, ...)
That said, perhaps you're not familiar with these types of codebases and aren't quite grasping the magnitude of code change that would first be required for Facebook to go "all-in on clojurescript". If you haven't had the opportunity to participate in a codebase of that magnitude, there aren't really words to describe it to you. Just know its multi man years worth of effort. In practical terms its not possible because a business also needs to iterate and release new features.
Anyways, this sentiment has become popular recently for some bizarre reason. All of the things that are the "real strengths" are in fact only possible because of virtual dom. So in my eyes the virtual dom is the important part, as the enabler.