The managers of this hedge fund handed over $100 million dollars in other people's money without so much as a whiff of due diligence.
There are 13 major life sciences venture capital firms and not one of then would touch Theranos with a ten foot pole. You'd think, in theory, that whomever it was at Partner Management LP who makes the big investment decisions would make a few phone calls first before deciding to pull the trigger.
Startups making bold promises about unproven technology are a dime a dozen.
>I think humanity is literally evolving to lie and cheat at a biological level.
It's naive to think we were not already born with these core qualities. "Survive at all costs" is a demonstrated maxim that all living beings possess. We didn't consider lying and cheating to be frowned upon until we decided we were a civilized society with rules based on [opinions | deities | etc.]. Having experienced multiple pathological liars firsthand, it makes more sense that rather than "evolving" these qualities, people are resorting to their core human nature as they feel more and more threatened.
> We didn't consider lying and cheating to be frowned upon until we decided we were a civilized society with rules based on
Eh, what? Where are you getting that from? Any organism with cooperative dynamics also has to contend with cheaters, and yet cooperation is extremely prevalent in nature. There's a reason parasitism isn't considered the norm in the animal kingdom.
I sincerely doubt that primitive human tribes widely tolerated healthy adults who contributed absolutely nothing to the group.
> I sincerely doubt that primitive human tribes widely tolerated healthy adults who contributed absolutely nothing to the group.
It's certainly not hard to imagine that no, they would not have tolerated such behavior. But does this mean that you are suggesting the members of this tribe convened and decided to put rules in place to define a member's behavior and potentially institute punishment if these rules were broken? That sounds suspiciously like a society. It's almost as if the larger population felt that attempting to hinder a particular perceived flaw in human nature was a net positive for the group as a whole.
The existence of cooperation or the desire to cooperate does not disprove that cheating and lying are embedded instincts in living beings. Cheating and cooperation are not mutually exclusive concepts. The parent comment was suggesting that we are somehow evolving to lie and cheat and I'm suggesting that we have been more than capable of this behavior all along. In fact, I've gone so far as to say that not only were we immediately capable since the dawn of humankind, but we have actively suppressed these "survival skills" because they are deemed bad qualities.
> But does this mean that you are suggesting the members of this tribe convened and decided to put rules in place to define a member's behavior and potentially institute punishment if these rules were broken?
No, although I could trivially say that any group of humans living together will be a society in some respect (and thus "natural" human behavior involves being in a society anyway).
Ignoring that, though, removing cheaters doesn't need to involve any sort of centralized group decision making. Your immune system doesn't convene and decide what kind of foreign bodies are unacceptable, and it's largely effective at what it does.
> ...does not disprove that cheating and lying are embedded instincts in living beings.
Sorry, the burden here is on you to prove that cheating and lying are embedded instincts (which I'm assuming means "typical in primitive humans" here). You're the one who made an affirmative statement.
My counterpoint is that cooperation is plentiful in nature (with many examples of cooperation in comparison to parasitism) and thus cheating is unlikely to be typical behavior in the wild.
You need to prove otherwise.
> Cheating and cooperation are not mutually exclusive concepts.
Are we defining cheating differently? What's your definition of cheating?
> The parent comment was suggesting that we are somehow evolving to lie and cheat and I'm suggesting that we have been more than capable of this behavior all along.
Humans are capable of any type of behavior. If your definition of "embedded behavior" is "humans are capable of doing that," then sure, it's trivially true because humans are numerous and any type of behavior can be found with such a large population.
> but we have actively suppressed these "survival skills" because they are deemed bad qualities.
Right, and my argument is that they're primarily suppressed because they're inferior survival skills in aggregate. Cheating and lying are classic "tragedy of the commons" behavior.
I wouldn't say that we've evolved in some way to lie and cheat more. The wikipedia page on the subject[1] covers the fact that such things exist in cooperative groups in nature and mitigation techniques exist.
Instead I would argue that 'cheating' behaviors are rewarded by some current economic and taxation models (tax loopholes that are created and used by already wealthy individuals to avoid taxation, rewards for destroying jobs only to increase profit, rather than avoid loss).
One can even look at American culture, and see how too often the value of a human is derived from the amount of wealth that they have. I'm not suggesting that all Americans do this, I'm simply suggesting that it's something that underlies so many arguments against taxing the rich and helping the poor; that the position that they are in is due to some kind of karmic result.
So, instead of saying that these are new, I'm arguing that we've just begun to reward behaviors that work against the cooperative goals of society.
I'm a Rails developer. I work on pretty standard web apps for a living. Some more complicated than others, but still, web apps.
I still haven't found a person that was able to give me a concrete reason why someone like me should invest time and resources into learning React and using it in my projects.
This is an honest question, I'm not trying to be sarcastic. It's just that there are so many frameworks that come out that it's very hard to know where to invest your time.
I understand your dilemma very well. I have experience building server-rendered web apps, web apps enhanced with jQuery, Angular apps, and React apps. I resisted React for a while, but I'm glad I finally tried it out. Compared with jQuery or purely server-rendered apps, React elevates what you can accomplish within a short time frame. A complex web form with async validation, client side calculations, and multiple branches can be a real pain to code as a server-rendered web app or using jQuery, but React uses a different abstraction that makes a lot of code easier to reason about.
React achieves that with the virtual DOM concept. On the initial render, the virtual DOM concept is nearly equivalent to the kind of HTML templating you're familiar with; you simply render a document with some substitutions. It's what comes next that's interesting: when you need to change something on the page (for example, when you need to display validation feedback for a form field), you don't add code that finds the DOM element and changes it. Instead, with a virtual DOM, you re-render your components with new data, and the virtual DOM figures out what changed and applies the changes. Event handling is much simpler.
React has only a few concepts; once you get it, there's only occasionally a need to read the React documentation. Angular is also powerful, but Angular has many concepts and I found myself referring to the documentation for every little thing. That may have changed with Angular 2.
EDIT: I should also point out that React adheres to the idea of putting HTML tags in code, rather than putting code in HTML tags. For simple templates, it doesn't really make a difference, but for some of the whopper HTML templates I've written before, putting HTML in code (aka JSX) would have been a major benefit. There are plugins for editors like Sublime Text that make JSX smooth.
React only needs a render method, not a render method and an update method for every state transition. Without the virtual dom this would destroy performance, so it is a rather key detail in understanding React's appeal.
FWIW we are trying to avoid "virtual DOM" in the new docs. The thing you create in render() and that describes the tree has been called "a React element" for many versions by now. "Virtual DOM" was more of a marketing term and I find it misleading because it doesn't make sense with e.g. React Native, and also makes React seem like a performance trick. React is not a performance trick. That elements get compared by React DOM renderer is its implementation detail. React is abstraction for dividing UI into predictable pieces, not a performance optimization.
If I wanted to do what React does, but without React, I might start like this:
document.innerHTML = myComponent.render();
That way, I can write components similar to React components and it can render very quickly. However, this strategy would work only on the initial render, because this naive strategy would destroy implicit DOM state like scroll positions, focus state, and cursor selections. The React DOM renderer (formerly known as the virtual DOM) lets me apply this rendering strategy without ruining implicit state.
The DOM renderer does not give me components or performance, since I can already achieve those things with raw Javascript. What it gives me is the ability to use a simple, clean rendering strategy without destroying the DOM state. That's why the React DOM renderer is not just an implementation detail.
For me, once I started declaring my UI as a series of components that simply render what they are provided (the common `v = f(d)` expression), it was hard to go back to the Backbone/jQuery way of mutating things all over the place and manually updating DOM nodes to try and reflect the current app state.
For view/UI, yes (if you can call React a framework). I personally do not use jQuery anymore as there is not much need to deal with the DOM directly when using React and when there is, I just use vanilla JS.
Since React only deals with UI, I use it alongside a bunch of other great libraries such as Redux (for state management).
The backend where I work (Airbnb) runs on Rails but most of my projects use node on the backend since they usually just expose a REST API.
Since it only cares about UI, React is obviously not opinionated about your backend/server environment unless you're trying to do server rendering (then you need something in your stack capable of executing JS).
I've spent some time looking at the 'needs a JS runtime' part and am prototyping an isometric framework in rust which renders with natively compiled code on the server and generated JS on the client, both generated from the same source template and logic. The JS can also be cached and served statically.
The server-rendered page is then instanced in the browser and differential rendering can be performed. I have been interested in doing this concept using React but have decided to prototype with a simpler implementation called Incremental DOM.
Nice. I was always wondering why no one was trying to do isometric stuff in other languages since every language and their mother seem to have a compile-to-js feature.
consider a complex submission form with updating state
eg you want to show uploaded images while editing parts of it etc
the realistic case:
if you have a rails app and do frontend "interactive stuff" you end up w/ some js frontend framework - let's say backbone - or even if it's just jquery send as ejs - you will have some sort of dynamic updates, maybe even frontend duplication of templates, you will add classes to places and interact with parts of the page, other people will add more features, some parts of the feature gets removed, that part of it moved to another site, to keep it working you need a certain setup on the page, etc et
pretty soon this gets complex - this is where react shines
reasoning about the frontend is easy because you think in components and in state. not in ui and the interactivity with it over time.
tl;dr: react can help for either a by design complex part of your frontend or your frontend becomes complex over time
it does not help for fast prototyping or small apps imo
"it does not help for fast prototyping or small apps imo"
I can understand this sentiment---React really is meant for serious apps. There is a decent learning curve. There is small overhead. And though it now only requires just a tiny bit of setup thanks to create-react-app, it might easily require a very significant change to workflow habits. (And the fact that CSS is still held by some as an ideal way of maintaining UIs rather than a temporary requirement given what browsers can consume in 2016 is a testament to how how hard habits can be to change. But I digress!) If you're not already knee-deep in it, React is almost certainly overkill for a marketing page or a mostly static form-y interface for some rails backend.
But just to give an alternative opinion: I think React is great for prototyping. The big reason is that React allows you to easily build and use custom abstractions. When you get down to it, that's sorta the whole point of the library.
If you need to do something---maps, a text editor, a flipping clock---there's a decent chance a catalog like js.coach will already have a React component for it. And at just a single line import away, unlike old jQuery "imports" which typically required more setup which then was more fragile once you wanted to make a change somewhere else (like, you know, renaming an id).
And over the years, like many others I'm sure, I've evolved my own toolkit which happens to be perfect for prototyping. I can vertically align <Rows /> and <Columns /> just by passing "center". I can add a modal simply by typing <Modal isOpen={isProfileVisible}><Profile /></Modal> right next to the button which opens it. I can add data persistence and real-time updating mostly just by typing <FirebaseWrapper /> and tweaking some config for the new app. I could go on and on. And these are just little personal things which make life a little easier. There's also projects like react-flip-move which smoothly animates transitions in a line of code, react-sortable-hoc which gives, in a line of code, a sortable with pretty good touch support and essentially infinite lists......
Obviously in principle you can get these benefits in other frameworks. But React is one place where lots and lots of people are actually contributing to the ecosystem.
I'm still somewhat scarred from the time I invested a ton of time into Angular.
Not sure you would be able to answer this, but is React something that works well with Rails out of the box? For instance, I found that Angular (when I was learning it) required a fair bit of shoehorning to get it to work well with rails.
Angular and React are like black and white when we talk about time of learning.
Simply because :
- Angular is a full framework including html templating, directives, components, controllers, services, router, xhr abstractions ($http and $resource), dependency injection, two-way data binding by default, one-way data binding if you want (to fix performance issues) and the list can continue. Plus, you need to set and learn a style guide [1] and some good practices because, if you have 2 developers, none of them will code in Angular in the same way.
=> it took me weeks to learn, and months to master.
- React is just a library to build views. You code 90% of your time in basic JS and 10% in React APIs (basically: states, props, lifecycle methods and that's it).
=> it took me 1 hour to learn, and 1 week to master.
If you want to learn React, you just need to read the official tutorial [2].
This is pretty misleading as a comparison, yes you can learn React itself very shortly, but the ecosystem around it will probably bring you much closer to Angular learning times, and that's also without the AngularJS documentation which is top notch.
I prefer React to AngularJS but I don't think it's fair to tell half the story when comparing them.
I'm working on an app for work that's a Rails API backend with a React front end. This stack is a pleasure to work with, once you get past the initial bits of setup.
With React I use Redux for state and ES7 bits for async and await. Productivity is high.
I was in quite the same situation, Angular 1.x was quite hard to grok at first. But React just "clicked" instantly.
For integration with Rails, I found https://github.com/reactjs/react-rails to be quite useful. It integrates the Babel transformer for JSX into the asset pipeline and brings a couple of helper functions, so no additional setup needed.
You start writing your components, "mount" them via the helpers in standard .erb templates (or even without the template directly from a controller action), done.
React in its basic form is pretty simple, you'll grok it in a couple sessions of playing with it. And since it's 100% view, you can fit it over pretty much anything.
This is assuming you're prepared to do rendering in the browser. If you want to do server side rendering I think you'll be doing more shoehornig :)
When you separate the web app from the server and build it as a stand-alone React codebase, you can create applications that run in the browser, iOS, Android (via Cordova / reapp) and cross-platform desktop operating systems (via Electron).
Now wait a minute, you're going to say, I can do all of that with my server-side web application. And faster too. Sure, but does your application work when the user is offline? Does it have access to the client runtime's local storage for data persistence? Can it access client hardware like the camera, GPS, and accelerometer? Can it be distributed through Google Play and the Apple App Store? Can it be installed as a desktop application?
How do you use the same codebase across web, mobile, desktop when your app is going to access camera/gps/accelerometer which aren't available on desktop?
There are some impressive numbers (from google I think) about conversion/retention/bounce rates in relation to page load times. I believe it was about a 50% reduction for every extra second.
Page loads are mostly download (bandwidth-limited) and layout. For many actions, you can reduce drastically reduce data transfers if only the actual data that changes is transferred (no markup/images/content already loaded). Similarly, only a small part of the layout may change. That can result in anything from doesn't really matter (newspaper) to "this project wouldn't make any sense without it" (google docs).
Given that SPAs tend to have payloads in the MBs, high conversion rates must be based on the end user having a very fast broadband connection. They probably wouldn't stick around for the initial page load otherwise.
Modern browsers are very good at caching resources. For server-side apps the browser is often just downloading the html for the page and nothing else. Compare that with downloading json from the server and applying changes to the virtual DOM. The difference is neglible wrt to speed and is, IMO, oversold.
Thanks for asking this question. I'm also a Rails dev, pretty much in the same situation. Some people are mentioning that if you want to do some server side rendering then things can get a bit more hairy.
Well I don't want my backend app to be just an API and the frontend to be a client. I'm not trying to argue whether or not that is the correct way to build web apps, but I don't want to do all the rendering on the frontend.
The reason is that I think this would make smaller projects a good deal more complex. Maybe you can convince me I'm wrong. Again, I can imagine that if you are a big company this might be the way to go. But for building small to medium web apps I think Rails (and the Rails way of building apps) works well. What I'm trying to figure out is if I can incorporate React into my toolbelt and have it work well with standard rails apps.
It really depends on what kind of apps you are building. If it's a complicated CRUD application that can be created without much heavy lifting javascript, then you'll probably be fine with vanilla js. However, once you start getting to the build where your front end application code gets larger and more complex, something like React will scale very well.
I'm a Rails developer too. I always use Turbolink for everything with jQuery. If the app requires mobile and web, I'll just work on the rest api on rails. The client site will be another app. This way doesn't mix ugly js files with rails files.
What you need is Vue.js. Other frameworks are waste of time. Angular 2 is complex and slow. React has it's own drama(jsx, react router).
