Ask HN: ReactJS – Do you use it? Do you like it? - <AUTHOR> Just started working on a small node.js based personal project and would like to hear opinions regarding the general situation in the ReactJS environment from people who use it now or used it in the past but stopped for some reason(s).
If you do use it - are you happy with it? Maybe there are some things that you wish were different about it?
If you did use it, but not any more - what are the reasons you've stopped? <comment><USER4> I'm using it for a very large enterprise app. React's advantage is the declarative style, very easy to reason about your View logic. Team productivity is up, fixing/changing older UI is easier/quicker, it's great. We've tried angular, we were using just vanilla JS and Jquery, React is great. A great resource you should check out is the slack channel Reactiflux. Many active people and they will answer any question you have!

At this point we have around 60 pages, hundreds of components. It scales very well. Give React a few days when trying it out. We also use our own customer flux implementaion, which makes handling front end data models easier through one directional data flow. I recommend checking that out also, it scales very well. Some of our pages right now would push angular to the limit with hundreds of rows, many different components, etc, React handles it really well without having to meticulously tweak performance, it just works. Angular can do the job as well, just needed a lot of quirks to make it work.

<comment><USER5> I am using React for a smaller enterprise application and find it quite difficult to reason about. But perhaps it's not well suited to deeply nested forms with lots of fields.

After about six months, I finally feel like I've got a handle on how it works, sort of. It's probably not something I'll use again on future projects though.

<comment><USER6> I feel like you lose out on using React if your application isn't going to be huge in terms of "components" and states.

You're probably better off using simple_form and Turbolinks with Rails.

<comment><USER7> A better alternative in my experience is to implement just the unidirectional data flow idea. This gives you some of the advantages of react without a lot of the complexity.

</comment></comment></comment></comment><comment><USER8> I've moved from angular to react and i'm happy. Simple, really simple!!! interface. All you need is to remember just few methods of one (ONE!!!) class. It's fast enough to create interfaces with a lot of objects.

With react and react-native i start publish my projects on github, because they has a simple structure and can be easily supported.

I almost forget jQuery, it's really rare situation when i need to access real DOM.

Big amount of flux frameworks (i love [flummox]([https://github.com/acdlite/flummox](https://github.com/acdlite/flummox)) , [redux]([https://github.com/gaearon/redux)](https://github.com/gaearon/redux\))).

I read discussions (in twitter, in github issues, in slack [http://www.reactiflux.com/](http://www.reactiflux.com/)) of this guys @sebmarkbage, @Vjeux, @dan_abramov, @acdlite and many others as like "THE BEST PROGRAMMING BOOK I'VE EVER READ"

My [app]([https://github.com/istarkov/google-map- react](https://github.com/istarkov/google-map-react)) hit the top trending github apps, thanks to react community. (it's not easy for developer to show his work to the world)

React is GREAT!!!

<comment><USER9> Your google maps component looks awesome. I'm looking at a few frameworks for my company and react is the one that I'm leaning towards (I've used angular before but react feels more performant out of the gate). We use google maps a lot so having this would be awesome!

</comment></comment><comment><USER10> I like React because it's closer to JavaScript than any other JS library I've used. The public API is tiny; you get better at React by getting better at JavaScript.

The only thing I don't like about React is the rapid churn in architecture best-practices (Flux et al). This is in stark contrast to Ember—which nails conventions and tooling but is written far about vanilla JS.

We use React because components are a great abstraction for the web. React components are also very transportable, making them a great addition to integrated systems like Rails.

I like to focus on transferable skills. I don't want to be a Backbone/Ember/Angular/whatever developer. I want to be a good JavaScript developer. React makes that happen.

<comment><USER11> > ...rapid churn...

This is why I'm sticking with Knockout for probably another year or so. It's tiny, safe, easy, stable and it's already been proven to work for large apps.

It also has a beautiful component system and since Knockout simply stays out of your way, you get to focus on Javascript. When the churn dies down in React-land, maybe I'll take another look.

</comment></comment><comment><USER12> I use it at work and for personal projects. It's great, creating sophisticated interactions is a lot simpler with flux and react.

Flux is very boilerplate-y, even with some of the lighter frameworks. But boilerplate isn't particularly complicated, so you get over it.

If I were going to a hackathon I would not use flux+react, I'd probably go with angular. If it's something I plan on maintaining over a long period of time, react is currently my big choice.

Testing react is very nice, especially coming from angular where testing directives was very painful. (And testing everything else was needlessly verbose.)

I made a VERY simple project starter [0] that I'm going to take the chance to plug now. It's built for frontend web applications in mind, and it focuses on giving you the starting environment to build an app. It provides development, testing, and production builds. In development you get live-reload and hot- loading of assets. In production you get minification, concatenation, and cache busting of assets, as well as getting all assets copied to your output folder. There's a live testing environment (i.e. watch files and run tests) as well as a single-run environment. Tests also generate code coverage reports. The best part is that it doesn't use gulp or grunt, it's just a webpack config with a few flags per environment type, and to run every task you just use npm run-scripts. Out of the box it handles ES6/ES7/JSX, CSS, images and fonts, but extending it to support other assets is trivial. I took the time to heavily comment the webpack config in order to help people out.

EDIT: My coworker pestered me to edit this and mention that we're hiring [1]. If you're interested in using React and Flux, reach out!

[0] [https://github.com/cesarandreu/web- app](https://github.com/cesarandreu/web-app)

[1] [http://www.treasuredata.com/careers](http://www.treasuredata.com/careers)

</comment><comment><USER13> Unbelievably productive. I don't think there is another good choice right now. I've been on every other framework (large, complex backbone apps, companies you've heard of) and the codebases have been insane. New programmer onramp time is down a lot, time to feature is down a lot. The codebase complexity seems to scale linearly with actions and stores, other frameworks felt more like quadratic (jk, don't respond to that).

</comment><comment><USER14> I used it for a project, along with a simple Flux implementation, and it did the job well enough. The declarative, state-based aspect of it is great. This might be a small thing, but I also missed their unified onChange event when I moved to another tool.

I didn't really like JSX, though, and using straight-up JS to declare components is gross. Using React in general also seemed rather verbose, and I found myself digging through the API docs and trying to reason about the component lifecycle. It just wasn't as _simple_ as I would like.

I ended up settling on RiotJS, which shares a philosophy with React but is closer to bare metal, so to speak. It feels more like a library and less like a framework. (They also just added mixins and HTML transclusion, two things that I missed from React.)

<comment><USER15> I agree on the JSX point, but there are a few libraries that make using plain JS less awkward:

[https://github.com/af/JSnoX](https://github.com/af/JSnoX) [https://github.com/mlmorg/react-hyperscript](https://github.com/mlmorg/react- hyperscript) [https://github.com/jussi-kalliokoski/react-no- jsx](https://github.com/jussi-kalliokoski/react-no-jsx)

I do wish the React team made their plain JS API less of a "second class citizen" to JSX though.

</comment></comment><comment><USER16> I've used it for multiple apps at this point and it's been a huge win for me in terms of productivity (I'm also quite enjoying Reagent with ClojureScript so far, but I'll withhold judgement on that for now). Trying to apply simple FRP-style abstractions over state changes like Signals becomes infinitely more tractable in React, where components are just functions that return data (as opposed to most frameworks, like Angular, with their very effectful controllers and other code).

Also, having worked with both Angular and React alongside less experienced developers, I've noticed developers in general doing a lot less stupid shit with React (not to say none, just less). Angular doesn't have many strong philosophies about programming, so it's largely up to the programmer to make good decisions rather than have the framework make the right thing feel right - the latter, in my opinion, being what growing developers need.

My sample sizes have been limited though, so take this advice with a grain of salt. Also, I picked on Angular because that's the other framework I have a reasonable level of experience with, but you could substitute most frameworks in its place.

EDIT: One thing I'm still missing is Flux. I tend to use React alongside PouchDB, and thus haven't really encountered a need for Flux, but even then - I think I simply don't _get_ it. I mean, it's just a convoluted event bus, right? What's the big deal? I don't mean to undermine the efforts of Facebook's engineering team(s), I rather feel like there must be something about the Flux architecture that I'm missing, that somehow makes it more valuable than a simple event bus.

<comment><USER17> The point of flux is one way data flow. Your data lives in ONE place (the "store"), and then it's fed into your views, which render it in a deterministic fashion. User interaction triggers actions, which circle back around to modify the data in your stores. Data should only be modified by actions, and views should only change when your data does.

There's a lot of advantages to this (in terms of performance, but much more importantly, in terms of being able to reason about your code). You could think of it as an event bus, and you might even implement it with one, but that's an implementation detail. In terms of your actual code, your store will list which actions it wishes to be respond to, your views will list which stores they want data from, and you'll have some UI elements that trigger actions. Your view doesn't "know" about events; it knows that it'll be rendered with the data it needs passed in as props, and re-rendered with the new data it needs.

You're probably using PouchDB more or less as a store. If not, you probably should be, and it would be trivial to write a very lightweight wrapper around it to tie it into your existing flux implementation of choice. What flux is trying to get you to avoid is some sort of ugly ball of ad hoc AJAX calls and local component state. PouchDB is already pushing you the same direction. (Which is probably why you don't see a point.)

<comment><USER16> Okay thanks, that actually clears things up a lot. Funnily enough, I found myself using this exact pattern in ClojureScript yesterday, using a ratom as my store and having what I suppose I should call "actions" which (may make HTTP calls and) update the data.

<comment><USER18> Sounds like Re-frame might be the natural next step for you: [https://github.com/Day8/re-frame](https://github.com/Day8/re-frame)

I haven't used it myself yet, but I'm itching to! I love Reagent and I'm very interested in FRP, especially the proposition that it might simplify the code a great deal if your app is above a certain threshold of complexity.

</comment></comment></comment></comment><comment><USER19> I've been slowly injecting it into a project that was previously all JS + jQuery.

Things I love:

\- All of the view state, event handlers, and markup in a single place. This makes it super easy to reason about.

\- Very easy to learn and get up to speed with relative to a full framework. I found it even easier than Knockout which is saying a lot.

\- Injectable into a pre-existing project that was not designed around using ReactJS.

Things that have bugged me:

\- Having to add a JSX build step (yes I know you can avoid JSX but it's ugly)

\- No standard Flux implementation the community can rally around

\- There is a big community focus on utilizing bleeding edge front-end tech such as ES6 (using Babel) and CommonJS (through browserify/webpack), all installed through NPM. Even the FB Flux reference implementation is written in ES6. As someone crawling away slowly from simple jQuery based site, adding a full on front-end stack + ES6 is a huge ask.

<comment><USER12> You're the target of this repo [0] that I put up! It's meant to give you a complete environment for building a frontend application. I just wrote a comment [1] explaining some of the features it provides.

[0] [https://github.com/cesarandreu/web- app/](https://github.com/cesarandreu/web-app/) [1] [https://news.ycombinator.com/item?id=9751949](https://news.ycombinator.com/item?id=9751949)

</comment></comment><comment><USER20> I love it. The only things that could be improved are:

\- some components in the ecosystem are more hobby projects and have trouble keeping up with React's API, even though it's small.

\- Documentation for react-native could be a bit better (but react-native is amazing).

\- I still haven't found a nontrivial and non-bloated example of react hot loader config, and getting it working on an existing project seems to be a bit of an art.

\- Not all open source components are listed in NPM (but they should be).

\- Still waiting for more info on Relay, which while cool, has created some uncertainty about best practices.

\- Fluxxor is a great flux lib but isn't widely enough acclaimed as the clear winner, though it seems to be (though nothing wrong with competition).

Everyone I've introduced to React was a bit skeptical at first but now loves it and can't believe what life was life before.

<comment><USER21> Hi grandalf! Which sections do you think are most lacking in the react native documentation? I've put some time into improving it this week by adding:

\- [https://facebook.github.io/react- native/docs/animations.html...](https://facebook.github.io/react- native/docs/animations.html#content)

\- [https://facebook.github.io/react-native/docs/direct- manipula...](https://facebook.github.io/react-native/docs/direct- manipulation.html#content)

\- [https://facebook.github.io/react-native/docs/navigator- compa...](https://facebook.github.io/react-native/docs/navigator- comparison.html#content)

I'd love to hear where you think I should be spending my efforts next.

<comment><USER20> That Navigator Comparison doc is excellent. I suggest you link to it toward the top of the Navigator and NavigatorIOS docs.

A few things I've found confusing:

\- What is the best way to implement Stripe checkout in a React Native app. I'm a bit surprised nobody has done this yet so wondering if I'm missing something.

\- What is the status of the ReactExtensionsManager project? Is that going to be officially supported? What is the plan for modules? Where does Cocoapods fit in?

\- Will we always have to drag/drop things using XCode to use some 3rd party components. It would be great to eliminate the need for that.

\- Is there a way to wrap a native component without using Objc? From the tutorial it looks like an objc header file is always required, but it's not 100% clear why. It seems like the recommendation do React Native developers would be to just stick with Objc as the IOS language to focus on (aside from RN)

\- What is the timeline for releases that cover the rest of the native SDK's major APIs (like payments)?

So I think these fall into the big picture project organization bucket or maybe the FAQ bucket.

</comment></comment></comment><comment><USER22> I evaluated and used it briefly for a hobby project before starting my current job.

We have a lot of existing jQuery plugins, so it seemed that my options were to either add a bunch of new dependencies that duplicate their functionality in React, start a big project to move all jQuery based components over to React, or stick with jQuery (or React wrapping jQuery, which sounds like a number of headaches).

In the end I decided to use Riot.js for new components instead, which is tiny and plays well with all of our existing jQuery dependencies so we don't take a huge hit on overall transfer size. I would use React if I were building a new front end from the ground up.

</comment><comment><USER23> Our front end developer seems to like it. We decided to use React in combo with RxJS[2], utilizing a unidirectional data flow for a new project[1]. React plays well with D3 and local CSS[3] to create reusable charting components. Our app produces a relatively high number of objects in a "table". The results would otherwise be paginated from here to oblivion and back to make it usable. Lazy rendering the results does the trick in our case.

So far we feel that Reactive Programming allows us to iterate quickly and swap parts of the back end rather easily, because, quite honestly, we don't know exactly yet where this journey is going to take us. We develop based on user feedback and the data we gather from them.

[1] [https://keywordbrain.com](https://keywordbrain.com) (Preview of the front end is outdated)

[2] [https://github.com/Reactive-Extensions/RxJS](https://github.com/Reactive- Extensions/RxJS)

[3] [https://medium.com/seek-ui-engineering/the-end-of-global- css...](https://medium.com/seek-ui-engineering/the-end-of-global- css-90d2a4a06284)

[4] [https://gist.github.com/staltz/868e7e9bc2a7b8c1f754](https://gist.github.com/staltz/868e7e9bc2a7b8c1f754) (Good primer on Reactive Programming)

</comment><comment><USER24> I tried it for a small project, but end up using Mithril.js for all my new projects instead. JSX, OOP, and Flux may be fine for some people, but I prefer to use plain, functional JavaScript.

<comment><USER16> I know that React likes to use the ES6 `class` syntax, and `React.createClass` otherwise, but the spirit of React seems very rooted in functional programming to me. Create pure functions that return data, no side-effects; use immutable data structures; minimize state where possible. I'm curious what about React gives off an OOP smell, besides the (admittedly curious) choice of syntax?

<comment><USER24> You said it: class syntax and React.createClass. In Mithril, a component is a plain JS object with two properties (controller and view).

Functional programming can mean many things, and no side-effects is one of them. However, JavaScript does not support immutable data structures very well, and React suffers by trying to force it, which results in unnecessary boilerplate code for common actions. Mithril does not enforce immutable data (though you can use something like immutable.js if you want to); it embraces JavaScript-the-language better in general.

</comment></comment></comment><comment><USER25> I use React for almost all my projects and I'm definitely happy with it. It addresses one of the main problems - many developers in your team contributing to the same code. React IMO helps us write predictable code even when there are many developers contributing to the same code.

Also, my favorite quote -

Before React - Don't mix HTML and JS React - Mix HTML and JS

Imagine. It simply tells you - do things like when you started learning web development `<div onClick={handleFunc}>`, change things as much as you want, and we'll take care of it. Just keep doing whatever feels natural. I've been waiting all this while from the moment I started writing code for browser - <USER2> wanted to use `onclick=func`, `onchange=func`, and `if (isHidden) return <div hidden=true>` and it just lets me do that.

</comment><comment><USER26> I've used it on a few personal projects with a koa powered API on the backend and one smaller project at work. I like it a lot, I've tried angular and jquery as well, both really don't stack up at all.

One thing that I wish was different was the focus on using flux. Flux isn't really for me, I found it really complicated and it made following the data through my app even more complicated than it was with angular.

The solution for me was to use something like Om's cursors (specifically baobab [https://github.com/Yomguithereal/baobab](https://github.com/Yomguithereal/baobab)). After trying to get a handle on flux for a few days I switched to baobab and the real power of reactjs just clicked for me.

<comment><USER27> How do you like koa? I really like the way it handles async stuff with coroutines.

I'm wondering if it will have lasting appeal, though, because ES7 should introduce async/await to javascript, which will probably replace the coroutine style.

</comment></comment><comment><USER17> Yes, I use it at work. Yes, I'm happy with it. My thoughts are:

The core idea behind React is that it makes a ton of sense to think about views as being composed of pure functions which transform (immutable) data into a DOM. It's a very good idea, and React is a good (and certainly the most popular) implementation of it.

It's not hard to implement in a way which is performant (which is nice), but much more importantly it lends itself to code which is easy to test and reason about.

In addition, it also works well with a flux architecture. It's not the _easiest_ way to write a web app, but there's simply large classes of bugs or potential issues that simply don't apply if you embrace one way data flow and immutable data.

There's nothing magical about React, and there's certainly some alternatives floating around. And you can certainly write terrible React code. But it's still a pretty good starting place, and the more serious you are about the app the better. If it's large, complex, needs full test coverage, and will be maintained by a team of people for the indefinite future, React is pretty good. If it's a weekend hack project, it might be overkill.

As for particular issues I've had:

1) The React team is trying to embrace ES6 syntax (and for good reason) but it's not quite ready for prime time. Some core React functionality relies on mixins, but ES6 classes don't really support mixins. So either you write hideous ES5 code (ewww), or find weird workarounds for the not-yet-ES6 ready bits.

2) Facebook also pushes the testing library Jest, and a lot of React projects use it. Jest is so slow that many people will give up before ever seriously using it, but if you _do_ persevere it you'll find that it's actually a steaming pile of buggy crap. A modern mocha/chai/sinon testing stack will be 100 times faster (I wish that was hyperbole), much more stable, and much better supported.

3) There's a lot of, well, flux, when it comes to flux implementations. I like Marty and Alt, which are both really good (and apparently might be merging soon), but there's several more excellent ones. Which is kind of a problem; it'll be good when things settle down.

4) React doesn't enforce immutable data, probably because it's not a mainstream concept yet, but everything works so much better when you use it. And it's a lot easier to use if you're using it from the start.

</comment><comment><USER28> I've been using React and Flux for a few enterprise projects, and although I don't have tons of experience with browser applications it is the most helpful and pleasant JavaScript technology I've ever used (aside from maybe jQuery, but that solves a very different problem).

I agree with the people saying that "stock" Flux has a lot of boilerplate. The upside is that when you're looking to add or change code, you know exactly where to go even as the UI and business logic get complex. Some of the newer Flux implementations look like they reduce the boilerplate, but I'd like to get more comfortable with the concepts before choosing another opinionated abstraction.

</comment><comment><USER29> We use it at $work in an "isomorphic" context along with react-router[0] and fluxible[1]. I'm very happy with it and the ecosystem developing around it. Using React also provides an interesting lead-in to native apps with react- native.

We transpile all of our JS with babel as well. I'd be happy to answer any more specific questions as well.

[0]: [https://github.com/rackt/react-router](https://github.com/rackt/react- router) [1]: [https://github.com/yahoo/fluxible](https://github.com/yahoo/fluxible)

</comment><comment><USER30> Short answer: it's great.

I don't mean to echo the already loud voices of people championing React, but they're right: it's just awesome to write.

I think React has the right abstractions for today's web development: I am frequently able to express complex UI with very little SLOC. It's easy to see what a component does, and it's easy to jump into a project with little to no experience.

On that last point: I write software on a team with a lot of Angular.js fans. I've been trying to use React in more places, so I frequently start internal tools that have UI associated with them by using React.

It's going pretty well.

<comment><AUTHOR> I think repeating some of the already mentioned answers is good - it shows common things that developers like.

</comment></comment><comment><USER31> I adore react. I've moved two companies to it, one on my own and one with a team, from angular and template toolkit respectively. It's been an enormous boon to each team, who have both found that it rapidly leads to clearer shorter code.

There's a dip. Your team will briefly get really screwed up, because the mind change is big, and since it's just part of the stack, after that you'll have some library support choices to make.

Try it on a side project. Once you have a gut feel for it, you'll know.

\----

Edit: splelang si hrad

</comment><comment><USER32> We're in the final stages of migrating a large non-web system to react for a client right now (we're up to ~200kLOC of JS) first big project our new company is doing. Next time I'd use an immstruct layer for maintaining state, and maybe a thinner vdom library instead of react. Not a fan of flux at this scale, it's too easy to have components being dependent on their position in the tree, so we tend to have lots of wrapper-boilerplate that just pulls data out of the store and pass it to immutable components. I'd rather just have a module dedicated to the task, and have immstruct sort out how to dispatch updates efficiently, acting as a 'JSON-view' of the server's state.

On the other hand, some clients seem to have heard of react now, so that's a big plus of using it. We'll probably end up doing more.

</comment><comment><USER33> React is a pain to use with web components. The event handling in React blows up when it is rendered under shadow DOM, so building chrome extension through React can be a bit of pain.

They are aware of the issue, but too slow in responding to pull requests and mostly reject them for being 'not good enough'

<comment><USER34> When we accept a pull request, we have to support that code forever, so I hope you'll excuse us for being a little bit picky in what we accept.

Shadow DOM event support should be in 0.14.

</comment></comment><comment><USER35> I migrated nearly all of troupeit.com over to ReactJS.

I really love it, but my biggest complaint has to be the mixing of logic and views together, and the duplication of security checks. Although I'm not entirely sure I can blame react for that, I blame my moving from CGI to Ajax/RESTFul interfaces for most of that pain.

We had about 90% of our codebase in RoR. In retrospect, I wish I had used Flux instead of React-Rails, but I didn't have that luxury as I was not starting from scratch.

As far as react and rendering data goes, I do wish there was an easier way in the render stack to conditionally display data. It's hard to squeeze logic into render()

<comment><USER36> I'm moving a project over to flux (well, reflux), and I'm still using react- rails. I'm probably doing a lot of stuff "wrong", but what I'm basically doing is instead of injecting data directly into the react component is inject it directly into the store.[1] Mainly I'm doing it as an intermediate step towards a separated client app with an api, but the upshot is (I think) my components are doing it in something that resembles a sane way, so all I need to modify later is the store logic. (Keeping in mind this is my first go-round with React, so those more experienced with it may tell both of us what a horrible idea this is. :) )

[1] [https://gist.github.com/karmajunkie/8dd5367837ee8d2bd5bd](https://gist.github.com/karmajunkie/8dd5367837ee8d2bd5bd)

</comment></comment><comment><USER37> I'm stuck in the middle right now with dependencies on jQuery for existing projects, while trying to learn both React and AngularJS. I've also been experimenting with Vue.js which seems like a nice middle ground between React and Angular. I am also wondering if it's just better to wait for Angular2 before fully-deciding either way. There is also a strong argument to be made for Polymer + Web Components as the better platform for future projects as the Web Components standard gains further vendor support. Any opinions?

<comment><USER38> I've wrapped a few jQuery plugins into a React components and had no issues or pain. YRMV.

</comment></comment><comment><USER39> Really loving it so far! Having a harder time actually organizing all of the application's assets and figuring out a more optimized way of having all of the assets work well together.

So what are best practices for using React with PHP, for example? For some more context, using Webpack to bundle up all the React logic into a single file. Static views are being served via PHP MVC, and React parent components are attached to window. Then, React parent component is being called within PHP file.

What would be a better way of handling React in a PHP application?

</comment><comment><USER40> I've been using React a good bit lately and it's fun to use. Overall I'd say I'm happy working with it and Flux. It's definitely a toss up between it and Ember for me.

</comment><comment><USER41> It's great but it's a real pity that the most recent way of doing things with version 0.13 and ES2015 is quite different to the earlier ways of doing things.

Don't get me wrong - the newest ways of working with 0.13 and ES6/ES2015 are superb.

It's just that as a result of the changes much of the documentation, discussion, questions and answers and blog posts must first be examined to work out which version and way of doing things they are talking about. It's a bit of a mess frankly.

<comment><USER28> If you're comfortable with ES5, one option is to paste examples into the Babel REPL here:

[https://babeljs.io/repl/](https://babeljs.io/repl/)

This will give you a familiar reference for what is going on, and quickly. It also translates the JSX which could be a good or bad thing depending on your preference. Running your own instance offline allows for a lot more customization.

</comment></comment><comment><USER42> We recently developed a large application using Ember. It works very well, but I get the feeling it would have been a bit more maintainable had we done it with React using Flux architecture.

My only gripe: React doesn't play nice with things like Emblem.js ([http://emblemjs.com/](http://emblemjs.com/))

<comment><USER6> You won't be needing Emblem if you use CoffeeScript and React.Dom instead of JSX.

Something like... import {Div, P} from React.Dom

render ->

      Div

       P {color :"blue}, "Hey"

<comment><USER42> That's actually quite helpful. Thanks!

</comment></comment></comment><comment><USER43> I use it, am very happy with it. Use npm for client and server. Modular design, and uni directional data flow makes project management better than ever.

#1 complaint is that watching with grunt react-browserfiy-ing the code buts a 3-15 second complile delay into my dev process.

<comment><USER44> You need to jump on that webpack train with react hot loader. No turning back. Here's a great boilerplate. [https://github.com/cesarandreu/web- app](https://github.com/cesarandreu/web-app)

</comment></comment><comment><USER45> I like it a lot for my tiny (400 lines) app, but I'm already annoyed at threading callbacks everywhere, which I think flux is supposed to solve, so I suspect I'll love it after I get that handled.

</comment><comment><USER46> It has been amazing for me. The one directional data flow of react and flux has made component design so simple. The modular design of flux and react makes it versatile for various projects too.

</comment><comment><USER47> For me, the most significant benefit of using React is the community around it. Rightly or wrongly, React had been crowned as the darling of "modern front end" and that has attracted huge amounts of criticism, debates, and exploration into how we build complex UIs. Over the last year the cumulative output of those people plus the related projects such as Babel and Webpack have collectively taught me a smarter way of developing complex dynamic interfaces for the web. The highest praise I can offer is that for the first time in 15 years I feel like I can bring the same level of engineering to the frontend that has been available to us the backend - code that is predictable, reliable, testable, maintainable, and understandable by others.

Having said that, such frantic activity is a double-edged sword. React universe is a rapidly shifting beast - a particular tactic can be the recommended way today, then quickly superseded and discouraged by tomorrow. Some examples include: React's initial createClass() guidance, react-router's "final, final2, final3" API surface, react-dnd's complete and incompatible rewrite between 0.9.8 and 1.0, the many phases of the flux store evolution (from 'just arrays of data', to 'maybe ajax reads', to 'not data at all') etc. In every such case I get annoyed at first, then shortly after I become grateful for the change because the new way _is_ significantly better and it _does_ lead to my app code being appreciably better in structure/flexibility/agility etc. This is great for continuously evolving products - our quality increases with each such iteration. But this can be difficult to budget for, or I do not enjoy going back to the rest of the team with the news that what I asked them to do before should now be avoided. We all learn and our core product benefits, but these quality and engineering efforts are a cost that not every team can maintain indefinitely.

Lastly, React is relatively unopinionated itself which means everyone has a different way to consume it. The freedom is there, and I see many teams using it to shoot themselves in the foot. Take the concept of Flux for example - <USER3> clean and maintainable code, very few components should ever have the word 'flux' or 'action' or 'store' in them. The overwhelming majority (>80%) of components should be ridiculously stupid, have no state, and certainly know nothing of flux. But the temptation is there - "oh I'll just drop flux inside and boom I have this power to do anything I want from my ProductSummary component"). This leads to the project having way too many moving parts, overpowered components acting at will, unauthorised data access points which cause subtle bugs, and the project ends up being the same unpredictable mess as we'd' have with jQuery. Yes, the rendering is done with React, but that's a hollow gain if the app is still unwieldy.

Using React demands discipline and focus to have hard boundaries between components, creating clear and predictable data/action flows, removing as much state as possible, and obsessively guarding and layering app's building blocks. Incidentally, if you do it the 'right' way, React itself will be the most inconsequential part of the system that you can swipe away with ease when a better way to write reliable interface will be inevitably discovered.

</comment><comment><USER6> I wish it worked better with TypeScript. I love the concept and I've always felt that front-end web was broken compared to iOS.

I've worked on converting some of Reacts tutorial to TypeScript just to try it out. Here's some of the code, and it's not 100%. [https://gist.github.com/seivan/c01a3b1173cd237b8531](https://gist.github.com/seivan/c01a3b1173cd237b8531)

<comment><USER48> Would you mind elaborating on the TypeScript comment? Is anything broken or just suboptimal?

<comment><USER6> It's suboptimal and obscure. There is barely any up to date resources on it.

So far I've managed to get to stuff presented on the window, but as soon as you start messing with references to the DOM components, things start to break down.

It's a shame, I really think Typescript and React would be the answer to getting a decent code base.

One of the cool parts, is that you get to define what your property is with static type checking and have no need to use Reacts on PropValidator.

let search = new SearchBox<{ options:SearchOptions, onSearch:OnSearchHandler> })

That tells you that the SearchBox props contains SearchOptions and a delegate to call when searching

I'm just starting with both React and TypeScript, so it could just be me.

<comment><USER48> Thank you. I'd love to use these together.

<comment><USER6> Hey! I got started with Webpack and now got a decent workflow.

Still figuring out the interoperability between React(JS) and TypeScript.

There are some issues regarding arrays from React that don't have Typescript features, even when casted (like filter() and reduce()

Not to mention the lack of JSX makes things verbose.

Anyway, here's a sample code of Facebooks own tutorial. [https://gist.github.com/seivan/fad1a175a5e140299fb2](https://gist.github.com/seivan/fad1a175a5e140299fb2)

I _REALLY_ love the one-way flow of data.

</comment></comment></comment></comment></comment><comment><USER49> It's hard to beat react right now. I came to react from ember and I regret not adopting react earlier.

</comment><comment><USER50> Hi, since it a small project. Why not try using the MEAN stack. mongodb express angularjs node.</comment>


Ask HN:  Review EventDroid.com - <AUTHOR>

Hello Hacker News,
We created a new event recommendation website, http://eventdroid.com, and wanted to get your feedback on our beta version. It only works for the San Francisco Bay Area right now. We will expand to other areas soon, when we gain more traction.
Here's the gist of our idea: We navigate the maze of events, you find something fun to do! You tell us what your goal is, whether it is go out on a date, take the kids somewhere on the weekend, or just have fun with your friends. We then suggest a small number of events that are relevant for you. No more sifting through hundreds of events on various sites to find the one you're really interested in.
Please visit our site and let us know what you think. <comment><USER2> Human curated or machine generated? I had this idea for a couple of years, and I hearing it from so many people, that I keep asking myself, why isn't there a decent solution? My thought was that doing it via machine learning, is very hard, and somewhat competes with Google / Facebook in their own field, but doing it manually (e.g. just reading the sites / magazines and updating) is not scaling in the eyes of VCs, so it's doomed to fail, although it's MUCH needed, and there is no real good solution. just beware that you are going to have tons of competition based on all the people I hear that are working on this.

<comment><AUTHOR> Right now, it's manual. We're itching for machine learned solutions...perhaps the first step is to do it manually and use that labelled data later. But you're right, it's a huge challenge, and we're not sure how to do it.

</comment></comment><comment><USER2> +1 for not using the bootstrap default by the way looks good. missing: favicon, and how you are going to monetize? nice to have: API for event creators (certified ones) to add events so you don't have too nice to have2: use open graph to identify events nice to have3: google maps integration must have: mobile app :)

but keep going, so many have the same issue, and no one did it right, so being the first with SOMETHING is great

one last thing - the thing that kills such things is content have great content that is up to date, people won't care about features or how it looks

<comment><AUTHOR> thanks for your feedback! monetization is pretty far out at this stage but it's definitely on the to do list. And yes, content is important, we spent a lot of effort aggregating and curating the events, and there's still a lot of room to improve on that front. Can you explain a little bit on what you mean by API for event creators? Thanks again!

<comment><USER3> Monetization - You could do sponsored event postings or affiliate sales of tickets.

I think what he means is that I as an event host will periodically hold events. If I could notify you via the API when I have a new event that would get me listed faster.

<comment><AUTHOR> I see. I think we can implement an event submission form, that should take care of your use case.

Yes, there are several ways we can go about monetization. But I think at this point our focus is on content quality and user experience.

</comment></comment></comment></comment><comment><USER4> I would like an event recommendation app where I can connect ME + FB FRIEND(S) + PLACE + DURATION (i.e. friend visiting my town for weekend + kids. what to do?)

FB friends would be used to scrape their and my interests etc., to form intelligent recommendations.

<comment><AUTHOR> in the short term, We will include a facebook share button soon so your friends will know about your interests and have conversations about them.

</comment></comment><comment><USER5> weird name for this era...

<comment><USER2> you mean, they should have called themselves evently? or event.io? or evnt.co? perhaps. but EventDroid is a great domain if you managed to get it without paying hundreds of dollars...

<comment><AUTHOR> yeh, we tried those, and eventify or eventshark, all taken. these domain squaders...</comment></comment></comment>


SDK published for Ouya - Apache 2.0 licensed - <AUTHOR> http://www.ouya.tv/its-open-season/ <comment><USER2> It's a little odd they're making a big deal of how it's all Apache licensed (<http://www.ouya.tv/the-o-word/>) saying:

        Please note that we're still working on releasing the
        source code for various elements of the ODK — and since
        some of it is compiled object code, you won't have access
        (at least not today) to every single line we've written.

When the ODK doesn't contain _any_ sources for stuff other than the samples, but hey, it is a work in progress I guess.

(nb. as per other threads, the ODK is just providing controller, in-app purchase and launcher support; they're not repackaging the google SDK, which is nice to see~)

<comment><USER3> > they're not repackaging the google SDK, which is nice to see

They are actually not allowed to do so anymore, as of about a month and a half ago; Google decided they didn't want to be quite so open going forward.

> Section 3.4 of Google's new terms, which were updated Tuesday, reads, "You > agree that you will not take any actions that may cause or result in the > fragmentation of Android, including but not limited to distributing, > participating in the creation of, or promoting in any way a software > development kit derived from the SDK."

\-- [http://news.cnet.com/8301-1023_3-57550824-93/google- modifies...](http://news.cnet.com/8301-1023_3-57550824-93/google-modifies- android-sdk-to-battle-platform-fragmentation/)

<http://news.ycombinator.com/item?id=4793068>

</comment></comment><comment><USER4> \--Setup Instructions for the OUYA ODK--

Windows: TBD

Eclipse: TBD

... and no working homescreen, no friends lists, no simulator capable of working with the controllers, a dummy API for the store, no final hardware, no final controller, no documented UX+UI guidelines, and it's shipping in March?

My faith falters.

</comment><comment><USER5> Truth be told, I'd rather pay $500 (or more) for a powerful console than $100 for OUYA - I guess it's addressing a very specific market, but it's not hardcore gamers (although I don't have much time to play lately, I consider myself one).

That being said, I'm happy for Steam's Big Picture, where I can actually build a HTPC myself and still enjoy the living room coziness for playing.

<comment><USER6> Of course it's not for a hardcore gamer. I used to be a hardcore gamer when in high-school. These days I don't have time nor the patience to get into many hardcore games. I'd much rather enjoy playing a simpler and more entertaining indie game for 30 minutes or an hour every now and then.

I also think its biggest market in the long term may be for young kids, like from 5-12 year old. That being said, I hope they upgrade it with more powerful and more modern ARM chips as soon possible.

<comment><USER7> I am right there with you. At one time I spent hours and hours playing "Hardcore" games, tweaking settings for better frame rates. Studying forums and websites for multilayer strategies and tip. Now I really would like something I can sit down with my five year old and play together. Or spend that precious hour after bed time and before my bed time playing. I don't necessarily have time for the six hour game marathon any more. I don't think I am alone as there is a whole generation that grew up like me that is now in the same position I am. I think there will still be a hardcore market, but I think it will transition from the mass market to an enthusiast market.

<comment><USER8> Spending a lot of time tweaking settings really has nothing to do with how hardcore of a gamer you are. It's a time vs. money trade-off; you can spend an extra hundred bucks to get the same performance as a tweaked cheaper version.

</comment></comment></comment></comment><comment><USER9> _the Dev Console has an early early early (you get that?) version of what our console UI will look like._

Can somebody explain the joke?

<comment><USER10> I don't think it's a joke, just reaffirming the repetition to ensure people are expecting a more complete design.

</comment></comment><comment><AUTHOR> And people said it couldn't be done. Now it's time for people to move the goal post again!

<comment><USER11> The people criticizing OUYA weren't criticizing their ability to ship a thousand developer units or an SDK and you know it.

<comment><USER12> In many cases they were. I had friends assert they'd take the money and run. Whether they'll ship the rest of the consoles on time or not I don't know, but having a thousand working examples sent out to your primary advocates 3 months beforehand seems pretty promising.

<comment><USER13> it might be a bit early to say "working" but still I admit I am one of those sceptics that believes ouya will be a huge disappointment for most people...I hope they will be able to prove me wrong.

<comment><USER12> Well if they shipped out 1200 developer consoles with higher than a 0.1% broken rate then I'd say we're soon to see some drama.

On the other hand we might see positive reports. I'm sceptical but not as cynical as you :)

</comment></comment></comment></comment></comment><comment><USER14> shipped. delivered.

<comment><USER15> That tells nothing about quality of delivery. I'd rather wait to see what comes out of it before proclaiming success.

</comment></comment><comment><USER16> In the video, they again claim that all the games will be free to play when they mean that all games will have what is essentially a demo version. Saying they're free to play is misleading.</comment>


The "Princess Bride" You Don't Know - <AUTHOR> https://slate.com/culture/2018/11/princess-bride-william-goldman-book-screenplay.html <comment><USER2> The book is fabulous - _way_ better than the film, and I'm a _huge_ fan of the film. The same is true of "The Hunt for Red October" and "The Englishman who Went up a Hill but Came down a Mountain".

There are other cases where the film is better than the book, but specifically those three favourite films of mine are genuinely better in the book version.</comment>


Show HN: A simple, free yoga practice app for everyone - <AUTHOR> https://www.dosome.yoga <comment><AUTHOR> I have suffered from back problems for many years and the only thing that has really, genuinely helped is Yoga. I built this little app to help remove one more barrier to me practicing everyday.

<comment><USER2> Tell us more about how you got better.

</comment></comment><comment><USER3> I'm very yoga curious but the woo that often creeps in is a real turn off.

For example, the first session I looked at sent me to [https://youtu.be/s2NQhpFGIOg](https://youtu.be/s2NQhpFGIOg) and at the one minute mark it tells me that a yoga mat (preferably made of cotton) is important because it prevents earthing of the energy that gets generated in the process.

<comment><USER4> You might enjoy DDP Yoga - [https://youtu.be/aB5ys1zsz-o](https://youtu.be/aB5ys1zsz-o) \- it's yoga from the professional wrestlers perspective.

<comment><USER5> I whole heartedly second this recommendation. This is from Diamond Dallas Page (I believe that was his wrestling name, I'm no fan of Pro Wrestling, I'm afraid) who had major compression of multiple spinal discs, almost unusable shoulders, hip issues and knees that were destroyed. He started yoga exercises without the "woo woo" and has brought a lot of the functionality back to his body.

He has gone on to rehabilitate multiple people and document it. It's really a fascinating story. Kudos!

</comment></comment></comment><comment><USER6> Rather than collate yoga videos with differing levels of accuracy relative to search (the search I just did was pretty inaccurate), why not have some gifs of poses and generate the practice by linking these poses together to mix something based on the user's chosen level of difficulty, style, and goals?

For my example, I chose "Advanced" and two of the three videos were labelled "Beginner". The third I did a quick view of and it also looked like a beginner practice. This is an issue generally with yoga videos online - they are predominantly for beginners with somewhat limited Intermediate videos and very rarely Advanced videos. But you could solve this with gifs of different poses linked together on the fly, and generate the exact desired length of practice!

<comment><USER7> That's the approach that the Down Dog yoga app seems to take. They had an instructor go through all the poses and transitions, and they can then run all sorts of different classes by combining them in different ways. They do it pretty seamlessly, but i have to imagine a lot of planning went into it.

<comment><USER8> Interesting I'll check this out. I had a similar idea that you would basically catalog everything and then have instructors put in classes. And as you grew more and more class you could start to find repetitions that instructors use and eventually be able to randomly generate classes with well known sequences.

</comment></comment></comment><comment><USER9> I had my yoga teacher ex design a simple routine for me that addressed my specific biomech issues (cycling and sitting). I videoed her walking me through it and watched it enough times to get it down.

I highly recommend getting a tailored routine. The sheer numbers of people with yoga teaching credentials make it pretty easy to find one.

My question is: Where is an AR app for yoga/PT/TaiChi/etc? I thought it would come with the Kinect, but that died on the vine. Now that Apple is all about AR and health, it should be in the pipeline - right?

</comment><comment><USER10> I am a certified yoga therapist, and I agree with a lot of comments here regarding some yoga practices on YouTube. Some go way into the "woo woo" stuff that is unnecessary and impractical (i.e., you don't need a cotton yoga mat), and others teach it in ways that actually can exacerbate problems.

I have been seeing private clients for years on chronic pain issues, low back pain, migraines, anxiety/stress. Throughout my years of working with them, I've created short videos and sequences on poses/practices that have helped a lot of my clients again and again.

I try to make these videos practical and bite-sized, instead of 45min or hour long practices. I get that we are all busy, and my motto is always: do a little everyday, and that will take you all the way.

Here is a link to the library of therapeutic yoga practices (including a whole playlist for low back pain). I add new videos weekly: [https://www.youtube.com/user/yogawithelaine/](https://www.youtube.com/user/yogawithelaine/)

</comment><comment><USER11> Some vocabulary info would help. As a beginner, words like "hatha" and "ashtanga" mean nothing, so hard to select.

<comment><USER12> As a 15+ year Yogi (who practices regularly, well at least until C19!) I've never heard of these either!

According to Wikipedia:

      * Hatha is seems to be a branch of Yoga (Hatha apparently means "force")
      * Ashtanga is another type of Yoga brought to the modern world by Sri K. Pattabhi Jois and involves synchronizing breath with a series of positions.

Interesting ... I'll have to look into them!

<comment><AUTHOR> Yes, thats a fair point, I will add something to help explain each. To be honest I had never heard of Hatha until I started building this, but as I aggregated the data it is a keyword that came up quite a lot. Thanks for the feedback!

</comment></comment></comment><comment><USER13> Youtube search for Sivananda yoga. All the breathing / poses are effectively the same and it is very simple traditional yoga that has been practiced for a very long time.

Anyone can do it and there are different variations of different amounts of time. I personally skip the headstand stuff because I worry about hurting my neck, but the rest of it is very non-stressful on your body, but quite effective.

</comment><comment><USER14> Since you are both positioning this for true beginners AND surfacing YouTube videos which offer varying degrees of teaching skill, level of spirituality, focus on anatomy, etc. I recommend adding a prominent disclaimer about variability of classes, encouraging shopping around. I'd hate for people to try a class that wasn't a fit, and judge the whole practice of yoga. I think a great onboarding would suggest 3 very different classes.

</comment><comment><USER15> Slightly off topic but do Indians generally find Westerners doing Yoga cultural appropriation when it's stripped from its original context? I actually see Yoga and Hinduism more broadly like open source software with its many philosophies as branches. As such developing a free app is in the same spirit of making (formerly) esoteric practices more accessible

<comment><USER16> Can't answer for Indians, but as far I understand it is a bit complicated. Depending on the classification you are looking at there are like 6-8 branches of Yoga of which "Hatha Yoga" is one. Hatha Yoga is the one which most people think of as Yoga. It has the physical 'asanas' as the main component. It has other parts like 'Pranayam' as well which are breathing exercises with chanting of verses/sounds in some of them. Most people who practice yoga are doing 'asanas' primarily with 'pranayams' mixed in sometimes. 'Asanas' in themselves are mostly physical and I think anyone can do them without any context. So, feel free to do so. :)

</comment></comment><comment><USER17> Thanks for making this! I might not be the target of this, but it'd nice to be able to select from videos longer than an hour. I see ashtanga as a filter option and primary series is going to take at least 90 minutes to get through (sometimes 2 hours depending on who you're practicing with and how they count).

</comment><comment><USER18> Thank You!! I love this.

Since SIP orders, I have been working out at home with YouTube videos. I have been bookmarking some of my favorite videos and categorizing them (arms, upper body, cardio, etc). I think you can easily build a clone of this for other forms of workouts too.

</comment><comment><USER19> Thank you! I was just hoping for something exactly like this, as a super new beginner.

<comment><USER20> I hope you get into it, and if you do, you should consider going to some classes. Doing it by yourself in front of a screen is good, but nothing beats the environment of a class with others. It's hard to describe, since you don't really interact with everyone, but there's a certain energy you get - you can stretch a bit farther and relax a bit more deeply. Plus, you may think you're doing things correctly, but a good instructor can spot even the smallest misalignments.

<comment><USER19> That is very good advice, thank you. I have anxiety issues, so being able to prep on the terminology and basics actually does give me the incentive to go out to a real class. Which is something I've always wanted to do, but haven't been up to before. It's very difficult for me to productively receive instruction from somebody when I know absolutely nothing about the topic -- it's probably some sort of weird childhood conditioning thing.

At any rate, yes. Your advice is very good :)

</comment></comment></comment><comment><USER21> thanks for making the world... healthier..and more connected to their inner consciousness ( namaste )

</comment><comment><USER22> take the 'create a new practice' page and put it on the bottom of the homepage.

</comment><comment><USER23> This is exactly what I was looking for!</comment>


Show HN: Social mapping webapp. Post tags to the map and vote up the useful ones - <AUTHOR> http://note.is/47

<comment><USER2> Cheers for posting this!</comment>


Can America Afford Bernie Sanders' Agenda? - <AUTHOR> http://www.forbes.com/sites/johntharvey/2015/09/21/can-america-afford-sanders/#59b4613c1b07 <comment><USER2> It doesn't need to: it just needs to be able to afford it as well as the current agenda -that we can't afford- to be a massive positive.

<comment><USER3> Yeah imagine if you completely shutdown the Pentagon, get rid of standing armies world wide there's a huge peace dividend waiting to transform the world for the positive.

<comment><USER4> Yeah, but imagine if you completely get rid of standing armies only in the USA. There's a huge peace dividend for the USA, but also a huge vulnerability to anybody in the world who decides to keep their military and attack the USA.

See, Sanders isn't running for president of the world. He doesn't get to disarm everybody else. If he wins, he only gets to run the USA. Everyone else keeps their own psychopaths and machiavellians and thugs that are running things.

<comment><USER2> I wasn't aware he intended to disarm anyone.

<comment><USER4> I was replying to shams93, who said "get rid of standing armies worldwide". That plan - whether or not it's Sanders' plan - is impossible without first conquering the rest of the planet. Getting rid of standing armies in the USA - whether or not that's Sanders' plan - is a fairly bad idea if everyone else keeps their armies. That was my point.

</comment></comment></comment></comment></comment><comment><USER4> Yeah, we'll just print money to cover all that the government is spending, and it will hopefully all work out. We can print our way to prosperity![1]

[1]: Your mileage may vary.</comment>


D&D player revolt over third party offers causes D&D to change plans - <AUTHOR> http://pavlovskitchen.wordpress.com/2010/04/21/dungeons-dragons-online-games-and-going-too-far-in-trying-to-get-customers-to-pay-up/

<comment><USER2> Title is innacurate. This is Dungeons & Dragons Online which is completely different than Dungeons & Dragons. Just sayin'.

</comment><comment><USER3> This article really isn't all that informative, and given your other submissions, one might assume that you're just trying to promote your social gaming endeavor.

<comment><USER4> Just out of curiosity, is there anything particularly bad about doing this? Looking through the guidelines they do in fact encourage self posting, so I'm wondering if there's some sort of "community" discouragement of this sort of thing.</comment></comment>


Boeing safety system not at fault, says chief executive - <AUTHOR> https://www.bbc.co.uk/news/business-47980959 <comment><USER2> This headline is highly misleading. The article says "Dennis Muilenburg maintained the system was only one factor in a chain of events that led to the disasters."

I watched the actual event and this is generally accurate. He maintained that all accidents are a result of a series of events, all of which would have to occur for there to be a crash.

He did _not_ say that MCAS was not at fault - the opposite, in fact, since he said they were testing a new version of MCAS to prevent future crashes.

<comment><USER3> Highly disingenuous to infer that if multiple factors that coincide to create a failure, that this component is not "the cause".

Of course there are always multiple factors, but all the evidence points to the MCAS system as a major contributor to these catastrophes.

I don't know who's advising Boeing on their crisis management and media strategy, but they're doing it wrong.

Every time Boeing attempts to sidestep or minimize this it makes me trust them less.

Take a lesson from the Tylenol poisonings [0] and the Rogers Commission investigation of the Challenger disaster [1].

Step 1 in enlightened crisis management: accept responsibility.

[0] [https://en.wikipedia.org/wiki/Chicago_Tylenol_murders](https://en.wikipedia.org/wiki/Chicago_Tylenol_murders)

[1] [https://en.wikipedia.org/wiki/Rogers_Commission_Report](https://en.wikipedia.org/wiki/Rogers_Commission_Report)

<comment><USER4> > Step 1 in enlightened crisis management: accept responsibility.

Agreed completely, but let me be devil's advocate here.

If he accepts responsibility then boeing is presumably fully and immediately legally liable. I guess that, particularly under US culture of suing anything that moves, everyone will try to cash in to the maximal extent possible. Including airlines possibly cancelling their existing orders - might they cancel 4,700 plane orders? What would that do to the company? By how much would boeing's liability increase on a straightforward "mea culpa"?

I can't agree with his butt-covering but I can see why it's happening. There seems to be little upside to accepting the blame. Could it destroy boeing? How many jobs lost?

"Boeing employs more than 153,000 people across the United States and in more than 65 countries" <[https://www.boeing.com/company/general- info/>](https://www.boeing.com/company/general-info/>) and a whole long-tail of US jobs indirectly.

How would it affect the US economy and standing in the world (I mean, more than it's already doing now)? I'm sure he's being leant on from above.

etc.

(please note I'm presenting a possible explanation, not endorsing it. There seems no moral way out of this. The real cause is the historical stupidity that allowed this to occur, for which he should definitely swing, and a few more suits. I am NOT endorsing these things I wrote but they seem things he will have considered. NB am a brit so I'm looking at this from the outside).

<comment><USER3> I suspect this is exactly what's happening - butt covering up and down the chain of command to avoid blame and legal liability.

This makes sense in a short-term, myopic view limited to first-order effects.

Enlightened crisis management isn't about the moral way out just for the sake of morality. It's about looking ahead to the second- and third-order effects.

When Tylenol was poisoned with cyanide, Johnson & Johnson could have taken the short-term, myopic approach. They could have held press conferences to explain how this wasn't their fault, it wasn't their responsibility, that many factors contributed to the catastrophe. They could have lobbied regulators to leave Tylenol on store shelves because it was an isolated incident.

Instead, Johnson & Johnson took responsibility. They communicated continuously. They to the initiative to remove all Tylenol products from the shelves. They redesigned the product to make it tamper-evident. And they led a campaign to educate people to inspect the seal and return any product where it was broken.

This was very expensive. In the short term, Johnson & Johnson would have made more profit just concerning themselves with first-order effects.

But in the long term, second- and third-order effects dominate. J&J enhanced their image, they made the Tylenol brand more valuable, and they built a deep reservoir of trust.

Boeing should take a lesson.

<comment><USER5> You're comparing apples and oranges here. In the Tylenol case, it seemed clear that the cause wasn't neglicance on the part of J&J, and the remedy of clearing all product off the shelves probably cost them somewhere in the millions of dollars.

In Boeing's case, the issue almost certainly is due to intentional actions taken by a number of people, and buying back existing 737 MAX8s + cancelling all future orders would amount to billions and could very well sink the company.

I think the parent comment is spot-on. Boeing is playing a game of damage control, and they're presumably being advised by some smart and experienced people. They're not accepting blame, an act which we can assume is motivated by the legal implications of doing so.

</comment></comment></comment></comment></comment><comment><USER6> Since the main battle to getting this plane flying again is going to be public trust, I think they're going about this all wrong.

First admit full responsibility. Then at least you have a shot at people trusting you to fix it.

<comment><USER7> At this point the planes either need to be retrofitted with their original engines or scrapped. They will remain flying deathtraps no matter how much software is piled on to patch the issue.

<comment><USER8> Why? What I've heard is that if the pilots know how to disable the pitch correction, the plane won't fight them in the event of a sensor failure and they can land safely.

<comment><USER9> Isn't that exactly what happened with Ethiopian Airlines? The pilots knew about the MCAS, knew what was happening, disabled the system, but were unable to physically adjust the trim to prevent the crash?

<comment><USER10> I've not read anything that suggested they knew about MCAS. They knew about automatic stabiliser trim, which is a different system also present on the older 737 NG. The way MCAS monitors angle of attack, and the way it is temporarily disabled by pilot trim inputs was not known to them.

<comment><USER7> They followed the recovery checklist. Step 1: Use the trim cut-out switches to stop MCAS. After the first crash, any MAX pilot would have to be a moron to not be informed about the issue and Boeing's (useless) guidance to resolve it.

<comment><USER10> Yes I agree, they knew about the possibility of runaway stabiliser and they were not morons. Boeing's guidance was useless to them because it left out a description of how MCAS operates, and I'm not sure it even mentioned it by name but I may be wrong on that.

If they had known that MCAS is disabled for 15 seconds by pilot trim inputs, they could have saved the plane. Toward the end of the flight they went off- book and re-enabled auto trim, blipped the trim a few times and 15 seconds later MCAS jumps on and dives them into the ground. All they needed to do was keep making small trims.

<comment><USER11> > If they had known that MCAS is disabled for 15 seconds by pilot trim inputs, > they could have saved the plane.

I understand it as "if they were able to consistently, all the time, until they land, fight the plane which was trying to kill them every 15 seconds turning the nose to the ground, resulting all the time in even harder position (due to the forces involved) they would..."

Flying death trap indeed.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> Video of Muilenburg press conference: [https://youtu.be/xOQmQpKHVWA](https://youtu.be/xOQmQpKHVWA)

He says MCAS is a "system that's designed to provide handling qualities to the pilot that meet pilot preferences." That's somewhat economical with the truth. It's designed more to meet the airline's preference not to have to retrain their pilots, and Boeing's preference to recover lost market share from Airbus.

</comment><comment><USER12> The scary thing I take away from this, is that I'm now interested to know what plane I'm going to get on.

For my entire life I'd thought (rightly) that "aircraft are the safest mode of travel" \- this issue has for the first time ever made me realize that aircraft safety is not an absolute. People making planes put up with all the same crap I do at work.

<comment><USER13> It's still the safest mode of travel.

<comment><USER8> I'd be curious to know how many planes could crash every year and still produce a lower death toll than auto crashes.

</comment></comment></comment><comment><USER14> > Mr Muilenburg said that both accidents occurred because of faulty data from > a sensor which triggered the plane's Manoeuvring Characteristics > Augmentation System (MCAS).

As if Boeing wasn't responsible for the faulty data and the poor programming that caused the plane to nose into the ground?

I suppose we should just go ahead and blame the earth for being in the flight path as the leading factor in the crash.

</comment><comment><USER15> > It said that once the 737 Max 8 returns to the skies, it will "have an > activated and operable disagree alert and an optional angle of attack > indicator".

Really, after all that they're still going to hide part of that arguably critical system behind a (presumably paid-for) option ?

<comment><USER10> The disagree alert/indicator was previously an optional extra[0]. Boeing are saying it will now be fitted as standard on all 737-MAX, including those already out there.

[0] [https://www.reuters.com/article/us-indonesia-crash-boeing- ao...](https://www.reuters.com/article/us-indonesia-crash-boeing-aoa- idUSKCN1NZ0QL)

<comment><USER16> Well that's too late, isn't it? Personally I'm not getting into any of those flying death traps ever

</comment></comment></comment><comment><USER17> He added: "As in most accidents, there are a chain of events that occur. It is not correct to attribute that to any single item."

He is selling this point hard. The problem is the chain is short and every chain has Boeing's fingerprint on it.

</comment><comment><USER18> The only thing that could get Boeing out of the hole this guy keeps digging deeper and deeper would be for him and his chief engineer to resign.

The longer he takes about it, the worse it will get.

</comment><comment><USER13> Boeing just keeps digging in and it's both a bad look and a poor strategy. This is not how you should react when people are scared to fly on planes you manufactured.</comment>


No degree? You can still work with us - <AUTHOR> https://blog.cloudboost.io/no-degree-you-can-still-work-with-us-cc9c555c0c1d <comment><USER2> "In the past we've hired from countries like Chile, India, Pakistan, Uganda, Nepal, Bangladesh, and more.".

OK hiring someone from these specific countries makes me very sceptical cause their hourly wage is like 1-5$ max. Usually most of the companies in our days looking for "cheap" talents in any of these less developed countries just mentioned in this article. I mean imagine you had an industrial business man saying to you " Oh yes we are so liberated and altruistic people that's why we moved our factories from German to China, or from USA to Honduras." Do the math, it's all about profit.</comment>


DuckDuckGo vs Goliath - An interview wth Gabriel Weinberg [audio] - <AUTHOR> http://techzinglive.com/?p=423 <comment><USER2> Gabriel, I just want to say you can't buy PR like this.

The hacker news crowd loves you (deservedly so!) and you are doing an awesome job with DuckDuckGo. Keep up the good work!

<comment><USER3> Thx! I've never paid for PR (yet), although I'm theoretically not opposed to it. My strategy to date has just been to be as open as possible, e.g. answer all interview and other requests ASAP, etc. I've also met a lot of great people this way.

<comment><USER2> Well its working! Developers love openness and developers seem to be the main focus of DDG at the moment from what I have seen. Very impressed with it, especially since I have always been interested in the search space myself as a hobby.

</comment></comment></comment><comment><USER4> Interesting interview, and thank you for taking the time to produce high quality audio. Production quality is frequently overlooked but it takes your podcast to a higher level and got me to listen for almost two hours to Gabriel's interview and subscribe for future episodes!

<comment><AUTHOR> Thanks so much for the positive feedback. ;) Justin has done a lot of work to get the audio quality where it is, so it's nice to hear that his effort is paying off.

</comment></comment><comment><USER5> Duck Duck Go is on my mind a lot these days :) Too much probably, but I think it actually embodies the future of search, for some fair sized percentage of the search market.

Right now they're at 0.035% of the market according to my estimates, that's only two doublings away from eclipsing altavista on it's way down.

DDG will be 'just what some people need', but not the general public, that's googles game. So to attack a giant like google you need to go the lilliputs way, many small search engines like DDG probably stand a better chance at nipping away at a giant like google than a single head-on competitor ever would.

Search engines are profitable at ridiculously low levels of traffic (I ran a toy one for a year), _if_ there are good enough tools to tie a bunch of them together and allow keyword sales. This will also mitigate the costs of combating click fraud.

Another thing that could be done between such micro search engines is sharing spam lists.

<comment><USER6> DDG has been my default search engine for work and home for a long time now. It's lacking in a lot of refinement on the UI end, but it works, gives me good results, and I love the zero-click information.

<comment><USER3> Working on ui refinement now, so I'd appreciate you emailing ui feedback as you think of things.

</comment></comment></comment><comment><USER7> I've switched to DDG as my default in Chrome again. My main problem is that I'm always afraid that I'm missing good results, so when it's an important search I have a tendency to also use Google. And then after a while I tend to switch back to Google to remove that anxiety.

Not sure how to fix that :-/

</comment><comment><USER8> Probably the best interview about Gabriel Weinberg.

</comment><comment><USER9> Is the transcript for this available anywhere? I much prefer text as a medium.

<comment><AUTHOR> While transcripts are something we'd love to have for the show, unfortunately we don't yet have the funds for that. Maybe some day ... ;)

<comment><USER2> Maybe you could attach a wiki and have users add them in? With 500+ listeners im sure someone would consider doing this.

<comment><USER6> This comes up every time there is a video or podcast.

I keep thinking I should create a service to do that. Crowd sourcing transcripts/outlines.

Must put some more thought into this and then build it.

<comment><AUTHOR> Yeah, we would love to take advantage of a service like that.

<comment><USER6> Okay. I'll build it. bbiab</comment></comment></comment></comment></comment></comment>


Ask HN: How to become an expert of Python asap. - <AUTHOR>

Are there any online resources(project, coding competition, etc) can make you become a Python expert asap? Thank you for advice. <comment><USER2> To learn any programming language, I would advise, in this particular order:

\- Have a project idea or a goal

\- Get basic python knowledge (any renown book or tutorial will do[1]) and get an overall feeling of the language, philosophy, main frameworks

\- Make sure that Python is the right tool for what you want to make or at least one of the possible tools

\- Start your project and learn along the way by researching how to solve problems the right way

\- Make your project work

\- Make it work better

\- Make it work faster

Bonus: Insert somewhere:

\- Other programmers' opinions on your code

[1] Resources: <http://www.diveintopython.net/>, <http://learnpythonthehardway.org/>

Also, see this thread on StackOverflow for other popular resources: [http://stackoverflow.com/questions/70577/best-online- resourc...](http://stackoverflow.com/questions/70577/best-online-resource-to- learn-python)

<comment><AUTHOR> Thank you very much.</comment></comment>


Ask HN: How do you find your first beta users? - <AUTHOR> Hi! I'm working on a startup, and I want it to be used by a few dozens of users for some time before I'm ready to launch it to the public.<p>Can you give me some advice on how to find them? <comment><USER2> When I was doing the beta testing for [http://flockmetrics.com](http://flockmetrics.com) I was looking for people with SaaS startups and I ended up using a few different approaches.

I contacted people I knew personally that were involved in startups.

I asked a friend who was involved in a startup incubator to email the incubator's founders mailing list asking for beta testers.

I posted on the @flockmetrics Twitter feed and my own personal one.

I posted the site on [http://betalist.com](http://betalist.com).

I cold contacted some people I thought would especially find it useful.

In the end I found it much easier to get feedback from those I had up front personal contact with.</comment>


Show HN: A Hacker News Reader Built with Choo - <AUTHOR> https://github.com/kvnneff/hackernews-choo <comment><USER2> I like how HN readers are the 'hello world' of every new tech stack. It's pretty cool

There are HN readers built with react native, cordova, nativescript, ionic...</comment>


A comprehensive tech solution for people with epilepsy? - <AUTHOR> http://www.artefactgroup.com/content/work/dialog?hn=true

<comment><USER2> This is incredibly impressive concept, and I love the design thought that went into it. How does Dialog intend to detect seizures? Will the patient need to act fast enough to trigger the device manually?

It would be great to hear from a company interested in making this device a reality, but as far as I can tell, nobody's currently building this.</comment>


Vegan burgers make men feel fuller than beef, study finds - <AUTHOR> https://bigthink.com/surprising-science/vegan-meals-make-you-feel-fuller <comment><USER2> And the macros?

If you're substituting carbs in place of proteins and fats, then I'm not surprised by this result, but if you are trying to avoid unnecessary carbs, then vegan burgers usually don't replace beef very well. Which is also a shame because I actually like a number of the plant based patties I've had, but they don't fit within my requirements.

</comment><comment><USER3> I see that the article mentions the Impossible Burger though the study does not. This does still apply to the Impossible Burger though right?

In the study, they used traditional vegan burgers made of tofu (soy). While Impossible Burgers also have soy technically it's not something derived from a whole bean - and there's also potato protein, coconut oil, and wheat in there. Everything is still plant based though...

</comment><comment><USER4> What about women?</comment>


CMU's Libratus builds substantial lead in Brains vs. AI competition - <AUTHOR> http://www.cmu.edu/news/stories/archives/2017/january/AI-tough-poker-player.html <comment><AUTHOR> I believe we are witnessing the Cambrian explosion of intelligences. The techniques behind Libratus (abstraction algorithm and game theory [1]) appear to be qualitatively distinct from those behind AlphaGo (deep reinforcement learning and MCMC) and DeepBlue (search and heuristics).

An ecology of Artificial Intelligences, unbounded by our evolutionary history and neural architecture, could evolve to suit each particular task more effectively than our brains can.

Promises and perils abound.

[1] [http://www.cs.cmu.edu/~sandholm/](http://www.cs.cmu.edu/~sandholm/) section "Algorithms and complexity of solving games"

<comment><USER2> Chess, Go, Poker... All feel like variations on the same theme. While it's obvious there is innovation being done, I want to see something more challenging. Something with more dimensionality and integration of several types of input.

How about a machine that can beat someone at Smash Bros, a game with varied characters, complex comboing mechanics, and a nontrivial computer vision task?

Or--more difficult by a few orders of magnitude--what about a robot that can beat someone at tennis? Or a team of robots that can best a professional basketball team?

When do you suppose we'll begin to see these sorts of things? Within our lifetime, I hope?

<comment><USER3> >Something with more dimensionality and integration of several types of input.

like using a few degrees of freedom and little strength to chop onions and some vegetable, crack eggs, whisking them, pour a bit of oil into a pan and lighting a stove, pour the omelette, flip it onto the plate, throw the eggshells in the trash unless it's too full (and take the trash out if it is) and wash the chopping board and pan with a sponge (adding a little dish soap) and not too much water, then rinse them thoroughly but without too much water. Which poses no challenge to most adult humans who take just a bit of time to learn (if you never learned to make an omelette and you're an average adult, by Wednesday you can make a perfect omelette every time.) Even though objectively humans have very weak hands, see things very, very slowly compared with machines, and cannot do any single mechanical action as reliably and predictably as robots.

computers might be able to find and count all the primes between one and a million before I can count the ones up to ten[1], but they can't even scrub my bathtub with a sponge given a whole afternoon to do it - not without a lot of specialized robotics anyway.

[1] [https://www.quora.com/How-long-does-the-fastest-algorithm- ta...](https://www.quora.com/How-long-does-the-fastest-algorithm-take-to- generate-primes-up-to-a-million-and-up-to-ten-million-on-a-standard-home- computer)

<comment><USER4> We make up for hand weakness with hand dexterity, slow vision processing with incredibly rich feature sets and powerful cameras, and reliable actions with previsioning and prediction on every task.

The human system is pretty incredible.

<comment><USER3> Yes, this is the kind of task computers should "compete with" \- using weak and semireliable motor functions and cheap cameras (no infrared or laser vision etc) and making up for it with "smarts" \- the way humans do.

</comment></comment></comment></comment></comment><comment><USER5> It's important to note that last time, the poker players beat CMU's AI by around 500k chips as well and they had the gall to declare it a "statistical tie". Yet if they win by chip they will claim to have "won".

<comment><USER6> [http://motherboard.vice.com/read/a-poker-playing- supercomput...](http://motherboard.vice.com/read/a-poker-playing- supercomputer-just-barely-lost-to-human-pros) Lost by $732,713, with $170 million bet... pretty close. But you're right, a victory by a chip will be declared a win

<comment><USER7> That's both an unfair slight to the ethics of the researchers involved, as well as inaccurate. They've published in advance their criteria for declaring a victory vs a tie: [http://www.cardplayer.com/poker-news/21215-poker-bot- doubles...](http://www.cardplayer.com/poker-news/21215-poker-bot-doubles-lead- in-historic-match-against-humans)

which is: "If after 120,000 hands either Libratus or the humans are one standard deviation above break-even, they will have won the competition with "statistical significance.""

(I'm a professor at CMU, but I have nothing to do with this research or competition.)

<comment><USER5> we mostly mean by the media. Story if they barely lose "Poker bot statistically ties pros". Story if they are one chip up: "Poker bot leads/beats pros"

</comment></comment></comment></comment><comment><USER8> I played poker part time heads up (one against one) previously and the amount of study and analyses players have to do is huge to only get to a reasonable level.

This challenge is very unfair to players so I wouldn't say it won, players have a massive disadvantage, every professional player has tracking software and a database to analyse every decisions that has been made.

This is of course extremely important because you can model your strategy to exploit the suboptimal decisions made by your opponent, yet players have no access to any of these tools, so the bot adjusts it's play based on their human opponents but humans cannot do the same and are left with a guessing game.

If they want to make a proper challenge then players need to have access to the tools they usually use playing in the Internet.

<comment><USER9> >o the bot adjusts it's play based on their human opponents but humans cannot do the same and are left with a guessing game

Do we know if it actually does it? I imagine it's much simpler to build a bot that plays a balanced profitable strategy rather than one that tries to build a model of their opponent and exploit it.

<comment><USER10> It's stated in the article. During a day's play, the AI suggests plays based on its current knowledge. At night, the day's events are fed into the system for it to learn on for the next day.

I assume there are probably papers that specify what form of learning is taking place, but the article didn't go into that level of detail and I haven't tried to track it down.

</comment></comment></comment><comment><USER11> Trying to play GTO is an interesting (and very profitable) approach but ultimately it's not the most profitable approach. It makes sense for the AI to be constructed that way because the matches it's likely to play are against good opponents. Most profit in poker comes from playing against not so great opponents though. Against those you usually play extremely exploitable on purpose.

That being said, the AI seems pretty impressive. Not sure how they picked the players I could think of a few HUNL players I'd rather see but they might not be interested in a 200k freeroll.

<comment><USER12> It's tough to decide what skill in poker really means. Is it that the AI can win against a good player or that the AI can earn money from bad players faster than other good players?

</comment></comment><comment><USER13> They should do a Libratus vs Deepstack tournament [https://arxiv.org/abs/1701.01724](https://arxiv.org/abs/1701.01724)

</comment><comment><USER14> I wonder if the players tried colluding: coordinate their bets to fake a weakness so the AI start to adopt a poor strategy, then up the bets and stop the feign. I don't see how the AI can protect itself against that.

<comment><USER15> The aim of the AI isn't to adopt to poor strategies, rather to play an approximate optimal strategy itself. It's aiming to be unexploitable, the further the other players deviate from optimal, the more it wins. It's EV (expected value) comes from the other players not playing optimally, it doesn't care about exploiting individual weaknesses.

<comment><USER12> Then I'd say it's not a very good poker player.

<comment><USER15> If you define a 'not very good' strategy as losing at a maximum of 0, then sure. Playing optimally means the worst case scenario against _any_ opponent would be breaking even. It doesn't have to be trained on individual playing styles, it is simply playing each spot theoretically correctly.

An example, say the humans are getting to a river situation with too many bluffs for a given betsize, an exploit for the AI would be to always call. The opposite is also true, if they are bluffing too little it should always fold. The players notice that the AI has adjusted, and adjust their frequencies - now exploiting the AI. By taking an exploitative approach the AI leaves itself open to be exploited, this is not the goal.

If this were rock paper scissors, the AI is doing the equivalent of always throwing each at 1/3 - even when it's opponent throws rock every time. It could switch to paper, but a thinking opponent will now switch to scissors, this will continue until we are back at equilibrium. The AI aims to play poker in this same fashion, having the correct frequencies of actions for a given range in every spot.

<comment><USER12> A better AI should be able to fool the opponent into thinking it has thrown rock (metaphorically) so that the opponent throws paper while the AI instead throws scissors.

Poker isn't about equilibrium, it's about misdirection and exploitation. When the table gets cold, you liven it up by convincing everyone to do a round of straddle.

<comment><USER15> Heads up poker is precisely about equilibrium. Your straddle reference is also irrelevant, this is not live multiway poker.

"Tricking an opponent into thinking it has metaphorically thrown rock" extrapolated into a poker example would be betting larger/smaller, calling more/less, folding more/less than is optimal in a given scenario in the hope that your opponent makes a (bigger) mistake. You're simply hoping he makes more errors than you, the AI instead choses to just make zero mistakes and let the opponents do the rest. You can see this in action for yourself in Heads up limit holdem by playing Cepheus ([http://poker- play.srv.ualberta.ca](http://poker-play.srv.ualberta.ca))

<comment><USER12> You're still thinking one hand at a time. It may be possible to confuse the opponent into permanently shifting strategy.

I agree that would not happen if two equilibrium-seeking computers played each other. Since the human strategy is unknown, it is possible that equilibrium may not exist or be optimal. Even if it's two computers, if one of the computers has the possibility of choosing a non-equilibrium strategy, then again the optimal strategy may not be to seek equilibrium.

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> Libratus biggest edge is probably grinding away at their blunders & tendencies (eg. Don never check raise bluffs in this spot, so I can safely value bet). It would be really interesting if they published the bots results vs. a mythical generic player. The difference would be a nice estimate as to how big an edge it derives from backtesting it's personalization strategies.

<comment><USER17> It doesn't use player tendencies, it plays closer to Nash equilibrium than the human players, AFAIK.

<comment><USER16> Yes it does. The Libratus bot uses a conterfactual regret minimization algorithm variant of the CMUs teams' own design to calculate endgame strategy. The inputs to that algorithm explicitly takes into account previous player behavior.

<comment><USER17> It doesn't know who it's playing against, so it accounts for the behavior of ALL players it played against, no?

</comment></comment></comment></comment><comment><USER18> That is very unconvincing as 49k hands is really nothing and not enough to iron out variance unless the edge is really big (which doesn't seem to be the case). Any serious poker player will tell you that. They should play 1-10 million hands (depending on the edge) in order to get a decent idea of where this is going.

<comment><USER19> Yes, I'm wondering if anyone is tracking the relative strength of each player's hands. In the end, the bot should be declared the "winner" only if its winnings were disproportionately high in relation to the strength of its hands.

<comment><USER20> The usual way they reduce variance in these man vs. machine poker showdowns is to do "pairs" play. You have two humans playing simultaneously in isolated locations. The decks for both humans are the same, but player 1 and 2 are swapped for one human. That way, the bot strategy has to play both hands.

It does totally eliminate variance, but they also take that into account and correct for it when looking at final outcomes usually. Right now the bot is up by something like 800K over 60K (out of 120K) hands. If that rate continues, it will win by around 1.6M or 400K per human. The blinds are 50/100, so that would equate to roughly 33 millibets (thousandths of a big blind per hand). That isn't too far off from standard win rates in bot vs. bot tournaments [1].

I'd say it's likely that the results of this tournament will be a statistically significant win for the bot.

[1] [http://www.computerpokercompetition.org/downloads/competitio...](http://www.computerpokercompetition.org/downloads/competitions/2014/results/results_2pn_tbr.pdf)

<comment><USER18> That trick doesn't change the variance at all if decks are the same.

Typical winrates in human vs human are between 1-5ptbb/100 where 1ptbb = two big blinds. At 1ptbb the variance is pretty big and north of 1million hands are probably necessary to establish an edge, whereas at 5ptbb the variance is much smaller and 100k hands are usually enough to converge to the expected value

</comment></comment></comment></comment><comment><USER21> I would love to know where they got their training data or if there's one publicly available.

<comment><USER22> This is not neural net. It uses an algorithm called counterfactual regret minimization to compute the Nash equilibrium of the game, no data required.

<comment><USER21> what about - [https://arxiv.org/abs/1701.01724](https://arxiv.org/abs/1701.01724)

<comment><USER22> That's a new bot by university of alberta. Funnily enough, even that doesn't require actual data. It uses randomly generated ones.

</comment></comment></comment></comment><comment><USER23> How would someone with no knowledge of the game learn to play poker? Any good books that stress the mathematical/probabilistic(/game theoretic...?) side of things?

<comment><USER24> Assuming you at least know the rules of poker, you can probably start with the MIT course on poker theory, available here: [https://www.youtube.com/watch?v=OTkq4OsG_Yc&list=PLUl4u3cNGP...](https://www.youtube.com/watch?v=OTkq4OsG_Yc&list=PLUl4u3cNGP61kfOW3zAIfpNhf0piao8oo)

</comment></comment><comment><USER25> Unless things have changed significantly from the previous version (Claudico), this is not really no limit hold'em, as the stack sizes are reset every hand.

<comment><USER26> How is that not no limit?

<comment><USER27> One of the distinctive traits of no limit tournament is that on any given hand a player can be knocked out the game with a big enough bet, which affects how players are likely to play (as might one player amassing a large chip lead ove another if neither player opts to go all in on early hands)

Of course it also makes games shorter and introduces a lot more variance, which isn't so good for assessing how well a computer plays.

<comment><USER28> This isn't a tournament though, it's more like playing a very long cash game where the stacks are reset on each hand. Whoever has the profit at the end of the cash game will be the winner.

</comment></comment></comment></comment><comment><USER29> Honestly, this doesn't look to be a true test of who is better at poker. Poker is not like chess - a lot of emotions are involved in reading another players' cues (if he is touching his face, whether he is talking nervously, how quickly does he call all in etc.). Making all this computerized seems to take the spirit of poker away. It is like playing online poker which is an entirely different ball game vs. real poker.

<comment><USER30> Physical tells are almost entirely Hollywood nonsense. When a professional player talks about getting a read on someone, they are talking about probabilities combined with the opponent's position at the table and a history (even a short history) of that player's betting/play patterns.

<comment><USER31> > Physical tells are almost entirely Hollywood nonsense

That's true for most any level of serious player, but I see it often in casual games in peoples kitchens with casual players who don't play often or are just starting. Even I can't control myself sometimes when the adrenaline starts pumping. I'd rather say lack of self control is just one of the most amateur things you can do in poker, and what's nonsense is the idea that it's a meaningful aspect of any kind of serious poker game.

</comment></comment></comment><comment><USER32> Wonder how long it will be until there is a crowdsourced AI winning the World Series of Poker?

<comment><USER33> Very very long. First of all, this bot was capably only of analysing heads up play. At the WSOP there can be maximum 10 players at the table, and with each extra player, the number of combinations to analyse grows exponentially.

Second, in the WSOP it is key to exploit weaker opponents. This bot was able to find almost perfect play against expert opponents but exploiting weak play is a different ballgame, especially if you are facing a mix of strong and weak players at a multi handed table.

</comment></comment><comment><USER34> How good are the BEST poker bots right now at holdem with more than two players?

</comment><comment><USER35> Easy with 16 tetra of ram

<comment><USER36> And tanking for 1+ mins on turn and river decisions (it would time out in real online poker). And $10M in computer resources. But impressive nonetheless.

<comment><USER12> Eh, I'll tank for a few minutes in live poker. I don't mind that the computer does too.

</comment></comment></comment><comment><USER37> I wonder if it is possible to achieve super-human play purely using reinforcement learning to train deep neural networks.

</comment><comment><USER38> Is this really fair? Part of Poker is "reading" when other players are bluffing, it's a lot more challenging to read when a computer is...

<comment><USER17> First of all, that's not true. Most players play several tables at the same time against the same player, up to four heads-up. That's something like 600 hands an hour in HU.

There's little heads-up play in live games, other than at the end of the tournament, and the stack sizes are completely different. These are not tournament players, they're heads-up specialists. They most assuredly play online the majority of the time.

Second of all, the computer doesn't read the human players, why would it matter? It's all up to actual strategies at that point.</comment></comment>