Removing User Interface Complexity, or Why React is Awesome - <AUTHOR> http://jlongster.com/Removing-User-Interface-Complexity,-or-Why-React-is-Awesome <comment><USER3> This is a really thoroughly researched post and jlongster has my gratitude for writing it up.

I have two concerns with this approach. Take everything I say with a grain of salt as one of the authors of Ember.js.

First, as described here and as actually implemented by Om, this eliminates complexity by spamming the component with state change notifications via requestAnimationFrame (rAF). That may be a fair tradeoff in the end, but I would be nervous about building a large-scale app that relied on diffing performance for every data-bound element fitting in rAF's 16ms window.

(I'll also mention that this puts a pretty firm cap on how you can use data binding in your app, and it tends to mean that people just use binding from the JavaScript -> DOM layer. One of the nicest things about Ember, IMO, is that you can model your entire application, from the model layer all the way up to the templates, with an FRP-like data flow.)

My second concern is that components libraries really don't do anything to help you manage which components are on screen, and in a way that doesn't break the URL. So many JavaScript apps feel broken because you can't share them, you can't hit the back button, you can't hit refresh and not lose state, etc. People think MVC is an application architecture, but in fact MVC is a component architecture— your app is composed of many MVCs, all interacting with each other. Without an abstraction to help you manage that (whether it's something like Ember or something you've rolled yourself), it's easy for the complexity of managing which components are on screen and what models they're plugged into to spin quickly out of control. I have yet to see the source code for any app that scales this approach out beyond simple demos, which I hope changes because I would love to see how the rubber hits the pavement.

It's always interesting to see different approaches to this problem. I don't think it's as revolutionary as many people want to make it out to be, but I've never been opposed to borrowing good ideas liberally, either. Thanks again, James!

<comment><USER4> To clarify, Om does not "spam" state change notifications via requestAnimationFrame - all rAF calls are batched. For example if a state change occurs we schedule re-render via rAF. If another state change occurs we will not call rAF since one is already queued. In fact no state changes can queue another rAF until all changes in the current cycle have been completely flushed.

<comment><USER3> I guess this discussion hinges carefully on our relative definitions of "spam." ;) What I mean to say is that, changes or not, the browser will be invoking your diffing algorithm every 16ms.

<comment><USER5> Won't that only happen if a state change has been made? That is, the diffing algorithm will only get invoked once every 16ms if the state changes faster than once every 16ms.

<comment><USER3> Nope, it calls it regardless of state change—that's the point, you eliminate the challenge of determining when state has changed.

To quote TFA:

> A set method to change state could trigger a rerender (React has setState), > but there's an even easier way to react to changes: continuously call > renderComponent with requestAnimationFrame to repaint the UI, and only > change the DOM when the component returns different content.

Edit:

I was mistaken about how Om works. I was under the impression that Om scheduled a rAF every 16ms to check for state change. In fact, it only schedules a rAF once the state changes.

However, this relies on being able to listen for state change from the underlying model data. I was under the impression that one of the benefits of Om/React was that you could use its data bindings with any JavaScript library, even if it hadn't been instrumented for property observation. Instead, it seems that with Om, you are limited to consuming data structures that implement its state change notification interface.

<comment><USER6> Thanks for clearing up the confusion. Although, I think it's worth it for you to edit your initial reply since it's the most upvoted comment so far.

Also, your comment, to me, shows there is still some confusion regarding Om's internals:

> However, this relies on being able to listen for state change from the > underlying model data. [...] Instead, it seems that with Om, you are limited > to consuming data structures that implement its state change notification > interface.

Actually, the interface used is ClojureScript's flavor of STM: you set your app state, generally a hash-map, in an atom. When you mutate the app state via `swap!` it is published to Om -> React -> render. This may seem like a pedantic distinction, however, the key point is that you are required to use an atom which controls app state mutation. You could also use strings and vectors as your app state if you so choose.

<comment><USER7> Interfacing with an external js library that publishes changes would be trivial though. Typically if you're building a ClojureScript app you're building a ClojureScript app... which means using atoms.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> As mostly an outsider to the web front end development, React.js is probably the easiest one for me to understand among the typical "frameworks", especially Angular and Ember.

After all the excitement about Angular for example, I went to learn about it and just got lost with new concepts: DOM transclusion, scopes, services, directives, ng-apps, controllers, dependency inversion and so on. I can use it but need someone to hold my hand. It reminded me of Enterprise Java Beans.

But so far just learning how React is put together and looking at the tutorials it seems like less of a framework and easier to understand altogether. I suspect this might become the new way to build web applications.

Well anyway, don't take this too seriously, I as said, I am an outsider to this.

<comment><USER9> > After all the excitement about Angular for example, I went to learn about it > and just got lost with new concept DOM transclusion, scopes, services, > directives, ng-apps, controllers, dependency inversion and so on. I can use > it but need someone to hold my hand. It reminded me of Enterprise Java > Beans.

AngularJS has a serious "naming" problem.

Most these concept are easily understood when explained the right away,what AngularJS doc doesnt do. The only complicated thing to grasp is the digest cycle. But anything else is trivials.It's nowhere near the complexity of Java EE.

Scopes are easy,like any composite structure you have nodes with children and parents ,what make scopes special is that they can inherit properties from their parent scopes.

Directives are just custom html elements/attributes where you should do dom manipulation,all other angularjs components should be free from any DOM manipulation,Directives are the closest thing to react components.

Controllers represent the state of the view,when the data in a controller changes, a view that exposes that data changes and vice et versa.

Services are dumb objects that can be shared between controllers and dependency injection is the way one share these services. Controllers can references services ,and services can reference other services. Services are singletons

So there is nothing really complicated with all these concepts,just that the doc sucks for some reason.

<comment><USER10> As the famous quote goes, there are two hard things in computer science: cache invalidation and naming things. When I first heard it, I thought it was a joke; nowadays I feel like it's barely a simplification.

<comment><USER11> "And off by one errors".

</comment></comment></comment></comment><comment><USER12> Not to distract from the topic, but jlongster's posts should be a case study into how to make an effective demo/tutorial on the web. The side by side code/demo format is very well done and should be the de facto way to do code + demo. There have been so many times when I've been reading a tutorial and click on a demo link that opens a new tab. This makes me completely lose context as I switch back and forth between the tutorial and various demo links.

For another example of a post that takes advantage of the dynamic nature of the web page, check out jlongster's sweet.js tutorial[1]. It's a tutorial on writing macros with JS that you can actually interact with (you can make modifications to the example code snippets and see your macros expand on the fly). Very cool.

[1]: [http://jlongster.com/Writing-Your-First-Sweet.js- Macro](http://jlongster.com/Writing-Your-First-Sweet.js-Macro)

</comment><comment><USER13> As a recommendation to the author, it would make sense to show the example/demo area the whole time, not only once I scroll down. It confused me. A lot.

<comment><USER14> Agreed, I really like the demo area but it's a bit of a shock when it first shows up.

<comment><AUTHOR> Heh, it's been mixed reactions. I will probably tweak the initial experience, but will need some time because I can't leave it open on load because it blocks the header.

<comment><USER15> I thought it was nifty. The shocking aspect might just be the big layout change. Perhaps a notification ("Check out the demo") so the user has to click it to enable the side pane, and then its business as usual.

<comment><USER16> I liked the layout as well. One thing I would change would be to make the code area wider than the demo area, as some of your lines wrap, where the demo area rarely needs a line break.

</comment></comment></comment></comment></comment><comment><USER17> For those that haven't tried it, David Nolen's Om for ClojureScript is an excellent React framework.

[https://github.com/swannodette/om](https://github.com/swannodette/om)

I've not used vanilla React, but Om is certainly fantastic and apparently adds a bunch of stuff that's not in the JS version.

Also, a web framework written by the guy that wrote most of the language you're using? Win!

<comment><USER18> I would love to support a JS project that is something like a port of OM to JS.

<comment><USER17> I understand that there are sometimes practical reasons for not being able to use ClojureScript, but have you given it a go? It's really very, very nice (much nicer than JS in pretty much every way).

* Immutable data (you can get some of this in JS with Nolen's Mori [http://swannodette.github.io/mori/](http://swannodette.github.io/mori/))

* Better functional programming than Underscore (map :mykey some-objects)

* Great syntax: homoiconicity, thrush operator, first class set, regex, map, vector syntax

* Macros!

* Use of cool frameworks: Om, core.async

* Same language as back-end if using Clojure

It was quite frankly intimidating to get started with it all as an ex- Java/Obj-c/Python/JS dev but I could never go back.

<comment><USER16> I've been trying to move towards ClojureScript for a while, but there are so few introductory resources out there that allow you to navigate between the Clojure world and the JavaScript world in a way that makes sense to people who come from JS backgrounds exclusively.

I wish OReileys would issue an expanded version of their Intro ClojureScript book!

<comment><USER19> I've been learning CLJS for a couple months. Here's a syntax guide and a list of resources I've used: [https://github.com/shaunlebron/ClojureScript-Syntax- in-15-mi...](https://github.com/shaunlebron/ClojureScript-Syntax- in-15-minutes)

<comment><USER16> After browsing around, you're GitHub repo is a learning treasure. Thanks for posting all of that stuff in such a clear way.

</comment></comment></comment></comment></comment></comment><comment><USER20> I really like the core concepts of React, especially the way it is designed to help you organize your code into reusable components.

I think the key to making React take off is building a centralized repository for components that are open source. Then building your webapp would be as easy as importing the components you need:

         bower install react-navbar
         bower install react-signup-form
         bower install react-sso-signin-form

I think this is definitely the future of how front end web development will be one day.

<comment><USER21> So I have a word of caution. As someone else in the thread mentioned, React is very intuitive for beginners. There's another framework I've used that was also intuitive for beginners: Backbone. The reason why Backbone is inferior to Angular and Ember is because it optimized for the beginner. Angular and Ember are optimized for the experienced developer on a large code base.

Specific to your suggestion, which I think is awesome, is the idea of composibility. The easiest kind of component to write is a large component with lots of options, like jQuery plugins. This is the hardest kind of component to use _outside of its intended use case_.

What makes Angular so good is that the core directives are all extremely composable. They can be used all over the place without hacking.

To make your dream come true we as component authors must design carefully to make smaller, more focused tools, rather than large components, because large components are harder to adapt to applications outside their main use case.

<comment><USER22> React has been designed to work in Facebook's codebase, to build large features worked on by many experienced developers. The fact that it is intuitive for beginners is a side-effect, not the primary objective.

<comment><USER23> Don't forget that Facebook invested a what I would call inproportionally lot in the PHP ecosystem primarily to let new employees pick up the pace as fast as possible.

I wouldn't be surprised if React was kept intentionally newbie-friendly, too.

<comment><USER24> While it isn't impossible for a complex library to become popular, I would be very surprised if a library/framework wasn't kept intentionally "newbie- friendly".

</comment></comment></comment></comment></comment><comment><USER25> I experimented with React a bit but I was a bit bugged by how large it was. The basic idea of rendering to a virtual DOM and having unidirectional data flow is really simple but I had trouble actually diving in to React's source code and seeing things under the hood (for example, I had to find a blog to see how the diffing algorithm worked).

What are the other libraries out there that we can use for this virtual DOM pattern right now? I only found mithril[1] that similarly does the template rendering with Javascript but I still don't know how different to React it is in the end? Is the diffing algorithm similar? Do they handle corner cases the same (many attributes need to be treated specially when writing them to DOM)?

Simplifying it a bit: other than the virtual DOM, is the rest of React also the best way to structure apps? What would the ideal "barebones" virtual DOM library look like?

[1] [http://lhorie.github.io/mithril/](http://lhorie.github.io/mithril/)

<comment><USER26> I have a similar frustration with React. The source code is very hard to read our follow.

An ideal "barebones" virtual dom library looks like [https://github.com/Matt- Esch/virtual-dom](https://github.com/Matt-Esch/virtual-dom) . The `virtual- dom` module was build out of frustration with the readability of react source code and is the minimal modular subset.

I've also built a small framework on top `virtual-dom` to add in essentials like immutable state and event handling ( [https://github.com/Raynos/mercury](https://github.com/Raynos/mercury) ). Whilst mercury might not be the best way to structure apps, it's an approach that is getting me far and I'm drawing strong inspiration from FRP and FP systems like Elm and om.

<comment><USER25> Is there a single-file version of virtual dom available for download? I am not finding any instructions in the repo on how to build it. Also, why does it have so many files in the first place?

<comment><USER26> I opened this PR on virtual-dom ( [https://github.com/Matt-Esch/virtual- dom/pull/67](https://github.com/Matt-Esch/virtual-dom/pull/67) ) to get a single file version into the git repo.

It has many folders because the `vtree`, `vdom` and `h` are fundamentally seperate concepts.

Again each one is seperated into it's own files, this allows you to just require the `is-x` functions or the `diff` function alone without having to depend on the entire implementation.

It's also easier to maintain code if it's not one big file.

There are plans to break vtree & vdom out

\- [https://github.com/Matt-Esch/vtree](https://github.com/Matt-Esch/vtree) \- [https://github.com/Matt-Esch/vdom](https://github.com/Matt-Esch/vdom)

Note `vdom` is an implementation detail, we could also write `vcanvas` or `vwebgl`

</comment></comment></comment></comment><comment><USER27> Please don't break the back button (Firefox and Chrome).

In Firefox 29.0 on Ubuntu 14.04, the left sidebar with the text of the blog disappears and is replaced with a white space. I do not experience this on Chrome.

<comment><AUTHOR> I just tried it on Firefox 26 on OSX and could not replicate. It has worked for everyone I've had test the page. The only thing that happens when you press back is the animation to load the right demo. There might be something buggy with how the CSS animation is using your graphics driver?

<comment><USER28> Back button breaking on latest version of Chrome/Win7 here. Scrolling up and down adds history.

<comment><AUTHOR> It adds history?? What is the URL changing to?

<comment><USER29> URL doesn't appear to change in chrome, but the back button just cycles through the various demo screens after you've scrolled down for a while.

<comment><AUTHOR> Oh, that's because the demos are loaded in an iframe. Not sure what the best solution is, but I'll think about it. Thanks.

<comment><USER30> Whoa there. An iFrame? Why?

</comment></comment></comment></comment></comment></comment></comment><comment><USER31> Great post. I recently started a project using reactjs, and I have nothing but good things to say. The unidirectional data flow, the declarative nature, and the virtual DOM makes it powerful and very easy to like.

The best resource is to follow the tutorial (link below). The tutorial explains everything you may have a question about when comparing it to Backbone, Angular, or Ember.

[http://facebook.github.io/react/docs/tutorial.html](http://facebook.github.io/react/docs/tutorial.html)

I also found the IRC channel to be very, very helpful.

The only downside is that you still have to rely on other tools to make a true SPA like routing.

<comment><USER31> I found this blog post to be very useful on how to leverage Backbone.Route with Reactjs.

[https://medium.com/react-tutorials/c00be0cf1592](https://medium.com/react- tutorials/c00be0cf1592)

</comment></comment><comment><USER32> Would you recommend using React instead of Angular for JS heavy areas of a website that is built with a server side framework (like Rails, Django etc.)?

I developed a rather complex SPA with Angular recently and I cannot go back to the ghetto that is jQuery when using server side rendering.

<comment><USER33> Based on my initial explorations using React with Rails, I'd say React might even be _better_ when used with an existing server-side framework.

With React, you can basically store all you data (state) in the root component (which could be the root of your entire page), and replace that with new state without thinking too much about the DOM updates and view changes that result from this.

This is perfect for a server-side framework, because such a framework by definition _already_ renders everything whenever something changes (page refresh). Without React, the framework does a bunch of things and finally craps out objects that are transformed to HTML by the view (where the views are as 'dumb' as possible). _With_ React, instead of rendering the object to HTML, you just pass these objects, as JSON, to a React component (which could be the whole page), and it figures out what needs updating. You don't have to deal (as much) with client-side logic if you don't want to, and things will still be performant.

This also significantly simplifies server-side rendering, to the point where it might require only one extra call to render the component server side (the handy renderComponentToString).

Of course, in practice it's often not quite that simple, but because of how React operates, you can get pretty far with relying primarily on the server- side framework and little logic on the React-side of things (plus you can achieve the 'holy grail' of seamless server- and client-side rendering.

(apologies if I'm getting things wrong, by the way. I'm by no means an expert on these matters and only just diving into React.)

<comment><USER34> Can you please explain how to store data from the server on a "root component"?

The data portion is the main reason I was looking at Angular.

Thank you.

<comment><USER33> If you keep it client-side: you turn the server-side data into json, then pass that to the renderComponent function (in a script tag or whatnot). Inside your component, you'd use this data in the getInitialState function to set the state of this component (which could pretty much be the whole page).

Does that answer your question?

</comment></comment></comment></comment><comment><USER35> Curious if anyone has experimented with Go+React - specifically rendering on the server side as well. Similar to Rails / react_ujs (react-rails gem), seems like you would need to provide Go with access to a v8 runtime and a FuncMap helper in the template to call for the necessary component (JSX -> markup). I've really enjoyed React and I've enjoyed Go in my spare time, but I still find myself using npm for a lot of the, um, grunt work.

</comment><comment><USER36> I think this post is missing something in its description of Web Components: the fundamental difference between a JS-based framework like React and a Web Components-based framework like Polymer is that the former takes JS objects as primitives and the DOM as an implementation artifact, while the latter takes the DOM as a primitive and JS as an implementation artifact. You cannot wrap your head around Web Components and give both it and JS frameworks a fair shake until you can make this mental shift in perspective fluently.

The line in the post where "You can't even do something as basic as that with Web Components.":

      var MyToolbar = require('shared-components/toolbar');

In fact has a direct analogue with HTML imports:

      <link rel="import" href="shared-components/toolbar.html">

And that's key to understanding Web Components. The idea of the standard is that you can now define your own custom HTML elements, and those elements function exactly like the DOM elements that are built into the browser. This is a key strategic point: they function exactly like the DOM elements that are built into the browser because Google/Mozilla/Opera/et al _hope to build the popular ones into the browser eventually_ , just like we've gotten <input type=date> and <details>/<summary> based on common web usage patterns.

A number of the other code samples in the article also have direct analogues in Polymer as well. For example, the App/Toolbar example halfway down the page would be this:

      <polymer-element name="Toolbar" attributes="number">
        <template>
          <div>
            <button value="increment" on-click="{{increment}}">
            <button value="decrement" on-click="{{decrement}}">
          </div>
        </template>
        <script>
          Polymer('toolbar', {
            number: 0,
            increment: function() { this.number++; }
            decrement: function() { this.number--; }
          });
        </script>
      </polymer-element>

      <polymer-element name="App">
        <template>
          <div>
            <span>{{toolbar.number}}</span>
            <Toolbar number=0 id="toolbar"></Toolbar>
          </div>
        </template>
        <script>
          Polymer('App', {
            created: function() {
              this.toolbar = this.$.toolbar;
            }
          });
        </script>
      </polymer-element>

You can decide for yourself whether you like that or you like the Bloop example more - my point with this post is to educate, not evangelize - but the key point is that _you can define your own tags and elements just like regular DOM elements_ , give them behavior with Javascript, make them "smart" through data-binding so you don't have to manually wire up handlers, and then compose them like you would compose a manual HTML fragment.

<comment><AUTHOR> The problem is that it doesn't scale complexity-wise. You miss a key point with imports: A `<link>` imports something into the global scope. There's always one global scope. In my example, I was able to rename Toolbar into MyToolbar and use it in my scope. You lose so much using the DOM as primitive and JS as artifact.

And the second you start doing conditional elements (like the tabbed example), Web Components gets pretty complex. In React, it's just `if(shown) { renderItem(); }`.

If you make HTML smart enough, sure, you don't have to manually wire up anything. But then you're left with `x-if`, `x-ajax`, and so on tags. Why not just use JavaScript?

<comment><USER37> Using JavaScript is fine for things that need script, but ultimately, if I'm building HTML, I'd rather do it in HTML. Put another way: HTML is a great DSL for creating HTML.

As for scoping of imports, you do have a point there in theory, but in dealing with quite a few complex Polymer applications at this point I haven't seen that be an issue in practice. The scoping issue is well known among the people working on Web Components, and AFIAK there are plans to address it.

I'm not sure why you think conditionals are complex in templates. Your example might look like this in a Polymer template:

      <template if="{{ shown }}>
        <my-item></my-item>
      </template>

Yes, there's some token overhead, but in the context of a larger template it pays off to have the entire HTML specified in one place, and in a way that mirrors it's output structure, not spread out over often hard to follow imperative code.

However, as you point out, Web Components doesn't prescribe how to manipulate the DOM, so if you still prefer to do it in script, go ahead!

The point is to produce an element where the browser, developer tools, and your users don't have to care what choice you made.

<comment><USER38> HTML is a great DSL for creating static HTML.

When you start to bolt on features for dynamism in HTML you end up with Angular. The reason that it has all of those complex features is because it needs them to build real world apps. I'm sure once people have built more stuff with Polymer you'll start to see similar "feature creep".

<comment><USER37> I've worked with a number of very complex Polymer applications, probably the most complex Polymer applications in existence right now, and the template features have been sufficient so far, and there's always the fallback to code if necessary.

I can think of very few common feature requests (mostly on Shadow DOM, actually), and they don't being to approach the complexity of Angular, which concerns itself with so much more than templating. Angular's complexity is not simply an unavoidable consequence of being used for real world apps - it's just complex.

</comment></comment></comment></comment></comment><comment><USER39> Just want to say thanks to jlongster and everyone who's commented on here; I created an account just to say thanks. I'm an amateur web dev/designer trying to figure out how to move beyond static web pages, and have read what would probably amount to a literal ton of material were it printed out, on frameworks, libraries, and more acronyms than I could imagine. Outside of HTML, JS, and CSS, even "basic" things like Sass and CoffeeScript I hadn't heard of just a few months ago, and I've since been all over the world (wide web) looking for info on ASP.NET (which my group at work decided last year was what we should be doing "web-kinda stuff" in, as well as Angular, Ember, Backbone, Knockout, Node, etc etc, and everything new (to me) that research like that comes with.

The discussion here has led me to a few more things to research, but I feel it's been very helpful in helping me think critically about the vast array of possibilities a budding web designer has to deal with. I just wanted somebody to provide an objective view of "If you're going to be doing medium-complexity web apps end-to-end, then learn ______" and I still would love that, but don't think it's possible to get. The alternative, as I've been doing, is just to learn a little about everything, try to figure out the kind of things I plan to do, and then find the paradigm that works, be it vanilla technologies, something like React, Web Components, or a framework (and I've been trying to learn Angular and like it, but it's tough to grasp). It just seems like as soon as I've decided on what I want to learn, I read a new post with a title like "Why You Shouldn't Use <whatever I just decided to learn> and Why <something new I've never heard of> Is Really the Way to Go."

So anyways, a long-winded thanks, but a thank you nevertheless for the open discussion here; I feel better now that I'm not trying to find the one-and- done "best" thing for making web apps in general.

</comment><comment><USER40> For those who are only interested in the render loop, I made a library[1] around this abstraction.

I plan to expand it with a toolkit to allow thinking in terms of batches, queues and consumers, à la bacon.js[2].

[1]: [https://github.com/zenoamaro/honeyloops](https://github.com/zenoamaro/honeyloops) [2]: [https://github.com/baconjs/bacon.js](https://github.com/baconjs/bacon.js)

</comment><comment><USER41> Leo Horie, author of Mithril, has written a blog post where he explains how to re-implement some of the article's examples using Mithril (React-like client- side Javascript MVC framework): [http://lhorie.github.io/mithril-blog/an- exercise-in-awesomen...](http://lhorie.github.io/mithril-blog/an-exercise-in- awesomeness.html)

<comment><USER41> Mithril docs: [http://lhorie.github.io/mithril/](http://lhorie.github.io/mithril/)

</comment></comment><comment><USER42> I like the state and property features of React, but I still don't understand why more people aren't using Chaplin instead. Because quite honestly, the syntax of every other framework - React, Ember, and especially Angular - <USER2> complete gobbledygook by comparison.

Example: in Chaplin, components are views or subviews (because it's still an MVC framework, which is another discussion for another time). The views by default render automatically without you having to call anything. But if you did, you'd write @render() (because hey, Coffeescript saves keystrokes and sanity). That automatically renders the component in the place you've already specified as its container attribute, or if you haven't it renders to the body by default.

Whereas in React, you have to write this garbage: Bloop.renderComponent(Box(), document.body);

WHY. Can't we write a framework that intuits some of this crap? Shouldn't we use a framework that reduces the time we spend writing code?

<comment><USER23> Automatic rendering is fine in small projects. Seemingly random appearance of widgets would, however, drive the debugging person crazy.

Comparing this.render to Bloop.renderComponent is superficial. If rendering needs to have a handle on different resources, you'd either violate the encapsulation in the former example, or write a service to couple them on a separate layer -- that service might as well be called Bloop.

Some of this crap makes hard things possible.

</comment></comment><comment><USER43> If school books had online versions like this page, it would make reading so much more fun.

Great read, by the way.

</comment><comment><USER44> I was at a meetup where the speaker suggested react is great for business-like apps, but for things with an insane amount of dom objects like html games, it tends to get bogged down.

Since React claims to be super fact, has done a performance comparison to see in what situations and how much better react performs in certain cases, compared to say, angular.js or more vanilla frameworks?

(Also I hear that there is a really great speedup that using OM gives you, but I haven't seen any comparisons with om either)

<comment><USER9> if you are going to update the DOM 60 times per second no databinding/reactive whatever framework makes sense.

there is so much overhead with these solutions performances would just be bad.

However it would be interesting to extract the virtual DOM from React to use it in the context DOM based games, being able to mark elements as dirty in order to redraw them is a usefull feature.One just doesnt need all the JSX/databinindg stuff for a game driven by a gameloop.

<comment><USER45> JSX is a build step and is completely optional. If by "databinding stuff" you mean React's setState and friends, almost all of React's code deals with the actual diffing and browser handling. Components are not much more than functions from props to a virtual DOM output. It's easy to use React without ever calling React.createClass (just pass the output of React.DOM to renderComponent). Still, we're looking at separating these parts of React so that you don't have to pay the file bytes but it's not a very significant difference right now anyway.

<comment><USER9> thanks for the info, i'll try to hack something with React for my next DOM based game and see if it works.

</comment></comment></comment></comment><comment><USER46> I recently watched a presentation about React's approach (I think from a recent JSConf) and it sold me, at least enough to try. The approach makes total sense to me, and I agree with many of its criticisms of Angular in particular. I really loved the reconsidering of our idea of "separation of concerns", that if we reconsider the scope of the concern, we can devise an approach where templating and logic go together. I'm excited by these ideas.

<comment><USER47> Seems like putting templates inside js is a step backwards. The advantage is that you can package templates together with js? That problem is still solvable while maintaining separation. For instaces with browserify tramsforms you can just require( 'my-template' ).

[https://github.com/epeli/node-hbsfy](https://github.com/epeli/node-hbsfy) [https://github.com/rotundasoftware/nunjucksify](https://github.com/rotundasoftware/nunjucksify)

</comment></comment><comment><USER48> Tester: The UI is wrong right here...

Developer: Hmm...I wonder how long it's going to take me to figure out where that HTML was generated in my javascript.

<comment><USER49> You hit the nail on the head why these things are bad.

You can either build something on a mass production line, where you're just screwing the same bolt in day in and day out, or become a master craftsman and build it with proper care, design, and quality.

These frameworks are nothing more than a factory floor and if all you do is build apps with a framework you're little more than a paid glue stick piecing bits of code together. Or you can become a master software developer and build something of quality without needing a crutch like a framework.

Now, if the needs of the project are such that a framework will suffice then by all means, use a framework. Chances are, if you're doing more than building a working prototype then at some point a framework is _going_ to fail you. If you enjoy building apps using frameworks then by all means, do it. But to my mind you're doing your customer a disservice.

Contrast that with great software developers (and I've been fortunate to have worked with some _really_ great developers) who abhor these frameworks. They can get more done with less code and ultimately deliver the project faster without frameworks. The tradeoff is that it takes time and dedication to achieve that level of mastery. I personally would prefer that path.

<comment><USER50> Of course it really is frameworks all the way down. Unless maybe you're building systems by laying out your own transitors.

The trick is to understand the strengths and weaknesses of any given framework and match those with the constraints of your project.

<comment><USER49> I disagree that its frameworks all the way down. There is a distinction between frameworks and libraries. React, Angular, et al are frameworks in the truest sense of the word.

Things like jQuery and Underscore on down to stdio.h are libraries. You can pick and choose from what they contain but they're not so tightly coupled that they get in your way.

They're a tool belt with tools that do one thing and do it really well. Frameworks are like having a tool belt with a hammer that also has a saw on the end but in order to use the saw you have to grab the screwdriver even if you're not actually using it.

<comment><USER33> Thanks for pointing out the distinction. I forget about that sometimes.

That said, React is a "A Javascript Library for Building User Interfaces." And to me me it _does_ feel more like a library than a framework.

</comment></comment></comment></comment></comment><comment><USER51> It was really cool, until I realized that scrolling broke the back button.

I thought one of the cardinal sins of web design was don't break the back button.

</comment><comment><USER52> Has anyone tried to use a different template engine with React? I was just wondering, since I didn't want to use JSX inline, and writing out html with React.DOM isn't appealing either.

I just wanted a way to put templates in <script> tags that get loaded by React Components. That way, I won't be mixing templates and the behavior of the components. Has anyone done this before?

<comment><USER16> There's this: [https://github.com/mereskin/jsxify](https://github.com/mereskin/jsxify)

But really, once you get used to keeping everything together it _really does feel better_. You just have to try it out.

Personally, since I use CoffeeScript, I like this lib:

[https://github.com/atom/reactionary](https://github.com/atom/reactionary)

which, since it strips out the required `null` or `{}` first parameter, feels very much like haml or jade.

<comment><USER52> I use coffeescript too, so I should be able to use reactionary to write the dom helpers it exposes in my JSX. So then the coffeescript -> jsx on server side, then jsx -> javascript browser side, is how it works, right?

I think I'm slowly being convinced putting it together in the same file makes sense, since it's a single component, and the what's being displayed is coupled with what you'd do with it, so I guess it should belong in the same place?

<comment><USER16> Well, the way you should do it is abandon .jsx completely, and just stick to .coffee.

Something like this:

React.createClass

       render: ->

          {div, h1, span} = require 'reactionary'

          div class: 'home',

              h1 "Hows it going!"

Clean and simple, particularly with CoffeeScripts default return.

As far as templates go -- and this is what I always tell people -- structure your code in a clean way which makes the render function pop out and you might as well be working with a separate file! It really does make more sense after a while.

<comment><USER52> Cool, I'll give it a shot.

I checked out reactionary, why couldn't I just do:

{div, h1, span} = React.DOM?

</comment></comment></comment></comment></comment><comment><USER53> The awkward right panel that changed abruptly from time to time, especially the first transition, made me skip the content.

Using a non-common ui idiom is risky. The presentation and topic don't match in a way that reader (i.e. me) had enough expectations left when it comes to what you might actually have to say.

<comment><USER54> I feel kinda bad that you're being downvoted. I also felt the presentation was a little jarring. The right panel seemed to change at strange times related to the content I was reading. Perhaps it was an overuse of the "change things while the user is scrolling to make it seem cool" theme I've been seeing a lot.

On the other hand, I actually found the content pretty great, but I'm not a web developer so take that with a grain of salt...

</comment></comment><comment><USER55> Instead of having React altogether, wouldn't it make sense to have the browser keep track of a virtual DOM, and only repaint whatever changes on its own, while managing its own requestAnimationFrame and paint cycles?

P.S. I haven't looked into this in depth, just throwing an idea out there.

<comment><USER8> Yeah if the technology was in the browser that would possible.

From what I understand, the core idea is that changes are applied to the virtual DOM in a very simple way (from the application point of view). Then there is another piece of code that knows how to efficiently find the diff between the vDOM and DOM and apply the changes. It seems that last part could be done by the browser.

<comment><USER56> The additional layer of redirection, at least conceptually enables the use of application specific, or pluggable, vDOMs and/or diffing strategies.

</comment></comment></comment><comment><USER57> So I'm curious how one would implement something like drag and drop in a React app?

Would you model the drag in the main data model somehow? Or would you do that all externally (with traditional DOM manipulation) and then update the model when the drag is complete?

<comment><USER16> The latter. You would use html5's draggable, then update on complete.

Check out [http://webcloud.se/sortable-list-component-react- js/](http://webcloud.se/sortable-list-component-react-js/)

</comment></comment><comment><USER58> Needs a catchy buzzword. So, can we all agree to name this ... NoHTML?

</comment><comment><USER16> This is definitely a "Sell this to your boss" type of post :) Great work.

</comment><comment><USER30> I'm honestly really, really wary of minimalistic front-end frameworks after two years of working on single page web apps.

All that ends up happening in practice is untested, messy code with deadlines up your ass and 0 developer ergonomics. Zero.

<comment><USER59> It's hard to say what, exactly, you're referring to here. React, in many ways, is not so much a framework but rather a really smart template system. It's ergonomics, I've found, are quite nice.

</comment></comment><comment><USER15> I was half-expecting a gambit Scheme post :)

</comment><comment><USER60> This is great except the button is broken.

</comment><comment><USER61> my gripe with those is that you remove UI complexity but shove usability and accessibility over some dark orifice.

All those things are cool for social apps (a.k.a. fart apps) but for business ready platforms this is just silly.

for example, a link that i can middle click or bookmark or send to someone, etc would be much more useful even if not as spiffy as those scrolls

</comment><comment><USER62> back button behavior is atrocious ....

<comment><USER63> But Javascript is awesome! Its the future.

<comment><USER49> Javascript doesn't inherently break the back button. Sloppy developers do.

<comment><USER63> Certainly, but sloppy developers using Javascript makes it way easier to break the back button than server-side rendering.

<comment><USER64> You can break the living hell out of the back button with server-centric solutions (hello asp.net, and POST's for everything)

<comment><USER63> Fair point. I feel like us server folk have figured that part out by now at least, the Javascript stuff is still quite the wild west on the client.

</comment></comment></comment></comment></comment></comment><comment><USER65> I hate OP website, why i got to click the back button 10 times to comeback here?

</comment><comment><USER66> Damn, Javascript is only becoming messier. I think I'll just watch it from the distance and wait until someone figures out the best way to deal with it.

<comment><USER67> That might take a few browser generations sadly. HTML6 anyone?

edit: HTML/next apparently: [http://www.w3.org/wiki/HTML/next](http://www.w3.org/wiki/HTML/next)</comment></comment>


Hackers prepare supermarket sweep [article with video] - <AUTHOR> http://news.bbc.co.uk/2/hi/technology/7584258.stm

<comment><USER2> s/Hackers/Crackers

Upvoted, but please fix MSM's newspeak when submitting.</comment>


Nvidia Announces GeForce RTX 2060 - <AUTHOR> https://www.anandtech.com/show/13796/nvidia-announces-geforce-rtx-2060-349-dollars-january-15th <comment><USER2> The bigger announcement here is that Nvidia is enabling support for FreeSync and certifying that things work correctly for certain FreeSync monitors. That's a big deal. Nvidia syncing previously required their proprietary "G-Sync," which is substantially more expensive and is usually only present on monitors explicitly aimed at gaming.

It's too early to tell whether this means G-Sync is dead and FreeSync is just the new standard, but it's a great day to own a FreeSync monitor.

<comment><USER3> And it looks like you'll be able to enable it for your monitor even if it's not one of the expensive certified ones.

</comment></comment><comment><USER4> Have to wait for benchmarks to say anything definitive, but from the specs table it looks like performance is in the ballpark of the 1070. Same TFLOPS, faster memory clock but not as much memory, TDP is 10W higher.

At $350 that sounds like a tough sell over the 1070, which is finally down to $300 after rebate. Unless you're really excited about the raytracing stuff.

I'm underwhelmed for 2.5 years of progress since the 1070 (mid 2016). Just sticking it out with my 970 until it dies, which will hopefully be until there's something new worth upgrading to.

Maybe AMD has something more impressive up their sleeves in the mainstream price range.

<comment><USER5> I'm also sticking to Nvidia GTX 970 for now but would be nice to upgrade at some point. I was hopeful about AMD's offering but after trying Ryzen 2400G APU on my Linux media box I am not going to touch new AMD hardware again with a ten foot pole any time soon. Their Linux drivers are a nightmare, freezing display all the time, requiring power cycling. Nvidia works nicely and I don't really mind the bigger price tag.

<comment><USER6> It's probably done enough damage to their reputation in your estimation to not matter, but please note these Linux problems are specific to the Raven Ridge APU [1] - not the case using a discrete AMD GPU, the open source drivers for which are by many accounts absolutely superb these days.

It's a shame, I want a 2400G to replace my ageing A10 Trinity media box, will probably give it a try fairly soon expecting latest kernels have this solved by now...

[1] [https://www.phoronix.com/forums/forum/linux-graphics-x- org-d...](https://www.phoronix.com/forums/forum/linux-graphics-x-org- drivers/open-source-amd-linux/1045801-is-there-any-kernel-on-which-raven- ridge-cpus-are-stable)

<comment><USER7> Thanks for this information. I was planning a GPU passthrough setup using this - 2400G APU for the Linux display and an nVidia GTX 970 for passthrough, but this now makes me pause.

</comment></comment></comment></comment><comment><USER8> Usually the new XX60's are great because you get the previous XX70's performance at the lower XX60 price. This time you're getting the previous XX70 performance for the previous XX70 price...more than 2 years later. Weak!

<comment><USER9> Hey, it worked for Apple!

<comment><USER10> I think you're being sarcastic, but it actually has according to their revenue. They've hit their targets except for the weakened China market due to increased trade wars and volatility there. Because the economy is exploding due to the tax cuts, and the increased amount of disposable income, the price increases of Apple product hasn't seemed to affect them adversely.

<comment><USER9> Have you checked the stock price lately? $223 to $148 in a few months is no one's definition of good. Top company by market cap to getting passed by many of your tech rivals, not good either. It implies that just blindly raising prices on your products to increase profits only works so long.

<comment><USER11> All time highest quarter in US, this last quarter. all time highest.

</comment></comment></comment></comment></comment><comment><USER12> I refuse to buy Nvidia cards until they stop blocking drivers in VMs with passed through video cards. Yes I know, you can bypass the dreaded code 43, it's more on principle.

<comment><USER13> Interesting, never heard of this until now. A KVM maintainer seems to confirm this behavior too [1], albeit 3 years ago. Some newer anecdotes are around but it isn't clear if this is still happening [2][3]. (I used to virtualize the GPU via RemoteFx in Hyper-V many years ago and didn't run into this then. But now I'll have to give it another shot!)

[1] [https://www.reddit.com/r/linux/comments/2twq7q/nvidia_appare...](https://www.reddit.com/r/linux/comments/2twq7q/nvidia_apparently_pulls_some_shady_shit_to_do/)

[2] [https://www.reddit.com/r/VFIO/comments/5sh41p/any_other_reas...](https://www.reddit.com/r/VFIO/comments/5sh41p/any_other_reasons_for_nvidia_driver_code_43/)

[3] [https://www.reddit.com/r/HyperV/comments/5u2ge2/nvidia_consu...](https://www.reddit.com/r/HyperV/comments/5u2ge2/nvidia_consumer_card_passthrough/)

<comment><USER14> It's definitely still happening, however there are workarounds that bypass the driver's checks by changing hypervisor settings. One particularly insidious "feature" is that on the Quadro series of cards, which are ostensibly meant for this use case, it will disable some features if a VM is detected (in my usage, the displayport 1.2 support for 4k@60hz was not enabled until I enabled the workarounds)

<comment><USER15> The workarounds you mentioned didn't work at all for me (and reportedly for some other people too), on my GTX 680 or 1050m. Just a warning for those who may be considering buying a nVidia card and were given hope by exrook's comment...

</comment></comment></comment></comment><comment><USER16> Nvidia is sticking to the strategy of releasing the same GPU with RTX bolted on under a lower number and charging the same price for it... 2060 ($350) is very close to 1070 ($300), 2070 to 1080, 2080 ($800) to 1080 ti ($750). Edit: not the same same obviusly, but very similar in terms of benchmarks.

Doesn't seem like progress to me. With RTX being underpowered on current gen cards there's no real benefit in being an early adopter by buying this generation of graphics cards if you at all count the money you spend. Just find a used 1080 Ti, I say.

I think, Nvidia tries to pull an Apple and move the "premium" price tier up 500 points while curiously nobody in the press is calling them out on it.

<comment><USER17> Would you have been ok with them calling this a 2080 while keeping a $350 price tag?

Today, I see that a new 1070 Ti goes for $400+. This new RTX 2060 has the same performance for $350.

In other words: if you ignore the name of the product, the new product line gives you better performance and more features (RTX, tensor cores) for the same price than yesterday's product.

Is your only beef with the naming of the product? Why does the name matter?

<comment><USER16> The problem in my opinion is that in the past they would effectively shift performance down one SKU on each generation, and at the top you could get a 30% upgrade in performance for the same kind of money. Like the 980 Ti to 1080 Ti for example. Now you get marginally the same amount of performance for marginally the same amount of money.

It doesn't matter what they call it if the performance/money is what it is. I compare names because names meant a set price point going up to 10XX generation.

If you've got no use for RTX and tensor cores, those cards are very similar. RTX is available in one game only 3 months after launch, and what if I just dont want to be an early adopter? Tensor cores, yeah, if you're going to earn money or otherwise have your life improved by additional hardware in Turing, sure, it's a no-brainer. But I feel like it's not for many gamers.

Disclaimer: I'm not saying I am entitled to progress. I'm pointing out that it has slowed. I feel that this is similar to the lack of competition Intel was having. At least I'm thankful to Nvidia gods for making the higher performance card at all available, I guess...

<comment><USER18> > The problem in my opinion is that in the past they would effectively shift > performance down one SKU on each generation, and at the top you could get a > 30% upgrade in performance for the same kind of money. Like the 980 Ti to > 1080 Ti for example. Now you get marginally the same amount of performance > for marginally the same amount of money.

That's the exact problem with this generation. Before the top end (980 ti) became midrange (1070) for substantially less money. Now they just pushed the names up a bracket and kept (roughly) the same, and justified it by inventing a new "top end".

<comment><USER16> Yep, you get me. And this saddens me doubly because we saw the same kinda "upgrade" from $700 to $1000 in flagship phones not long ago and everybody was just as okay there.

Maybe it's the tariffs, or inflation, or some other thing that totally justifies this kind of sudden jump, but somehow not many press outlets acknowledge this jump at all existing, for them it's business as usual it seems.

My only hope is that consumers will react with falling sales. I'm sticking to my 1080 Ti for sure until the next gen.

</comment></comment></comment></comment></comment><comment><USER19> I really hope AMD can offer some real competition to Nvidia soon, right now NVIDIA is fleecing customers because they have no real competition. $350 for a mid-tier GPU is shameful.

<comment><USER20> NVidia stock has lost half their value since peak, if fleecing they aren't doing a very good job at it.

<comment><USER21> Personally I think the price explosion had two groups of people driving it: The first group, which I am in, believes nvidia with its proprietary CUDA will continue to grow its datacenter presence rapidly, and get some big contracts for field ML hardware. The second was looking for crypto exposure. The etherium bubble has mostly burst and it isn't profitable (probably hasn't been for a long time in most places) to buy nvidia cards for crypto mining. That and the trade war with China have taking half of the stock's overheated value off. It's still up quite a bit from ~$30 in 2016, and I think that reflects its real edge in ML hardware as well as some modest healthy growth in consumer gaming. I think, previously I assumed all the growth was from investors thinking like I was about their AI prospects and missed that I had picked a winner based on the crypto craze. I think a lot of smart money realized that and got out.

Disclaimer: was very long nvidia, sold a lot in the 200s and hold a lot less these days.

</comment></comment></comment><comment><USER22> I'm not very convinced.

Nvidia has been very commendable by breaking new ground with the RTX technologies, but it seems that at least ray tracing has a huge performance impact, therefore, I wonder how this card will fare, given its (relatively) low-level position.

Moreover, with the RTX series, Nvidia has "pulled an Intel": they raised the TDP for each model, so that they on generic (non-RTX) benchmarks, they look good, but they actually have a negligible performance per watt gain compared to the previous generation.

GTX x60 cards traditionally had fixed power requirements (6-pin); this doesn't apply anymore.

My suspicion is that GTX 11x0 cards (1160, 1150) are not yet showing, because Nvidia hasn't figured out a way to show a performance per watt improvement yet.

<comment><USER23> > My suspicion is that GTX 11x0 cards (1160, 1150) are not yet showing, > because Nvidia hasn't figured out a way to show a performance per watt > improvement yet.

My guess is slightly different - they know that the RTX technology isn't really there yet, and models that were just faster version of the current generation would probably kill any RTX sales.

Putting RTX on a 2060 is odd to me. The 2080 can't really run ray tracing at usable performance levels, I don't even want to know what it would look like on a 2060. There might be some more rounds of improvements coming to software, but are those enough to make it playable two tiers down?

</comment></comment><comment><USER24> If only NVIDIA would drop their expensive G-Sync and use FreeSync instead. That would eliminate the strongest reason right now to buy AMD (way larger selection of quality monitors).

<comment><USER18> Apparently you're a wizard, but don't let that go to your head.

[https://www.pcgamer.com/nvidia-brings-g-sync-support-to- free...](https://www.pcgamer.com/nvidia-brings-g-sync-support-to-freesync- monitors/)

</comment></comment><comment><USER25> How would this compare to my 980ti? It's been working pretty well for VR, but I've been wondering if maybe there's some value in upgrading soon.

<comment><USER26> This will be a little bit faster than the 980 Ti, as the 2060 is at the level of a GTX 1070 Ti, while the 980 Ti is bit slower than a GTX 1070. But I'd wait a generation longer, the jump is not worth it (if you don't get a great price when selling the 980 Ti).

</comment></comment><comment><USER27> I wonder if low sales numbers for the new generation of Nvidia cards will negatively impact the current and future development of the ray tracking tech.

<comment><USER28> Doubtful since the ideas behind ray tracing are very mature. Advances in real time ray tracing will take the form "x advancement in offline ray tracing from 30 years ago can now be done in real time."

</comment></comment><comment><USER29> It's still ridiculously huge.

<comment><USER30> It's not much different than any other Nvidia card. Dual fans, dual slot, it's probably smaller than some of the monster Radeon cards AMD used to make. They make smaller versions of some chipsets but what you lose in volume you lose in cooling.

<comment><USER29> That is true. To be honest, I'm still salty about some older OEM mobos I had to upgrade, which decided to crowd the PCI-e slots with capacitors. All that did was make the slots impossible to use!

</comment></comment></comment><comment><USER31> I'm still waiting for the AMD implementation of hardware real time raytracing. I don't trust Nvidia anymore concerning hardware quality, and the price is just ridiculous.</comment>


Chimps choose more rationally than humans - <AUTHOR> http://www.upi.com/NewsTrack/Science/2007/10/08/chimps_choose_more_rationally_than_humans/8872/

<comment><USER2> I may be wrong here but...

I dont think chimpanzees have a firm grasp on economics or even an analogous example; chimps don't think about spending banana's to make more bananas in the long run. Chimps arent thinking about trading banana's for shelter or safety or manual labor.

"In the game, a human or chimpanzee who receives something of value can offer to share it with another."

Also, from what I gathered from that article the people and chimps have to work to get something, then they can choose to share it. Why would they share? Person or Chimp? That would be real self-interest.

I mean if you are forced to make an offer and you know your counterpart is not as smart as you...let's say a chimp, you would be dumb not to offer less.

That's just my two cents.

<comment><USER3> It's hard to draw conclusions here, since there are important details left out in the article and there was no link to the actual paper.

While I can't argue for comprehension of economics by chimps, I think chimpanzee have a grasp of how to cooperate with others in order to ensure their own survival and after that, the survival of their offspring. If they didn't, I don't think they'd live in social groups. Therefore, they should have comprehension about sharing and giving.

So the result could be an indication of how much cooperation is required to survive in a particular chimp society. But even then, I personally wouldn't be so quick to jump to that conclusion, because something like cooperation is learned (I have no proof, but I can't imagine one knows how to cooperate from birth), and different troupes of animals have different learned cultures, even within the same species--especially if they are social animals.

Animals have culture--i.e. knowledge and behaviors passed from generation to generation through learned experience. There are two cultures of Killer Whales, but they are genetically the same species. One culture beaches itself to hunt seals and the other eats fish only. You can probably find video footage on youtube of a mother training its young to beach itself for seals.

Only specific cultures of apes know how to crack nuts with rocks and others fish ants out of trees. Only the macaques in japan wash their sweet potatoes before eating them.

The last case is also interesting because the exact moment of that particular innovation was observed by Japanese scientists back in the 50's. A young macaque named Imo found that she could solve the annoying problem of sand in her sweet potatoes by washing them. The scientists found that the innovation spread from Imo to her mother, and then through to her playmates. The last to adopt potato washing were the males--especially the high ranking males.

Amazingly, that wasn't the last innovation Imo had. She also learned to separate sand from wheat by throwing it into water (wheat floats, sand sinks), instead of picking it out one by one. This behavior has also spread to the other macaques in her troop. I think they all still do this to this day.

So besides that tangent about animals having culture, if cooperation is indeed learned and passed from generation to generation, I think it'd be premature to say that ALL chimps are more selfish in their cooperation. One might only be able to claim some--and from a particular troupe.

</comment></comment><comment><USER4> That depends on the number of rounds. Granted with one round you should accept anything. But, if you have more than one you can set a minimum bound and punish people who give you low bids.

AKA Round 1 accept 10% Round 2-100 accept 1%? vs. Round 1 reject 10% Round 2 reject 25% Round 3 reject 40% Round 4-100 accept 50%</comment>


Google Payments API - <AUTHOR> https://developers.google.com/payments/ <comment><USER2> [https://stripe.com/docs/pay-with-google](https://stripe.com/docs/pay-with- google)

Looks like Stripe supports it. The name is a bit different, but this is probably just Google being Google.

<comment><USER3> Android Pay, Google Pay, and Google Wallet (I think) are all pretty much synonymous.

</comment></comment><comment><USER3> I've been waiting on this since July, when we implemented Apple Pay at edX. They missed the advertised September deadline. Despite signing up for the mailing list, I have yet to be notified about the functionality. Now that I'm seeing all the press about it, there still seems to be no way to register as a merchant. This is quite disappointing.

<comment><USER4> Sounds very... Google-y. I love Google but I don't plan on wasting any of my time integrating with their tech anymore.

</comment></comment><comment><USER5> Before I get my hopes up.. Is this "only for US" (and a small number of countries)?

<comment><USER6> Under the section about the rules

> The following terms apply if you access or use the Google Payment APIs in > Central America, South America or China: ...

I'm no lawyer but this seems to imply that it at least includes those regions.

<comment><USER7> It is a shame that there is no clear information regarding this. I am in Costa Rica (Central America) and would love to use this here.

<comment><USER3> Ultimately, acceptance depends on who is processing your payments (e.g. Stripe, Adyen, CyberSource). All Apple/Google Pay do is take advantage of tokenization, which allows buyers to send merchants a token/pointer to an account rather than a real credit card number. Every transaction gets a different card number to minimize risk in the event of a data breach. Additionally, both services make it really easy to checkout by providing a simple method to provide the billing/shipping address in addition to the payment info. No more typing. Just click the appropriate pay button, and confirm payment with your fingerprint/passcode on your phone.

Here is a demo I created for edX: [https://www.youtube.com/watch?v=axTCbUjWcbI](https://www.youtube.com/watch?v=axTCbUjWcbI)

<comment><USER7> Oh ok, thanks for the detailed explanation!

</comment></comment></comment></comment></comment><comment><USER8> If the purchase is for digital goods, would it need to be for Google Play in- app billing, whereas if the payment is for physical goods, then it qualifies for Google Payments API?

What does a subscription for a membership for physical and digital goods fall under?

Thanks for the pointers.

</comment><comment><USER9> This must be the 5th Google money API/interface to date. It doesn't seem like they learned from the previous attempts.

<comment><USER3> I haven't used Google's previous implementations, and I'm bummed I still can't use this one. I have high hopes for this implementation because it is written to comply with the W3C Payment Request API ([https://www.w3.org/TR/payment- request/](https://www.w3.org/TR/payment-request/)). Microsoft and Mozilla are also working on implementations. Apple Pay for Web follows a very similar API. As a developer who deals with payments this makes my life a lot easier as I can create a single implementation that enables users of almost every major browser to take advantage of speedy checkout.

</comment></comment><comment><USER10> I think this will _substantially_ increase conversion rates. My experience with it as a customer was that I paid for something I otherwise wouldn't have, because I didn't have to input my credit card info.

<comment><USER11> I feel this all the time. Especially for flights, I will pay like $20 bucks extra if I can buy using Google Flights and don't have to go through the slowness, upselling, and credit card entry of the airline's site.

<comment><USER12> Do you fly for business or otherwise fly a bunch? I 0-3 times a year, typically for vacation, and I am extremely price sensitive. I'd gladly spend 5 minutes on the airline's website to save $20.

</comment></comment></comment><comment><USER13> How does this relate to Android Pay? Is Android Pay deprecated?

<comment><USER14> This is an implementation of the W3 Payment Request spec I believe: [https://www.w3.org/TR/payment-request/](https://www.w3.org/TR/payment- request/)

They talked about it at Google I/O earlier this year: [https://www.youtube.com/watch?v=hU89pPBmhds](https://www.youtube.com/watch?v=hU89pPBmhds)

(I believe this is how it works, I could totally be wrong here, I haven't read on it too much).

This is a way of using forms of payments people have stored with Google (cards added for Play store, android pay, or other services) to pay for things with from merchants. The payments don't route through Google, rather it pulls the card details from Google and send them to whatever merchant you are buying from.

EDIT: This is useful: [https://developers.google.com/payments/mobile-web- tutorial](https://developers.google.com/payments/mobile-web-tutorial)

It looks like websites can request data back as a Gateway_Token (to then run through Adyen, Stripe, Braintree, or Vantiv). Or you can setup a public/private pair[0] and Google will send the card details back of as an encrypted bundle that you can decrypt in a PCI compliant environment.

(disclaimer: I work on payments at Google, opinions are my own. I didn't work on this feature and don't really know anything about it).

[0] [https://developers.google.com/payments/payment-data- cryptogr...](https://developers.google.com/payments/payment-data-cryptography)

<comment><USER15> Does Google see the merchant you're paying?

<comment><USER14> See[0]. The "Pay With Google" initiative is adding a 'supportedMethods' of '[https://google.com/pay'](https://google.com/pay'). What is then in the data section of that supportMethods call to Google is up to Google, which is specified here[1]. It looks like Google required "merchantId", which the merchant registers with Google to get access to the cards Google has stored for that customer.

So yes, if a merchant wants to use a customer's card on-file with Google to pay at a merchant with "Pay with Google", Google will be able to connect the 2 dots together, but I'd read the ToS to see what is allowed[2].

The value-add here for merchants is to get customers to complete a purchase without having to go through the pain of typing in their card details. And for consumers, if they don't fully trust the website and the website is using Gateway Tokenization, then the merchant never sees the credit card data.

[0] [https://www.w3.org/TR/payment-request/#the-methoddata- argume...](https://www.w3.org/TR/payment-request/#the-methoddata-argument)

[1] [https://developers.google.com/payments/mobile-web- tutorial#a...](https://developers.google.com/payments/mobile-web-tutorial#api- parameter-list)

[2] [https://payments.developers.google.com/terms/sellertos](https://payments.developers.google.com/terms/sellertos)

</comment></comment></comment></comment><comment><USER16> I've read through this several times and I'm still confused. How does this relate to the Payment Request API? Or Google Wallet or Android Pay?

</comment><comment><USER17> I don't get. I really don't. I think I've looked everywhere but I can't find it. What's the pricing?

<comment><USER18> This is more low-level than that. This is an API to retrieve payment details, not to process an actual payment. You'll want to use Stripe or the like for that.

<comment><USER17> Thanks. So it's for people looking to build their own Stripe?

<comment><USER19> It is for app and web site developers that want to accept credit cards through the new Payment Request API. The backend would process the credit cards with their usual payment processor. The payment API is easier for users since Google remembers credit card details and they don't have to type them into a form.</comment></comment></comment></comment>


AAPL is now worth more than entire US energy sector, stock up 66% year to date - sahin-boydas https://9to5mac.com/2019/11/15/aapl-is-now-worth/ <comment><AUTHOR> I know this is FUD but I get spooked by massive returns without anything magnificent or game changing behind them. How much of this is riding the recovery from last year's trade war uncertainty, and how much is this people banking on Apple TV+? Especially with declining iPhone sales and imo, decline in the quality of their products/services, potential regulatory issues depending on the election... that 66% is really spooky.

<comment><USER2> Certain stocks are more hype driven than anything. Tesla, Apple, Netflix etc... A couple of bad things happen and watch the stock fall pretty fast, a couple of good things happen and watch the stock rise up really fast. I think for some of these companies stocks don't really measure anything other than hype. Beyond Meat is a good example, stock price went crazy cause "revolutionary meatless concept", started from $40 dollars and went to like $200 bucks in a month or two, now hype has died down, its back down to $80. It is still a solid company judging by their earnings report but people have now lost faith because the hype died down.

<comment><USER3> Apple is worth something like 1.1 trillion dollars , I assure you there is more to it than hype</comment></comment></comment>


Ask HN: Where have you found your startup colleagues (friends)? - <AUTHOR>

I have a startup idea and I don't want to work on it alone. I miss analysis, discussion with someone who has same opinions, but different point of view etc. The problem is I just don't know anybody who would like to work on it with me or just discuss about it in private with skills I need (programming, startup awareness). How did you find your programming friends and colleagues in your startup? I don't mean hiring, but a friend.
It's not as funny as it used to be at the beginning after a while when you work alone. So the question is? Where did you find your programming, startup friend?
For those of you who would like to work with me on a project which in final stage will work with search engines and affect daily internet experience of a internet user (search experience, bookmarking much more different as we know it now) you can always send me an e-mail or contact me via GTalk. I'm 21 years old programmer who loves to hack in Python and use Django,jQuery for the web stuff. That's why I prefer people with Python/Django, jQuery skills.
Anyway, I'm still glad for each opinion and advice. <comment><USER2> I met my previous cofounder for our last startup through a mutual friend long before founding the company together. We were introduced to each other base on the fact that we were both so business oriented and our friend just wanted us to meet. A few years later, an opportunity for a business idea came up and we decided to partner up. The company was later acquired and we decided to pursue different interests after but still keep in touch practically every day .

In hindsight, natural settings of meeting someone who have similar interests to you either through friends, work, college, etc... is much easier to find compatibility as cofounders than actively hunting down strangers at meetups hoping to find a cofounder that will work well with you. I believe PG or someone else mentioned something about how if the only reason you guys are together is to work on this startup idea and nothing else, there's really nothing holding you together and there is a higher risk of failure (not in those exact words).

The other problem you'll be facing too is that you're trying to sell your dream to someone else which is harder than joining someone else on their dream. Most people from what I've seen wants to work on their ideas rather than the ideas of others. Of course there are those that do join on with someone else's idea but for the most part, people you run into at cofounder type events are mostly biz guys looking for a technical guy to execute on their idea. It's really hard to find a compatible "friend" you can call a cofounder outside of just your startup dreams.</comment>


James Cameron on "Avatar 2″ and the Impending Environmental Crisis - <AUTHOR> http://mashable.com/2010/10/29/james-cameron-eric-schmidt/

<comment><USER2> Let's try to take apart this muck, which I seem to have read a hundred times before:

> we're becoming disconnected from nature and that we are on a precipice.

Why is it bad to be disconnected from nature? What's wrong with going in the opposite direction towards increased artificiality, given that our very artificial infrastructure keeps us alive?

> take control over our stewardship of our planet / the planet [...] will be > in significant danger

What the heck does that actually _mean_? Can we just admit that these statements are religious, but wrapped in non-religious language?

> 70% of species will be extinct by the end of this century if we do nothing > due to the rise of world temperatures

I wish it were as fashionable to care about runaway AIs, nuclear attacks, geologic events, etc.

<comment><USER3> You're not worried the world seems to be shifting under our feet because of us simply doing what it takes to live?

If you were a programmer adding an extra feature to an existing system, and after a few days work you realize that 90% of the system has been modified by you in some way or another, won't you be alarmed?

In 200 years, many species have been driven to extinction by our activities, entire forests were chopped away, and countries are now sinking due to rising ocean levels "<http://en.wikipedia.org/wiki/Maldives>, and you're still not worried?

It's fine to be "disconnected from nature", as long as everything can keep going the same way, but _I don't think they can_. Our own artificial infrastructure is like a ponzi scheme, requiring ever increasing amounts of resources to support it. Until you can find a way that it'll support itself without killing everything around it (I'm not exaggerating, your roof is a desert.), it is not sustainable.

<comment><USER4> Sorry but the Maldives is not sinking. They mustn't be too concerned, having just built a new runway. There are several trees that exist just inches above the high tide mark which are at least 50-100 years old.

There has been erosion in the Maldives due to changes in use, but erosion != sea level rise.

I also challenge anyone to nominate 1 single species made extinct in the past 50 years as a result of climate change. Note that you must be able to attribute the sole or overwhelming cause of extinction to a change in the average temperature, and not through habitat loss, local pollution, overhunting or any other myriad of ways that humans wipe out species.

edit:typo seal->sea

<comment><USER5> I for one would be happy to see more seals in the Maldives ;-)

<comment><USER4> yes, those pesky seal level rises. Fixed now:)

</comment></comment></comment></comment></comment><comment><USER6> I loved Avatar, but I've noticed a strong theme from Hollywood for over a decade now of environmentalism. It's either the subtext, subplot in the 90's movies, and now it's become the main context and plot of major movies in the 00's and I'm getting the strong feeling I'm going to be beaten to death with it in the 10's.

I think one of the reasons I've gone from liking the Harry Potter film series to outright loving it is because environmentalism isn't even a sub-subtext in the story. The plot is that humans are doing incredible damage to humans, not that humanities inactions are inevitably going to hurt us by some bullshit catastrophe like 2012 or the day after tomorrow.

This bullshit enviro-paganism has driven me to the point of not giving the slightest damn anymore. If you tell me we've got a program error from monday to friday, but you offer no solution to fix it except to spell check the code (recycling) then I'll tell you to fuck off by the next monday. If you offered a major rewrite I'd buy in. Double-down on Fusion research, go all nuclear with new power plants (it's the only practical and realistic way, if you deny it you're ignorant of the massive wastes inherent in solar and wind systems and the fact that many of these systems rely on the existing coal and gas infrastructure to support it in low-wind or cloudy periods).

We're being told we've changed the world disastrously through our inactions, then we should be showing the world we can change it through our actions. Sequester carbon, go nucelar, build a frigging IR reflector in space, build cloud machines.

I find it more disturbing that environmentalists are flat out ignoring the disastrous effects caused by wind turbines, killing bird and especially bat populations and promoting demineralization of farm land (note this is the preliminary step in desertification). Not to mention that there's already been noticeable wind-speed decreases in areas of heavy wind turbine usage. I think interfering with the wind patterns is going to fuck up the planet far more than a little CO2 as you'll actually be creating high and low pressure regions _permanently_.

<comment><USER7> Lots of factual errors here.

Solar and wind can make very large impacts on electricity generation - see the Desertec website for lots more information: <http://www.desertec.org/>

Research has shown that geographically distributed renewable generation can be used as reliable base-load, although I can't find the reference at the moment.

The CO2 payback times for various technologies are shown here: <http://www.envirowiki.info/CO2_payback> , although this does miss out other payback times that are relevant.

Winds and pressure regions around the world are primarily caused by temperature contrasts between the poles and the equator, and between land and sea (due to water having a much larger thermal inertia than land). Huge numbers of wind turbines will not effect this in any way.

Modern wind turbines kill very few birds, orders of magnitude less than cars and window collisions (<http://www.treehugger.com/files/2006/04/common_misconce.php>). Older wind tubines have faster rotational speeds which kill more birds than modern turbines.

Bats, again, are not effected too much by modern wind turbines as the blades are are sufficiently high above the ground that bats will never come into contact with them, as bats rarely fly at high altitudes (see PDF linked from [http://naturalengland.etraderstores.com/NaturalEnglandShop/T...](http://naturalengland.etraderstores.com/NaturalEnglandShop/TIN051)).

Please, don't rant unless you know the facts.

<comment><USER8> Do windmills kill "huge numbers" of birds? Wind farms recently got adverse publicity from Norway, where the wind turbines on Smola, a set of islands off the north-west coast, killed 9 white-tailed eagles in 10 months. I share the concern of BirdLife International for the welfare of rare birds. But I think, as always, it's important to do the numbers. It's been estimated that 30 000 birds per year are killed by wind turbines in Denmark, where windmills generate 9% of the electricity. Horror! Ban windmills! We also learn, moreover, that traffic kills one million birds per year in Denmark. Thirty- times-greater horror! Thirty-times-greater incentive to ban cars! And in Britain, 55 million birds per year are killed by _cats_.

\--David MacKay, "Sustainable Energy -- without the hot air".

[http://www.inference.phy.cam.ac.uk/withouthotair/c10/page_63...](http://www.inference.phy.cam.ac.uk/withouthotair/c10/page_63.shtml)

<comment><USER4> So what you're saying is that it's OK to kill birds as long as you're 'saving the planet'? Because that's how it reads to me. I'm shocked that environmentalists support wind power with the large ecological footprint it has. Plus you have to build baseload power to back it up, so it's not like you are stopping the construction of fossil fuel plants.

It just seems like a gigantic waste of resources to me.

<comment><USER8> That's a rather provocative interpretation of what I posted. I was merely pointing out that the birds thing is a relatively small issue, and if you really care that much about them you'll have to sacrifice much of the modern lifestyle.

For what it's worth, the book I quoted from (link in my previous comment) is (in my interpretation) fairly skeptical of wind power. I highly recommend it: It looks at the issues in a balanced manner, with extensive figures and calculations, and without resorting to sensationalist language like "it's OK to kill birds", or putting sarcastic quotes around "saving the planet" to imply naïvety of anyone who dares to disagree.

</comment></comment></comment></comment></comment><comment><USER9> What is it about hollywood that makes people who work there think they are qualified to speak about technical matters?

70% of species? Seriously? That's just pure nonsense.

<comment><USER7> The IPCC 4th assessment report states that greater than 40% of species are likely to be extinct given a temperature increase of ~3.8C, with 30% of species at increasing risk of extinction given a temperature increase of only ~1.5C.

A rise of 1.5C is certain to happen by 2100, even in the best case scenario where emissions peak soon; and a rise of 4.0C is depressingly likely given the current continuous rise in emissions.

See pages 22, 23 and 29 of the synthesis report: <http://www.ipcc.ch/pdf/assessment-report/ar4/syr/ar4_syr.pdf>

I would recommend everyone reads this report; it's not too long, and I found it very readable and succinct.

Given that we're all going to be affected, isn't it worth knowing the facts about this stuff?

<comment><USER10> Also readable online at [http://www.ipcc.ch/publications_and_data/ar4/syr/en/main.htm...](http://www.ipcc.ch/publications_and_data/ar4/syr/en/main.html)

I would assume this is where the 70% came from: _"[...] As global average temperature increase exceeds about 3.5°C, model projections suggest significant extinctions (40 to 70% of species assessed) around the globe."_ [http://www.ipcc.ch/publications_and_data/ar4/syr/en/mains3-4...](http://www.ipcc.ch/publications_and_data/ar4/syr/en/mains3-4.html)

<comment><USER11> > 40 to 70%

That's one heck of a margin of error.

</comment></comment></comment></comment><comment><USER12> I'm a movie junkie and a Cameron fan -- at least until Avatar. Plus I love startups and business issues.

James is part of this interesting movement by performers to insult and preach to audiences. At some level, we all want to be challenged by art -- art should take us places and make us look at ourselves in ways we haven't before.

But, in my opinion, what's happened is that art has ran out of ways to easily challenge us. This has led to the development of sort of a religion -- people are selfish and harmful, the planet is in danger, we must wake them up in order to save our children.

Not getting into whether that's a good worldview to have -- there are many pros and cons -- the problem here is that this particular religion, like all religions before it, has become rigid and predictable. That hurts the art, and it hurts the business.

Avatar was a wonderfully visual film -- and an example of a movie I don't want to see again. It was preachy and trite. The plot was about as dumb as possible. But damn, it was gorgeous. I bought the first disc I could when it came out. And it's still sitting unwatched on the shelf.

When you cross the line from art to preaching, from sharing experiences to moralizing, the art suffers.

I am also fascinated by this propensity for famous entertainers -- basically our version of a high-paid circus clown -- to insult the people that are buying tickets to their attractions. James isn't as direct about it, but underneath all of this the message is clear: you are a mindless consumer and your lack of concern and selfishness is destroying the planet. You're a selfish asshole. Give me some more money and I will say it in a different way. That's got to be the weirdest business model I've ever seen.

<comment><USER4> The most odious part of Cameron's carry on is the way he travels to remote villages in South America and parades them around like sideshow curiosities in tribal outfits. He implores us to leave them be, leave the noble savage alone (this is also the underlying message from Avatar, as I understand it) He never asks them if they'd like a refrigerator for food and medicine, an air conditioner or some roads built to increase their access to civilisation. Instead, they are just assumed to be more pure, a better way of living than the rest of us, and morally superior as a result. But nobody ever asks the villagers what they think. They're just told to stand there in war paint and look at one with the forest.

I haven't seen Avatar because once I saw the plotline I couldn't bear to sit through it. It's bad enough trying to watch a decent U2 concert these days without all the preaching being folded in.

Then there was the highly publicised event where Cameron was going to call 'high noon' on some bunch of climate change skeptics at a public debate. I think it was at an environment conference or film festival or something. But as the date approached he asked to have the rules changed many times before pulling out altogether. I'm sure the reason is not to give the skeptical point of view any airtime, but it just makes him look foolish and clumsy.

<comment><USER13> _He never asks them if they'd like a refrigerator for food and medicine, an air conditioner or some roads built to increase their access to civilisation._

Um.. most of the natives in South America are losing out to clear-cut logging. I'm not sure how a refrigerator is going to help that.</comment></comment></comment>