Hacker News Reader

Comment by AlwaysBCoding | Hacker News Reader

I'm totally cool with Facebook mining my data if their open source keeps up this pace. GraphQL + Relay are total game changers for structuring web + mobile applications. Code bases get cleaner and more reliable. Less data gets sent over the wire. Other cool libraries are going to be built on top of Relay (I'm pretty excited to see what can be done now with ClojureScript components in .cljc files).

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.

View on HN

So I'm drinking the React kool aid, anyway, but this stuff has hardly been out in the wild. 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. Again, I'm drinking the kool aid, but maybe we should slow down on the hyperbole. Unless there are reasons to believe that things really are different this time?

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.

At a more general level:

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

This is spot on.

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.

The distinction between client and server is already evaporating, with things like server-side dom bringing client functionality to the server and service workers bringing server functionality to the client. I expect the next generation of distributed databases will include the client into its storage layout. However, that will only make it more apparent that the fundamental problem of synchronizing state between multiple machines is an unsolvable one, thanks to the CAP theorem. By unsolvable I mean that the intuitive expectation of the user is an always available system that is completely consistent, and we know we can't give them that. I feel like we're heading into the data processing equivalent of the AI winter, where the wet towel of reality will dampen much of the hyperbole around p2p and IoT.

Fair points!

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.

s/coy/cute?

http://dictionary.reference.com/browse/coy

/embarrassed

Probably: s/coy/silly

I think you need to understand what the issues are with previous frameworks and why React is different.

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.

OT: At this point, I am so confused at what "drinking the Kool-Aid" even means. People on the Internet seem to use it for every meaning possible. I was surprised to see that it has its own Wikipedia: https://en.wikipedia.org/wiki/Drinking_the_Kool-Aid.

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.

I think his suggestion is that he is drinking the Kool-Aid while internally questioning whether it is a good idea for him to be drinking the Kool-Aid. Which, I agree, is sort of a contradiction, but a parseable one.

This makes more sense. He's basically saying, "I love this, but let's not get too carried away." I now see where that comment's coming from!

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.

It might not have been the original meaning but when you think of a cult member drinking the Kool Aid (that will kill them) they might be a true believer with no doubt in their mind, but they could also be someone who isn't sure but is being led by peer pressure ao on.

When you accuse yourself of drinking the kool-aid, (or discuss yourself drinking the kool-aid), it carries along a degree of self-recognition: "sure, maybe I'm drinking the kool-aid, but at least I realize it".

Every top-level comment so far has started about by saying that this is exciting and awesome. The rest of the comments are full of accolades. That is drinking kool-aid. And it's okay to do that. Now let's get back to our hacker roots and start tinkering to see if this carries any weight. Everything is a trade off in technology - so what are we gaining by using this? And what's the cost? Is there a clear benefit?

Thanks. So another definition of drinking Kool-Aid would be "praising highly" I suppose.

To "drink the koolaid" is to blindly place trust in or unquestioningly accept something (that could in all reality by a solo cup full of poison).

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.

I mean, this isn't like a kickstarter project where you have a nice video from some random person and nothing but blind optimism it can actually deliver. This is Facebook open-sourcing a library that has been in their production codebase for multiple years. It solves a specific problem that most developers are intimately familiar with, and has already been praised by people in the tech community who aren't officially associated with Facebook. It's ok to get excited about this :)

Yeah, I mean that's what I was saying I thought the definition was in my original comment. But taken the way the OP apparently meant it, it does mean something similar to "praise highly" or "very excited about." The meaning's evolved.

Still OT, but it is pretty crazy how language develops over time and usage. Different people seeing a word, observing its context, and reusing it in similar context (or a context that person perceives to be similar), and thus potentially changing the meaning of the word ever so slightly.

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.

He meant exactly what he said.

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.

Can you expand on what you mean by "what can be done with ClojureScript components in .cljc files"?

Is Facebook also working with ClojureScript?

Well the whole idea of Relay is to couple together the rendering logic of a UI component with the data fetching requirement of the component. So if you change the rendering logic of the component, the data that is fetched from the server will also change with it and you'll never be over/under fetching data.

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.

ClojureScript community is pretty close to React (see e.g. Om), and since React 0.13 supports plain classes, they can be written in CS. So FB itself might not be doing anything with CS but enables the CS community to work in the same ecosystem.

Reply on news.ycombinator.com