This is so awesome. Much love to everyone at Facebook that has made this possible. With React, React Native, Rebound, GraphQL, Relay etc... You're saving us all from drowning in complexity when buiding web/mobile apps and I love it. Keep fighting the good fight.
Also, totally not okay with how FB mines data; they don't get a pass on that. Their OSS work is top notch, though. Now only if someone would take their own technology and beat them with it. A little guerilla warfare.
> People have been saying tech X saves us from complexity for decades (OOP, noSQL, Knockout, Angular, etc...), and after a few years of use we realize it's not actually a magic bullet.
Throughout all your years of education, you were challenged the same amount. Doesn't mean you weren't doing/learning more.
X did save us from complexity. We just, continually, keep writing increasingly complex things.
Yesterday's sites were rendered on the server, with all state stored on the server. Today's are rendered on the client, buisness state on the server and rendering state stored on the client. Tomorrow's will distributedly store all data on the client; Think bit-torrent + encryption + web-rtc. Day After sites will be rendered on the server again; because we are now working with extremely "complex" 3D hologramed Apps.
But, I disagree with your last statement:
> Day After sites will be rendered on the server again; because we are now working with extremely "complex" 3D hologramed Apps.
Data is data is data. When the problem of distributing, syncing and querying data distributed between client and server is solved, it is solved forever for all classes of application which are built on that paradigm.
This is true whether you're rendering a 2D web page or a 3D holographic image from that data on the client. There would never be a need to go back to server management of data or state - that's why leaps forward in this space, which React is and now Relay looks like it will be, are incredibly exciting and pull the whole industry forward.
I would suggest a more likely 'Day After' problem would be managing more granular distribution of data and state through networks of clients, i.e. apps built on the peer-to-peer IoT paradigm rather than today's dominant client-server paradigm.
I think we agree on everything. I was honestly just being coy with "Day After". I don't believe I can adequately predict tomorrow's complexity issues. I just picked something arbitrarily "complex", not really giving it much thought.
React does save time. Maybe you've not built sufficiently complex apps in which state has bitten you in the ass, which isn't a bad thing. From experience, before React it was a nightmare as soon as the first dependency issues arose (whether that's data loading, UI flows or component hierarchies).
React's fundamentals are in managing state via composition and functional-like declerative programming; it's hard to argue that any other frameworks take this clean, pure approach and really solved the problem.
With Flux, Relay/GraphQL and ES7's decorators it's easier than ever to build pure, stateless components that are drop-in replacements for Angular's controller hell, or Marionette's awkward controllers.
And it seems like you mean exactly the opposite of what you've said, based on that definition - you're not drinking the React Kool-Aid, or drinking the anti-React Kool-Aid.
I'm not trying to impose grammar OCD on anyone by any means. Like I implied, I'm probably one of the more ignorant people about these phrases. I just think it's confusing when people say things like "could care less" and "drinking Kool-Aid" when they actually mean the complete opposite. It's very bizarre to me but OTOH I guess it's fascinating that English is just that flexible.
Thanks. Nit-picking again, but drinking the Kool-Aid does mean "unquestioning, ... without criticism" implying that those who are drinking wouldn't have such reservations. That's what I was confused about. Oh well. Language is evolving, what else is new.
So it's not so much that they're praising highly in and of itself as that they're (implicitly) praising highly because they're buying the hype without questioning it, because it's not like they've used it in anger yet or heard 3rd party testimonials.
That said, he did use the phrase correctly, well, sort of. He was saying he believes in React, and then noted some caveats with people's reactions React. Which isn't properly "Drinking the Kool-Aid", but his meaning gets across.
Haven't you heard? There are tons of new JS framework being churned out annually, and each time it's hailed as the holy grail to all our problems.
Is Facebook also working with ClojureScript?
But inside the UI component you're really just defining the schema of the data to be returned from the server, you're actually implementing how to fetch that schema from the database somewhere else in your codebase.
Clojure 1.7 introduces a new file-type with extension .cljc that can load in both Clojure and ClojureScript. Which means you should be able to define both your React component AND the Server side implementation of the data fetching schema all from one file. Pretty frickin' cool if you ask me. One file, one component, that knows how to render itself, fetch it's data and serialize it's data.