Angular 2 versus React - <AUTHOR> https://medium.com/@housecor/angular-2-versus-react-there-will-be-blood-66595faafd51 <comment><USER3> To me it really feels like Polymer is taking all of the pros from both of these "libraries" or "frameworks" or whatever you want to call it and none of the cons. Why aren't we talking more about that? Polymer is a fraction of the size. It's one of several ways right now to write custom components. React and Angular2 do the same thing yet they are both bloated and force tons of tools and tech down your throat. For what?

Sorry, no. My 2016 isn't going to come down to me deciding between React's perverted DSL and crazy toolchain or Angular2's massive cluster$&!% of a bundle with cringe-inducing template syntax. No thanks.

I have followed this long enough. To a lot of people, adding Flux, Webpack, TypeScript, whatever, might seem like the beginning of the future of front-end development, but I see something different. I see 2016 as the year that people slowly begin to realize that while components ARE the future, you don't need big frameworks or libraries or 4000 node modules. This is the year of pure, well-written, and fast web apps. This is the year of framework fatigue.

<comment><USER4> Why did Google create Polymer? Google isn't using it. This is almost the same 'problem' with "AngularJS by Google", it's almost never used by Google.

Edit: The reason I like React more is the fact that Facebook uses it in a high traffic production setting.

Edit 2: I think the whole Javascript (or framework) fatigue is just a 'transition problem'. Old tools are getting replaced by new tools, causing confusion..

<comment><USER5> YouTube Gaming & the new Google Play Music are both built with Polymer, both moderately complex consumer facing sites.

<comment><USER6> Google Play was poorly made

[https://play.google.com/store/apps/developer?id=itdisplayswh...](https://play.google.com/store/apps/developer?id=itdisplayswhateversattachedtheid)

<comment><USER5> Kinda beside the point, and I'm not sure the play store is using the same tech stack as play music. Two different things

</comment></comment></comment></comment></comment><comment><USER7> > _Sigh. Yes, Angular is a framework, React is a library. Some say this > difference makes comparing them illogical. Not at all!_

Agree. This BS "oh, it's like comparing apples to oranges" knee jerk reaction should stop.

For one, even if Angular is a superset, we can always compare the parts that both have: component model, templating, etc.

Second, when we say React we almost ALWAYS mean React + Router + some Flux lib, etc. -- so all the same things you get with Angular, just cherry picked.

Third, we can just as well compare Angular (or any framework) with building something from scratch with vanilla JS too. Nobody said we have to compare them "as frameworks". We can compare them as different "ways get a web app done" (with/without framework, without framework but with x lib, etc).

Fourth, we can always compare apple's to oranges. Here's a comparison: oranges have more vitamin C than apples, and are better for scurvy (haven't checked the actual vitamin C stats, but you get my point).

<comment><USER8> Can you use Angular's components & templating outside of the rest of its MVC architecture? Despite the insistence on HN that React = React + Router + Flux, I've been using just React with plain js objects for models, and I like it exactly because it's an easier way of writing simple interactive views.

<comment><USER9> What if it can't? (I don't develop apps using Angular, so I really don't know the answer...)

Then it's just a con for Angular, but also a pro for providing a default MVC architecture to rely on. It's a design choice that can be both good and bad.

</comment></comment></comment><comment><USER10> This is continuing to shape up to be another one of those preference debates.

I prefer the Angular approach, as its end goal is to simply make web markup what it should be: Interactive. The downside being that you're forced into Angular's opinions for better or worse.

I don't prefer the more "tangled" approach of React. I call it tangled as it's mixing two flavors in one "view", whether you like it or not: JS and HTML. Many people like the approach, and I can see why they do. I don't.

Those are preferences. So much more goes into making an app efficient, testable and expandable. The biggest ingredient is comfort. If you and your dev team are comfortable with React, that's going to be your best option. It's not the wrong option, it's a great option. For me, it's Angular.

However, I feel compelled to say that the debate should be Angular 2 v React. Having used others (... Ember....) it just doesn't make much sense to use anything outside these main 2 contenders unless you're using some of the new "cool" web components based stuff. Angular is solid. React is solid. Compare, contrast and make your decision based on how comfortable you feel with the getting started docs.

<comment><USER11> > I call it tangled as it's mixing two flavors in one "view", whether you like > it or not: JS and HTML.

Doesn't Angular mix HTML and JS too, except in the HTML file?

<comment><USER12> > Doesn't Angular mix HTML and JS too, except in the HTML file?

Angular2 doesn't. Like React it uses a HTML-like templating syntax to generate views. Nothing is mixed in Angular2, everything is defined in JS and rendered as HTML.

</comment></comment></comment><comment><USER13> React's learning curve is _tiny_ compared to Angular. With React, you need to understand the component API, which consists of about 5 methods that one uses regularly, and the top level API, which consists of 2 (or just 1 if you use ES6 class syntax to create components).

And as the article points out, it's just JavaScript.

<comment><USER14> When you factor in the learning curve of the usual tools that go with React like Flux/Redux, Webpack, Router and whatnot, the combined cognitive load becomes a lot.

<comment><USER15> Yeah, additionally React has a serious paradox of choice problem.

Which of the dozens of CSS solutions should I use? Inline styles or not? Which of the dozens of Flux libraries? Isomorphic/universal or client side? If Isomorphic, Express or Koa? Does react-router work with the choices I've made? Webpack or Browserify? It goes on and on...

I love React, but the environment and best practices are unclear to say the least.

Just look at how many starter kits there are and how big they tend to be: [http://andrewhfarmer.com/starter-project/](http://andrewhfarmer.com/starter- project/)

Can only imagine how many of the choices made are going to be deprecated in a couple months.

Edit: Heh, and now that I've read the article, I see they hit on this issue. :)

<comment><USER16> There is also a lack of best practices, combined with constantly breaking changes. Every tutorial before the last month is already outdated, and everybody has a different way of setting up webpack / isomorphism / templating.

<comment><USER4> >lack of best practices

How many 'best practices' do you need? What about 'higher order components'? Use proptypes in development? 'Avoid local state'?

>constantly breaking changes

I call bullshit, what was the last breaking change? Every large release still supports the old deprecated syntax, but with warnings.

>Every tutorial before the last month is already outdated

That is a big exaggeration; I wouldn't advice anyone to use 'pre es6' tutorials, but the concepts still apply.

>everybody has a different way of setting up webpack / isomorphism / templating.

No they don't, maybe a small differences and what do you mean with 'templating'? It's not Angular.

<comment><USER17> I call bullshit on you calling bullshit on every point of this comment.

> How many 'best practices' do you need?

Actually, there should only be one way to do something in a framework. While not a framework, think about the Go language. Go is a very strict, almost paternal language that 'enforces' best practices in the language itself by giving you only one way to do something. Angular, on the other hand, provides numerous ways to create a service. Because of this confusion, the Angular team provides best practices. It's like saying, 'we screwed up in designing this thing, so you have to read all the documentation to find out the subtle differences in all this bullshit.' It's not the lack of best practices that concerns me, it's the abundance of them that gets shipped with a bloated framework that wasn't designed well.

>Every large release?I seriously doubt it.

Think of all the pain involved in removing all of the digest cycle code when switching from Angular 1.4 to Angular 2.0.

> No they don't, maybe a small differences and what do you mean with > 'templating'? It's not Angular.

Seriously? There are no small differences between Django templates, Soy templates (client and server side), and Angular templates to name a few. They are all very different yet they do essentially the same thing. At least Soy templates can be used outside of a framework (with either JS or Java).

<comment><USER4> My comment is about React. I am not defending AngularJS.

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> Or, much shorter, Angular is creating an inner platform [1], and React is extending the platform that already exists to do more work.

[1]: [https://en.wikipedia.org/wiki/Inner- platform_effect](https://en.wikipedia.org/wiki/Inner-platform_effect)

</comment><comment><USER19> If anyone is new to both frameworks Angular 2 or React; I would prefer React. I have learned React in a day. I can use my existing knowledge of js in React (for, if etc), whereas in angular learning those directives is still a pain (in Angular 2 as well).

I love the fact how each component in React can be composed! Its just beauty!

<comment><USER20> What other tools do you use alongside it?

<comment><USER21> Not OP but...redux and react-router, both mentioned elsewhere in the thread, and both maintained here: [https://github.com/rackt](https://github.com/rackt)

</comment></comment></comment><comment><USER22> There are some slight inaccuracies here, such as file size reporting - <USER2> 2 is fat at the moment only because it is bundling the whole kitchen instead of just the one piece that is the library itself. The Angular 1 number also is off too - this link is giving me 52.8 KB for example (minified + gzipped): [https://ajax.googleapis.com/ajax/libs/angularjs/1.5.0-rc.0/a...](https://ajax.googleapis.com/ajax/libs/angularjs/1.5.0-rc.0/angular.min.js) (all numbers I remember seeing for angular 1 were around 120 KB IIRC). I'd suspect all the other numbers are off too, but I haven't investigated.

There is a strong argument against doing what JSX does in moving the HTML to JS - you allow developers to fall into the trap of creating complex conditional DOM that is hard to read without a disciplined team (if statements all over the place with imperative DOM construction for example). Neither approach of JSX or Angular's templating (or any other similar system to either) are without its warts, and this falls into an opinion discussion without real winners excepting for however a particular team prefers their templating.

One thing that wasn't discussed but that may come into play - the performance numbers out there for Angular 2 currently is extremely impressive. Optimized Angular 2 code is generally performing at about 2x the rate of other frameworks/libraries out there for UI rendering/repainting, and unoptimized Angular 2 code is performing at roughly the same parity as optimized React code (although optimized/unoptimized React code performs very similarly in many situations, which is a huge benefit of React).

I'm personally on the Angular side of the fence, I prefer the more declarative style to avoid the imperative DOM construction, but I could work with either (and have worked/am working with both) if they are done right. Both are impressive libraries though, and both have strong merits - at the end of the day, it comes down to how your team works, and what they're productive with. Both libraries are bringing excellent changes to how we do things in the frontend...I just wish tooling was there in maturity, that seems to be the greater pain point currently.

<comment><USER23> > I'm personally on the Angular side of the fence, I prefer the more > declarative style to avoid the imperative DOM construction, but I could work > with either (and have worked/am working with both) if they are done right.

If by _declarative_ , you mean artificially limiting, then I agree with you, but in my humble opinion, the React approach allows for far more declarative UIs than approaches that come before it.

Templates ultimately limit UI semantics to the subset designed into the template language. Modeling the DOM as a pure JS data structure gives you the entirety of the expressive power the JS programming language, and allows you to construct your UI as a pure declarative mapping between components/elements and your app state (the approach taken by Redux and many ClojureScript frameworks), with no imperative manipulation whatsoever.

<comment><USER22> React uses an imperative style, not declarative - when one uses this.items.map(item =>
{item.name}
), this is imperative, not declarative. You are describing the DOM with imperative language - JSX cloaks what is truly an imperative nature. This is made more clear with the non-JSX equivalent. When one uses an if else-if else, while, switch, or other similar control flow statements, one departs from describing, to imparting the details of the implementation. The only part declarative about JSX is the conversion of certain code into valid text/attribute values/etc. into the HTML, which I'd hope is a minimum requirement of a useful templating language.

Angular's templating is clearly declarative since one is not making a statement about how it arrives at its result, but purely describing it and leaving the implementation elsewhere. Something like

{{item.name}}

 leaves the iteration implementation away from the view completely. Every piece here is descriptive, not something more.

It should be noted that Angular 2's DOM model uses an AST under the hood, just like React - fundamentally they are the same in the virtualization of the DOM. Angular 2's templates are not true HTML either, but is closer to HTML than React is in its syntax. It does limit what you can do, but that is the purpose of templating languages - it limits what you can do to increase readability, increase consistent patterns, and steer users away from dangerous usage. That is an argument aside from declarative vs. imperative templating, and more emotional than useful.

Now, both approaches have obvious flaws - both styles are easily (and often) abused, but both also have simple conventions to keep it clean. Imperative construction (ala React) requires one to carefully organize the control flow to avoid convoluted template construction. Declarative construction (ala Angular 1 + 2) requires one to avoid tossing too much in a singular template. What is easier to work with, that is not for me to say as an absolute, but IMO carefully organizing the control flow in template construction requires more mental overhead to avoid constructing the template in a hard to read fashion, and yet still involves the same ultimate basic strategy of having to create separate components to avoid overly complex templates, which is what one has to do with declarative template languages, but without the mental overhead of accidentally abusing control flow in its construction.

<comment><USER24> A pure functional map is imperative?

Defining UI as a functional map of the state is the one of the most declarative ways of viewing the problem, IMO. Templates are maps too. The problem with templates, historically, is that they've been used only for the initial state, and abandoned for later changes because rerendering is expensive.

</comment></comment></comment></comment><comment><USER25> The foolish, totally avoidable, misguided and completely pointless mistake that Angular 2 made was using a template syntax that was almost but not quite completely unlike HTML:

            {{hero.name}}

or:

        <web-component [title]="exp1" (close)="exp2()">

That is INVALID html and INVALID xml. That means you can't edit or process or generate or validate Angular templates with any of the millions of existing HTML and XML processing tools. They have completely forsaken the entire universe of existing tools, for no good reason.

The Angular 2 template language gets absolutely zero benefits from arbitrarily disobeying HTML syntax. There's nothing about the broken syntax that makes it any more powerful or tangibly convenient that could be done by an HTML or XML compatible syntax.

Maybe it appeals to Perl brogrammers, but the hip stylish syntactic appeal of peppering templates with unique special snowflakes of punctuation like they were so many christmas tree decorations does not outweigh the dire consequence that you can't use an off-the-shelf HTML editor to edit and preview templates, or use any of the many other existing HTML tools to do whatever they're designed to do.

I've encountered Angular 2 proponents who were such blind zealots that they actually refused to see any benefits of sticking to standard syntax and enabling the use of existing tools. They would ask things like "why would you ever want to edit an Angular 2 template in an HTML editor?" or "why would you ever want to generate a template from another meta-template?" or "why wouldn't you want to write your own Angular 2 template validators and editors and processors?" or "why wouldn't you want to retrain all of your html designers who can't use the tools and syntax they're accustom to?"

Yet they were still unable to name any tangible benefits of the broken Angular 2 template syntax, that couldn't be achieved with a non-incompatible HTML syntax.

I'm afraid that they next thing they'll do is invent their own incompatible version of Unicode.

</comment><comment><USER26> React has a non-open license: [https://github.com/facebook/react/blob/master/PATENTS](https://github.com/facebook/react/blob/master/PATENTS), which basically says that an organization can no longer use React once it sues Facebook for any (unrelated) patent infringement.

This is an automatic no-way for React for any major company

<comment><USER27> Yes... I'm really surprised that people aren't talking about this more seriously. They have removed the worst of it, but it still looks like it gives Facebook an advantage in any patent conflicts with any company that uses React, Immutable, Hack, HHVM, GraphQL, etc. anywhere in the dependencies. It appears that the PATENTS file claims that if Facebook infringes on _your_ patents, you can't defend your patents without a risk of immediately losing the ability to use React (or other Facebook library). Maybe a lawyer would be able to make more sense of that PATENTS file.

I'm surprised that Apple might be using React, since they have had big patent battles with Facebook:

[http://www.meetup.com/ReactJS-San- Francisco/events/227071839...](http://www.meetup.com/ReactJS-San- Francisco/events/227071839/)

[http://www.theguardian.com/technology/2015/jul/21/facebook-g...](http://www.theguardian.com/technology/2015/jul/21/facebook- google-dell-hp-ebay-samsung-apple)

I've heard that Google doesn't use React, but I don't know how long companies will be able to do that as Facebook libraries increasingly become dependencies of other libraries.

<comment><USER28> Google does use React now; as far as I know they are happy with the current version of the PATENTS file.

<comment><USER27> The last I heard, they weren't allowed to use it. If you could link to a Google product that uses React, I'd like to take a look.

<comment><USER28> I don't have links to any; they might be all internal. The current iteration of the patent grant was developed in collaboration with Google to meet their needs, so if there is any complaint they still have with it, that is news to me.

Only public evidence I have of this is Firebase (owned by Google) being unwilling to use React and then happy with the new license:

[https://twitter.com/KanYang/status/586636624349569024](https://twitter.com/KanYang/status/586636624349569024)

<comment><USER27> I would like to find out more specific information. It seems like the section of the license below says that you can never make any patent claim against Facebook or you lose rights to use the software. Doesn't that mean that Google could never initiate patent claims against Facebook, while Facebook could still initiate patent claims against Google? It seems strange that Google (or Apple) would do that. I am not a lawyer though, and the PATENTS file may not mean that.

> The license granted hereunder will terminate, automatically and without > notice, if you (or any of your subsidiaries, corporate affiliates or agents) > initiate directly or indirectly, or take a direct financial interest in, any > Patent Assertion: (i) against Facebook or any of its subsidiaries or > corporate affiliates, (ii) against any party if such Patent Assertion arises > in whole or in part from any software, technology, product or service of > Facebook or any of its subsidiaries or corporate affiliates, or (iii) > against any party relating to the Software.

</comment></comment></comment></comment></comment></comment><comment><USER29> I went "all in" on React a few weeks ago, but one probelm I had is the complexity of the various samples/starter kits.

If anyone knows basic React and uses Typescript, and want to start using Redux/ReduxSimpleRouter, you'll find this interesting: [https://news.ycombinator.com/item?id=10837377](https://news.ycombinator.com/item?id=10837377)

<comment><USER30> Does this work with the new react router that was just released?

And did you try using Immutable.js ? From my understanding, it doesn't work so well with simple router.

<comment><USER31> The only reason you could have a problem using Immutable.js with redux-simple- router is if you're trying to make the router's state into an Immutable.js data structure, but there is no reason to do that. redux-simple-router manages it's own part of the state, and you don't need to directly mutate it. You only read it or dispatch an action to update it.

You don't need to make the entirety of your state tree an Immutable.js structure, just the parts which are managed by the reducers you write.

</comment></comment></comment><comment><USER32> IMO the standout difference between Angular and React is how you think about your application. Do you like functional programming paradigms and want to apply them in writing your components? Use React. Do you think immutability is too restrictive and love things like two-way binding? Use Angular.

That being said, I'm a bit disappointed to see no mention of Aurelia although the author has mentioned other frameworks like Emberjs. I have been writing production code with Aurelia for about a month and this has been so far my best experience with any client side javascript framework. ES6 is very capable and Aurelia did it right by staying out of your way for most of the times by letting you write your components in plain ES6. All the while providing binding capability(with beautiful syntax), a very powerful router and out of the box package management support. I feel with all the commotion in framework space, more people will appreciate the simplicity of Aurelia and that camp will get bigger as time goes by.

<comment><USER33> > Do you like functional programming paradigms and want to apply them in > writing your components? Use React.

s/React/Elm/g

</comment></comment><comment><USER34> Its the Angular 2 router that currently needs a lot more work. Currently things like passing data down to child routes [1], getting current route segments[2], checking active route etc are still not easily possible[3].

imho router is a big part of any large app and getting the details right is essential there.

1\. [https://github.com/angular/angular/issues/5330](https://github.com/angular/angular/issues/5330)

2\. [https://github.com/angular/angular/issues/6260](https://github.com/angular/angular/issues/6260)

3\. [http://stackoverflow.com/questions/34571517/angular-2-how- to...](http://stackoverflow.com/questions/34571517/angular-2-how-to-determine- active-route-with-parameters)

</comment><comment><USER35> I prefer angular over react. 1) It is opinionated (wasting time for decisions is bad) 2) It is simpler to organize the code (it is MVC) 3) (click)="onSelect()" is simpler. You dont have to create an object with "bind" function like in react. 4) I dont want web designers mess with my code. So putting html on JS is bad decision.

<comment><USER36> But do you want web designers to mess with your markup? Many of the projects I work on still involve the 'old-fashioned' server-side rendering approach with bits of jQuery for interactive elements. If a non-coder webdesigner were to mess with my markup, everything would break anyways.

I guess what I'm saying is that I've worked on many types of projects in many kinds of environments, and whenever a front-end framework was necessary, the 'webdesigners' were not. I've just never run into the situation where it actually ended up being useful to create logic-less templates...

<comment><USER37> I don't have a horse in this race, but do you think that learning JSX is going to be any easier for non-coders?

<comment><USER38> Honestly I wouldn't hire a web designer that can't code a little Javascript. It's been a while since knowing only HTML as a web designer has been acceptable.

To answer your question though: they're probably about the same level of difficulty, and I don't think it's a great argument for vanilla/React/Angular because a person who doesn't understand code trying to modify stuff that is controlled by code is going to break something regardless of what JS framework you're using.

I prefer JSX because it's not pulling wool over your eyes - you're building a JS app, not an HTML app - so let's stop pretending. The ESX syntax is just a nice way of forming a hierarchy of class instances. The beauty of React is that you could come up with your own syntax for doing that and use it just the same, because React is just Javascript.

<comment><USER36> > I prefer JSX because it's not pulling wool over your eyes - you're building > a JS app, not an HTML app - so let's stop pretending.

Yeah, that's what it really boils down to. Many of the principles we apply are holdovers from when we used HTML and CSS for what it was originally intended: pages with content.

The way I see it, HTML and CSS were not meant for any of these apps. But if we are going to 'abuse' these technologies, we might as well chuck out the rulebook and optimize for what _apps_ need to do.

That said, please don't do this if what you're making _is_ 'pages with content'!

</comment></comment></comment></comment></comment><comment><USER39> What's your take on vue.js?

<comment><USER36> I quite liked Vue.js, but I really don't like how it takes the Angular approach of putting 'js in your templates' (sort of). Furthermore, while I'm holding off on 'universal apps' for now, I love being able to use React server-side. If a component needs client-side functionality (sliders, navigation etc.), it's trivial for me to create one component that renders a simple server-side version and then initializes the same component client-side with all the logic it needs.

Last I checked (about two weeks ago I think) server-side rendering was not possible yet in Vue.js.

All that said I'm quite likely to use Vue.js instead of jQuery for many of the use-cases where I would use jQuery instead of React. It's quite impressive!

</comment></comment><comment><USER12> tl;dr: The author is asserting that React > Angular2 because he's already emotionally invested in the former.

React's greatest strength is also its greatest weakness. It requires devs to compose their app out of multiple de-centralized parts. See 'javascript fatigue'.

If your aim is to write an isomorphic React app, you CAN"T just use 'plain old javascript' or anything that touches the DOM. If you care about SEO, this is a very important implementation detail to consider.

Angular2's greatest strength is also its greatest weakness. It provides a unified API for building apps. It forces you to do things the 'angular way' which is no different from Angular1.

So far Angular2 is heavily biased toward Typescript because it was written in TS and it was literally just released to beta 2 weeks ago. TS is good for devs bridging over from strongly-typed OOP languages, and TS provides better support for autocomplete in IDEs. TS is bad because it's not an 'official' standard and it may be an awkward transition for existing JS devs.

TS is not required, I have been writing an Angular2 app in strictly ES6 despite the lack of documentation/support.

Both: require transpilation; use observables (ie redux vs rxjs); use a HTML- like templating language for data binding; use the virtual DOM to speed up rendering; discourage mutating the DOM directly to encourage rendering on other platforms (ie mobile, isomorphic); require platform-specific shims that don't touch the DOM; etc...

The underlying technologies of both are more similar than different. React favors a more decentralized architecture. Angular2 favors a more monolithic architecture.

/axegrinding

<comment><USER33> My understanding is that the SEO argument is becoming moot.

With emphasis on the word 'generally': "We are generally able to render and understand your web pages like modern browsers." [https://googlewebmastercentral.blogspot.se/2015/10/deprecati...](https://googlewebmastercentral.blogspot.se/2015/10/deprecating- our-ajax-crawling-scheme.html)

</comment></comment><comment><USER40> As a new web developer, where do you draw the line between a web application rendered server side and a SPA? I'm trying to develop a web app for creating invoices for a niche market but in this case I don't see huge advantages for a SPA over rendering HTML server side, the added complexity of a SPA doesn't have that big of a reward, I still plan to separate the frontend and backend, for example, writing a HTTP API that outputs json and in another process(or server) consume the json and render HTML in the frontend server (and maybe add some JS to improve interactivity). But everything this days seems about creating SPAs for new apps and that's definitely the future it seems, I'm wrong following this route or is that I'm just consuming to much SPA hype?

<comment><USER36> Perhaps in the future there will be a time where an 'old-fashioned' server- side app is a bad idea, but right now I think it's still a perfectly valid approach, and even preferable in some cases.

Consider whether your app will _actually_ benefit from being an SPA. Does it negatively impact the user experience to have page refreshes? Or does it provide significant benefits to do things client side? If the answer is 'no', you might as well take what is currently still easier and more standardized, and go for server-side.

But the next step is to ask these questions about _parts_ of your app. In those cases using React or Vue or something similar for just those parts might be a good idea. And if you've already separated front- and back-end, it shouldn't be too difficult to realize (and it's a good reason to use React server-side even if that's all you use it for initially!).

</comment></comment><comment><USER41> > You spend your time writing plain 'ol JavaScript. That's the future I > believe in.

How about a future where you don't write any code at all? This is the beauty of Angular's markup-centric approach, it's declarative so that means less code, which means less opportunities for devs who _enjoy typing_ to screw things up.

Jeremy Keith made a good point in his An Event Apart talk [1], where he talks about HTML slowly subsuming interactive elements (e.g. like how HTML5 adds better form type support). Angular is pushing things into this realm by helping to take code out of the picture more and more.

[http://aneventapart.com/news/post/the-long-web-by-jeremy- kei...](http://aneventapart.com/news/post/the-long-web-by-jeremy-keith-an- event-apart-video)

<comment><USER18> If you're writing loops, and especially if you write loops that have conditionals inside of them, you're writing code. "Declarative" is saying "I want a list of all users", "For every user, display their name like this" is just code.

I've seen a lot of template languages that claim to be declarative, I'm yet to see a production template (that is to say, not an "example") that actually _looks_ declarative and isn't just writing code in a language with poor constructs for writing code.

<comment><USER36> Agreed. In every single project I've worked on that used mustache/handlebars, haml, or some similar 'restricted logic' approach, the long-term result consisted of view templates that contained hacks, a lot of logic hidden in helpers that were often only used in one place, or just plain convoluted solutions.

Furthermore, the main argument I hear is that these logic-less template approaches benefit designers/front-enders, which doesn't make sense to me. If your project is complex enough to require Angular or React, a non-coder front- ender probably will have trouble working on it anyways. That's been my experience at least.

</comment></comment></comment><comment><USER42> Angular is HTML-centric whereas React is JavaScript-centric. Succint!

</comment><comment><USER43> It seems like Redux + React is clearly going to win out. What am I missing?

Yes the ecosystem is constantly changing right now but the oscillations are getting smaller not bigger. In my opinion Redux is the highest level and most intuitive, just like React was for the view when it came out. It's only a matter of time.

<comment><USER44> Why does Redux imply React? I use Redux with virtual-dom and end up with far less bloat.

<comment><USER43> Interesting. Didn't know about that

</comment></comment></comment><comment><USER45> His argument about the 'Unix Philosophy' reminds me a lot of the argument between using big web frameworks like Django vs smaller micro-frameworks like Flask. Personally, I prefer Flask for the small projects I make because of how nimble it is but it's hard to argue with the large organizations using Django for massive projects to (seemingly) good effect. Ironic since I actually do like Angular (sorry)!

Overall I felt the article was preachy and extremely biased. It's as if the author was trying really hard to convince as opposed to just presenting the facts and letting the reader make a choice based on the evidence.

I have concerns about ng2 but having made an effort to learn React as well I think he dramatically oversimplifies it's ease of use for large scale projects (where Angular shines, IMHO).

</comment><comment><USER46> From someone with years of experience with javascript, how is this "plain 'ol javascript"?

 { heroes.map(hero =>
{hero.name}
 )}

<comment><USER47> It clearly isn't, but it starts to _feel_ like it once you get used to JSX syntax as sugar for nested function calls with attribute object arguments.

</comment></comment><comment><USER48> "Angular 2 continues to put "JS" into HTML. React puts "HTML" into JS."

It seems fairly obvious to me that both approaches are wrong.

<comment><USER38> Have you tried either? What is your concern with mixing the two? JSX is optional, by the way. I have a problem with JS into HTML because that's pseudo-coding. JSX tags are representations of classes and class instances, which makes a lot more sense than a totally new DSL for scripting.

</comment></comment><comment><USER49> More importantly, when is the Flux Influenced, Stateful Template Enterprise React methodology gonna get a catchy acronymn?

Asterisk-ux isn't cutting it, and god knows we need a buzzword.

</comment><comment><USER50> "Yes I'm biased" was tl;dr actually. Or "I love JSX so much I can't even think about frameworks without JSX".

</comment><comment><USER51> I found smaller frameworks like riot.js easier to reason around and light on almost all use-cases.

</comment><comment><USER52> > _React is a library. It's precisely the opposite philosophy of large, > comprehensive frameworks like Angular and Ember. So when you select React, > you're free to choose modern best-of-breed libraries that solve your problem > best. JavaScript moves fast, and React allows you to swap out small pieces > of your application for better libraries instead of waiting around and > hoping your framework will innovate._

Just an aside, but who would've thought that Facebook would be the one to develop around the Unix philosophy? Yes, I know that Google is a monolith, but it became a monolith over one very specific feature and mission, whereas Facebook had to accompany many kinds of user-interaction and behavior right from conception. When Zuckerberg guest lectured CS50 (more than 10 years ago), he didn't foresee FB doing open-source:

[https://youtu.be/xFFs9UgOAlE?t=17m25s](https://youtu.be/xFFs9UgOAlE?t=17m25s)

Excerpt: _" There's a lot of work that goes into making stuff open source. And it's on top of whether or not you want to lose the competitive advantage...there's a lot of support and licensing and all that stuff. We found that it's been annoying"_

Yes, I know FB of 10 years ago is nothing like it is today, with much different people and components...didn't React arise partly/mostly from Instagram? Either way, I was encouraged to use it early on because it was purportedly being used in Instagram production. Angular 1.x wasn't in any of the big sites (other than DoubleClick?). It's nice to see it in more of Google's sites now...but honestly, how it has currently been used has left a bad taste in my mouth. I'm thinking of the Cloud/Compute Dev console. I spun up a machine, thought I shut it off, found out I was $30 in the hole at the end of the month. No big deal, I've done that with EC2 too...but the difference is that AWS's interface, ugly as it may have been, was very easy to use to shut down a machine (right-click, Terminate). I'm ashamed to say it took me about 10 minutes to do it in the Google console. Part of it is unfamiliarity, sure...but nothing interacted the way that I, as a developer, expected it to. I finally found the button or whatever that brought up the panel to show the Terminate option -- it was on the very bottom of my widescreen monitor window...which is a huge visual gap from where the instance-icon is. Maybe it's different when you have several instances spun up and your eye is naturally drawn to the bottom...

Anyway, I know overly-enthusiastic-responsive design is not something that can be blamed inherently on a framework. But it doesn't inspire enthusiasm when it is poorly dogfooded on a developer-facing UI. I mean, it's _beautiful_ , but in all the wrong ways, with boxes of live-updated charts showing performance/activity metrics, but in no discernable hierarchy, as if someone wrapped the page container with jquery.isotope. It's something I would show my boss to make it look like I was doing something impressive but it was not great for productivity.

In contrast...the way that React was justified in its announcement had immediate appeal. The number of UI/UX things that FB and Instagram have to constantly update because of their dataflow required React's kind of overhaul, and it was easier to trust that they would not only maintain React, but design and add features only as necessary.

<comment><USER53> > I'm ashamed to say it took me about 10 minutes to do it in the Google > console. Part of it is unfamiliarity, sure...but nothing interacted the way > that I, as a developer, expected it to.

You can make sloppy interfaces with any library or framework. Angular is no exception. Neither is React.

</comment></comment><comment><USER54> Oh my Christ, not this again. The framework fatigue is real. Why are people trying to push Angular 2 or React even? The former is still under heavy development and the latter is such a painful pill to swallow.</comment>


AWS Lambda as a back end for a single-page app - <AUTHOR> http://lg.io/2015/05/16/the-future-is-now-and-its-using-aws-lambda.html <comment><USER2> So the backend becomes a repository of small lambda-modules.. on a testing perspective, that's pretty cool. I agree that it could be the next big thing as new libraries leverage that.

Basically, there's no more "Platform as a service".. there is just "your code" that gets executed whenever. You can upload a new module without touching the other modules.

Something worth exploring in my next hackathon : )

<comment><USER3> It's really just a more fine-grained PaaS, not significantly different than a bunch of tiny Heroku apps (the ~1 second cold start time is significantly better than Heroku's though)

</comment></comment><comment><USER4> I've used [http://www.Webscript.io](http://www.Webscript.io) in the past which is essentially just like AWS Lamda to make static sites 'dynamic' with no backend.

</comment><comment><USER5> "the future is now, and it's down because somebody used the secret key to drain the poster's bank account"

To be sure, the author specifies that the IAM role being exposed here is only allowed to invoke the function. That's great for the security of the other resources on the account, but still allows a reasonably determined attacker to run up a Bill of Unusual Size quite rapidly.

For instance, the rate limiter currently kicks in at 1000TPS. Assuming the smallest memory size (128MB) and requests <100ms, that's a worst-case spend of roughly $18/day per Lambda function. Not the wallet-melting consequences of, say, accidentally posting AWS root credentials but not great either. Multiply that by the number of endpoints you'd likely want in a single-page app, and it gets expensive.

<comment><USER6> But the same is true of any backend. Once you know the endpoint being used by the frontend, you can blast the backend with requests and one of two things will happen:

* You will take down the site (a DoS attack). * Or the victim has auto-scaling and you rack up their AWS charges.

This is hardly a unique problem to Lambda.

<comment><USER7> The biggest difference is ease of rate limiting. With lambda, I imagine the best you could do would be check the IP in a Redis cache at the beginning of each request (if the SDK even includes that info) to minimize the damage. But there would be no way to fully stop an attacker without turning off the service entirely.

If you run your own webserver, I think you can stop stuff like that more efficiently / without the expense, eg at the nginx level.

</comment></comment></comment><comment><USER8> The real question here is still: why doesn't Amazon offer a GET interface to Lambda? It's so, so, so close. So almost. They offer POST (through a work- around with S3), why not GET?

That is the real destination. With lambda serving GETs, we can remove the "for a single page app" from the title. AWS is so close to fulfilling the promise of its cloud: let developers worry about code.

<comment><USER9> It is a bit slow still. Jitsu[1], which starts unikernels is fast enough to do per request image booting, but Amazon seem to have a 1s cold start which is just a bit slow.

[1] [https://github.com/mirage/jitsu](https://github.com/mirage/jitsu)

<comment><USER10> Ah, so there is a 1s cold start. I couldn't understand how they managed to get a container (which I imagine they are using?) running "within milliseconds". I guess the millisecond claim only holds for concurrent requests then?

<comment><USER9> Seems so for the measurements I have seen yes. Concurrent or close before it has been shut down.

</comment></comment></comment></comment><comment><USER11> What's the typical latency for a request when you use lambda, such as for this example?

<comment><USER12> My anecdotal experience is that it's about ~1 sec. for a "cold" request, and on the order of 10s of ms for repeated requests thereafter.

</comment></comment><comment><USER13> Naive question: how does his example differ from a server responding to HTTP requests, that would take a JSON _event_ as an argument and return a json version of:

        "the value was: "+ event['key1']

I suppose the AWS wins in term of set up and easiness of deployment. Anything else?

<comment><USER14> It differs in that you don't have to worry about scaling up that HTTP server, or pay for the machine hosting that HTTP server. With Lambda, you only pay per requests, current rate is $0.20 per 1 million requests.

<comment><USER15> Is there also any limit on machine resources that a single request can use? I'm curious about cases in which requests might need non-trivial amount of computational power.

<comment><USER16> You pay for request time too, measured in 100ms increments. And you pay more for more CPU/RAM.

</comment></comment></comment></comment><comment><USER17> I don't think I'd trust building directly on it for the 100 req/sec limit and whatever latency it introduces, but it seems like it would complement heroku dynos really nicely farming out processor-intensive stuff like bcrypt.

<comment><USER18> I think it is 100 concurrent requests per account. That is pretty low IMO. I think it was intended for things that are CPU intensive and short-lived. If it needs to pull from a data store and process, it likely isn't a good idea for lambda to begin with, right?

I agree, it is only really useful to use like this for certain scenarios.

<comment><USER19> All of those limits are typically to protect users from being over charged if they fat-finger something. Most limits like that can be lifted with a support ticket. I'm not sure if this is one of them but I think it's likely.

<comment><USER20> You are correct; that limit can be raised. Just ask!

<comment><USER7> Could the limit also be lowered, for damage control?

</comment></comment></comment></comment></comment><comment><USER21> Does nobody else look at this and worry about the vendor lock in implications?

If your app is dependent upon a technology like this, it's much harder to move to a different platform than if just used, say, EC2.

<comment><USER22> I don't worry about lock in in this particular case. At the platform level there is an element of implicit lock in because nobody else offers this exact service.

However, the application level can be easily moved to another platform. You could host the handler function code on an EC2 instance or bare-metal server. Little would change in the app code, except the API endpoint to which requests are sent.

So IMHO there is no lock in in the traditional sense, but there is a switching cost if you want to move to another platform.

<comment><USER21> >At the platform level there is an element of implicit lock in because nobody else offers this exact service.

That's kinda what I meant (although there seem to be some similar variants with totally different APIs).

Anything similar will use a different API, as well. Even if you could move to an almost-identical service, there will be not-insignificant switching costs as you reconfigure everything with a different API and reimplement the glue code.

>So IMHO there is no lock in in the traditional sense

Lock-in doesn't mean that it's impossible to move to a different platform, it just means that there's a high cost. To me, it seems like the cost of moving this to some other platform is quite a bit higher than the cost of moving something from, say, EC2.

Actually, it seems like this is Amazon's real business strategy with things like this. They want you to use all of their different services like this, SQS, SES, Elastic beanstalk, their hosted database thing. Individually the costs of moving away from all of them is not _that_ high, but add them all together and it becomes immense.

<comment><USER22> > Even if you could move to an almost-identical service, there will be not- > insignificant switching costs as you reconfigure everything with a different > API and reimplement the glue code.

That's true. I think we're essentially on the same page here.

I guess I'm still using the old definition of lock in. Poor example: a proprietary Microsoft format that can only be understood by MS software. There is literally no alternative to using MS software if you want to access files created using this format.

Does "high switching cost" == "lock in"? I think it is a grey area. I would not consider myself locked in to Lambda if I had made the decision to host my app there, although I do see there is a high switching cost.

However, if I used RDS Postgres and Amazon decided to prevent me from creating database dumps to migrate to a self-hosted Postgres, then I would be very unhappy because that would be an arbitrary restriction with no purpose except to keep me on AWS.

> To me, it seems like the cost of moving this to some other platform is quite > a bit higher than the cost of moving something from, say, EC2.

I agree completely with this. Let's say this was implemented on EC2 instances running Ubuntu, and configured with something like Salt or Puppet. The cost of moving to a Digital Ocean box would be negligible.

</comment></comment></comment></comment><comment><USER23> Some time ago, when Lambda was in its early preview, I've created awsletter [1], a newsletter system w/o any old-style backend components - only AWS SDK for browser, S3 and Lambda. Pretty the same idea - utilize "invoke function" calls to realize backend actions.

[1] [https://github.com/jelz/awsletter/](https://github.com/jelz/awsletter/)

</comment><comment><USER24> How does the pricing compare with say X amount of tasks that run for 1 second each compared to what you could expect from 1 hour on a medium ec2 instance?

EDIT: I see it offers "The Lambda free tier includes 1M free requests per month and 400,000 GB-seconds of compute time per month. " What is a GB-second ;)

<comment><USER19> Re: pricing -- good question I'm going going to test that.

Re: gigabyte seconds: It's how much memory (RAM) you're using:

128mb RAM (lowest possible value) for 10s == 1 GB/s

1gb RAM for 1s == 1 GB/s

I think it's a pretty clever way to (somewhat) directly correlate compute cost with power (energy). If you remember what John McCarthy said when he imagined that computing would be a public utility one day ([http://www.technologyreview.com/news/425623/the-cloud- impera...](http://www.technologyreview.com/news/425623/the-cloud-imperative/)) I think this is about as close to that as we're going to get for a little while.

<comment><USER25> Doesn't this terminology come from power utilities where a kilowatt hour is kW.h. as in kilowatt × hour. Not kilowatt / hour. So why is a GB second, a GB / second and not GB × second?

<comment><USER19> It is a GB x second -- I've just seen it written more commonly as GB/s. I think we need a better abbrv for it... gBs?

<comment><USER25> Then it should be GB.s or GBs.

GB/s gives a different meaning. For example I could use 600 GB in the first second, then 400 GB in the second second. All together its 1000 GB.s, at an average of 500 GB/s for 2 seconds.

This is not perfect because kilowatt is a rate so kWh is a quantity. But GB is already a quantity. So a GB.s doesn't make sense either. It would need to be an equivalent memory rate usage × time in order to get memory quantity. Like avg GB/s × s.

<comment><USER26> > This is not perfect because kilowatt is a rate so kWh is a quantity.

You're a bit mixed up there. Kilowatt is a quantity (unit of energy), kWh is the rate.

</comment></comment></comment></comment></comment></comment><comment><USER27> This makes me think that Amazon should build a service that acts as a virtualized "pre-fork worker model" server (a la [g]unicorn) and transparently scales WSGI/Rack/etc application processes across machines.

</comment><comment><USER28> How hard is it to pull in extra dependencies for the script ?

<comment><USER29> There are a few answers in the FAQ around this: (none specifically answering the "easy" part): [http://aws.amazon.com/lambda/faqs/](http://aws.amazon.com/lambda/faqs/)

My own experiences of working with Amazon services suggest that this will probably be great for some use-cases and very complex and unpleasant for others, and will probably be updated every six or twelve months in a fairly drastic way which will make it hard to find helpful documentation. Maybe I'm just feeling cynical today, though.

<comment><USER19> I think AWS is betting big on Lambda (I work there). So I think you'll see a lot of continued innovation around the service. They're pretty intense about consuming customer feedback and iterating on it so if you have an idea or desire that you would like Lambda to incorporate I'd definitely shoot them an email/ticket -- it's not a black hole.

</comment></comment></comment><comment><USER30> AWS has a couple of issues with Lambda. If you use a binary its very difficult to talk to the process. No port binding means its nearly impossible to talk to processes without prohibitive changes (named pipes are a solution but it requires extensive code changes to existing apps)

</comment><comment><USER31> It is certainly an amazing product. Would be interesting to know how Amazon designed it, specially for security. Does anyone know if they just put all requests in a queue and spin up containerized environments for each request?

</comment><comment><USER32> Is it possible to have the same thing but over websockets? As Lambda can also listen to DynamoDB, it would be quite interestig to have an ability to forward this kind of events to browser clients.

</comment><comment><USER33> How would this use differ from Amazon's elastic beanstalk?

<comment><USER34> With beanstalk, you're paying in terms of multiples of server instances at all times, even if nothing is hitting your servers. With Lambda, you pay only for the execution time of your function, which is only when a request is made.

</comment></comment><comment><USER24> I like the idea of Lambda. I have some linux binaries that I would like to run on demand. I wonder if this is possible.

<comment><USER35> You should be able to do that as described here : [https://aws.amazon.com/blogs/compute/running-executables- in-...](https://aws.amazon.com/blogs/compute/running-executables-in-aws- lambda/)

Note that there are some limits regarding the size of the zip you upload [1].

1: [http://docs.aws.amazon.com/lambda/latest/dg/limits.html](http://docs.aws.amazon.com/lambda/latest/dg/limits.html)

<comment><USER24> Thanks for the links! If my executable relies on .so files in a lib directory, is it possible to set env variables to point to a local path?

<comment><USER36> Why would you need to do that? Just set DT_RUNPATH when you link the binary and use the $ORIGIN variable to set a relative path.

<comment><USER37> Is there anywhere that has decent documentation on how to do that? I'm not very good with compiling and linking C, and have been trying to work out some distribution issues with a project I was working on in a compile-to-c language, where it relies on a dynamically linked shared library that I want to distrubute along with it.

<comment><USER36> I would read section 3.9 of Ulrich Drepper's "How to Write Shared Libraries" [0].

[0] - [http://www.akkadia.org/drepper/dsohowto.pdf](http://www.akkadia.org/drepper/dsohowto.pdf)

</comment></comment></comment></comment></comment></comment><comment><USER38> > The future is now, and it's using AWS Lambda

How is this different from what Azure Mobile Services and many others have been offering for the past 2 years? To me it seems the author is proclaiming Platform As A Service is entirely new (look, no spinning up AWS instances!) while this has been around for quite some time, just Amazon is getting into it more seriously recently.

<comment><USER39> Lambda is a focused, specialized service for running short-lived processes triggered by events and is one of the many services provided by AWS that have formed the foundation for many companies and other PaaS providers for many years, while Azure Mobile App Service is a packaged and branded collection of services including data storage and push notifications that is similar to backend service providers like Parse and Urban Airship pre-pivot (at least one of which was built on top of AWS), and tries to offer services comparable to a subset of other AWS services including SNS (push notifications), RDS or DynamoDB (databases as a service), among others.

It's also quite strange to spotlight Azure as if it's doing something at all remarkable considering the "Mobile Backend as a Service" market has existed for years and actually seems to be on the decline, at least as a standalone segment.

<comment><USER38> I mentioned Azure Mobile Services because (as it's node-based) it can be used to implement exactly the same application as the OP, line-for-line exactly the same.

A static webpage, that calls into a javascript based service, you can register a script to run in that service without any infrastructure hassle, because, well, it's a service.

You are right that there are many comparable Mobile Services that can do many other things and might be branded differently, but this just adds to my point: I don't see what's new here, other than that the OP has seen the light on static webapps combined with platform services.

</comment></comment></comment><comment><USER40> Can this be called RPC? If not, what is the difference? Amaz(on)ing service anyway!

</comment><comment><USER41> I like lambda a lot. I just have to find more use cases for it.

</comment><comment><USER42> Hey, just a heads up, you posted your AWS secret key. I'd take that down and change your key ASAP. I had my keys compromised before and someone racked up a $5k AWS bill mining bit coins.

<comment><USER43> he mentions in the article he created that account specifically to only have the ability to call that one lambda function - which I didnt realize you could restrict to that level.

<comment><USER44> I like this one better because it demos using google auth to get temporary aws credentials:

[https://github.com/cloudnative/lambda- chat](https://github.com/cloudnative/lambda-chat)

<comment><USER45> Last message is "Peter Sankauskas Hello". I tried to send some message, and it's saying "Message sent to SNS successfully". But these message never show up in the page.

<comment><USER46> I'll be talking about this at Gluecon this week. You are right, it is a little broken right now.</comment></comment></comment></comment></comment>


How To Write The Perfect Meta Article - <AUTHOR> http://www.whattofix.com/blog/archives/2011/01/how-to-write-th.php

<comment><USER2> In this situation, as a smug HN reader you may want to make a comment that mirrors the form of the article in a way that you find clever but is in fact irritating.

The best way to achieve this is to go one level up on the meta-ladder, and to write a meta-comment, that is, a comment about comments.

However that would be self-indulgent to the point of solipsism, so I advise against it. At least I think it would be. Let me just ask the next djinn above me...

<comment><USER3> With your "next djinn above me" comment you have implicitly already laid claim to the infinite chain of additional rungs on the meta-ladder on top of your comment. And you did it in the very first comment of the thread.

I don't see how anybody can possibly go more meta than that.

</comment></comment><comment><USER4> I've been tempted to write "Top Ten Articles Containing Ten Reasons Top Ten Lists are Bad".

<comment><AUTHOR> I've been meaning for some time to write an article on procrastination.

<comment><USER4> If that's a friendly snark about how I haven't written it, the reason is that the joke is basically the title; actually writing it doesn't add much to the joke. A little bit from actually finding ten such articles, but not enough to warrent the effort.

<comment><AUTHOR> No snark intended. I got the joke. Just trying to reply in the meta and recursive spirit of the article. Like yours, my title is the joke. Nothing more to add.

</comment></comment></comment></comment><comment><USER5> OK, Daniel, I see where this is going...

Last week: "Roll Your Own LinkBait Tech Headline"

This week: "How to Write the Perfect Meta Article"

Next week: "Ask HN: Review my start-up BlogPostGenerator.com"

<comment><AUTHOR> After swombat's article today on writing articles for startups I tweet "Swombat! Keep this up and I'll write an article on how to write meta articles"

I had to do it. It was a triple-dog dare.

He now threatens to write an article on how to make fun of meta articles, but I don't think he has it in him.

Meanwhile for those of you who think we do this instead of working, I've been pounding away at writing a custom Data Access Layer in F# and MySql. It's going to do some cool stuff, and I look forward to blogging about it. But the reason it's cool, ugh, is that, you guessed it, it works at the meta level.

So I had meta on the brain today and this was just a good way to blow off some frustration.</comment></comment>


Inside the deal that made Bill Gates $350,000,000 - <AUTHOR> http://faculty.chicagobooth.edu/john.heaton/teaching/35000/msft.htm

<comment><USER2> What I found fascinating about this semi-puffy piece was the backstory -- Sun, Oracle both going public right in the same month or two.. The institutional questions around personal computing companies and their value.. Fascinating! Tech has, at some level, schooled investors in the last 25 years.

Also, you can find out what Gates did with his $1.5mm in IPO proceeds, worth a read just for that tidbit.

<comment><USER3> he bought waterfront property on Lake Washington on which he later built his home

</comment></comment><comment><USER4> Really interesting moral to the story: if something is important to your destiny, don't delegate it to flunkies

</comment><comment><USER5> "Among the major houses, Gaudette had been most impressed by Goldman Sachs, which tightly links its underwriting group with its stock traders and keeps close tabs on the identity of big institutional buyers."

The hookers and blow had nothing to do with it. Ahh the 80s.

</comment><comment><USER6> [https://www.readability.com/articles/b7ohcudx?legacy_bookmar...](https://www.readability.com/articles/b7ohcudx?legacy_bookmarklet=1#)

A little easier on the eyes</comment>


Is Google Always the Best Search Engine? Answer is No why? - <AUTHOR> http://thejaynotes.com/is-google-always-the-best-search-engine-answer-is-no-why/ <comment><USER2> " _Use knowledge engines, such as www.wolframalpha.com or www.trueknwoledge.com_ "

Wolframalpha can be classified as "knowledge engine" but is this true for www.trueknwoledge.com? I couldn't figure out what it is.</comment>


Ask YC: Feedback on a way to measure and discover links between your daily activities. - <AUTHOR> http://www.bricolagelabs.com

<comment><AUTHOR> Some sample experiments being recorded currently:

 _Weight lifting and Swimming_ \- Does swimming a few laps in the pool at high intensity immediately after weight lifting help build and maintain muscle mass?

 _Food & Alcohol_ \- Which foods hold alcohol the best?

We've been curious about these and many other things. We started bricolagelabs as a place to record your observations and perform "experiments". these could be anything - productivity when you wake up early/late/ pickup lines/ whatever.

It's related to Seth Roberts' (Shangri La diet) self-experimentation with the goal of aiding discovery through trial and error.

Would love to get news.yc feedback on this. Thanks!

<comment><USER2> Great job. I've actually been working in this space for about 2 years. It's an interesting development and people are tackling it from a number of angles.

It seems your approach is more descriptive than numerical. That could be good, a lot of the recent players are more numbers oriented which may turn off most users.

For a good summary of the field, Google "Me-trics", who presented at TC50. You'll find a lot of the competitors listed on various posts discussing Me- trics. I think the personal analytics/crowd-sourced-research-experiment space is set for solid growth in the coming years.

I've tried a number of different UI's and a number of different techniques to mining the data. I don't think the market is quite there yet, so I'm doing these things on the side until I have the money and technology ready to focus on it. Anytime you want to chat about it, shoot me an email.

<comment><AUTHOR> Useful pointer. thx a lot!

I'll be in touch.</comment></comment></comment>


The Strange Similarity of Neuron and Galaxy Networks (2017) - <AUTHOR> http://nautil.us/issue/50/emergence/the-strange-similarity-of-neuron-and-galaxy-networks <comment><USER2> Discussed at the time: [https://news.ycombinator.com/item?id=14825473](https://news.ycombinator.com/item?id=14825473)</comment>


A Practical Guide to Correctly Troubleshooting with Traceroute (2009) [pdf] - <AUTHOR> https://www.nanog.org/meetings/nanog45/presentations/Sunday/RAS_traceroute_N45.pdf <comment><USER2> Reminds me of back when I was a kid in NYC around 2001, and first learned about traceroute and routing playing around with Linux. Late one night my Comcast Internet went down. So I called support, only to be given some message that it consumer support was closed. Did some basic ping and traceroute troubleshooting and discovered that the first hop out of Comcast to Cogent was down.

So being a foolish and persistent 18yo, I called directory assistance and sure enough Cogent NOC was listed. So I called them pretending to be a Comcast support employee. No questions asked. I told them the router IP that was down and they said they'd look into it. 20 min later, my connection to the outside was up. Probably fixed the Internet for several million people in NYC. The foolishness of youth has its perks.

<comment><USER3> > So being a foolish 18yo I called directly assistance and sure enough Cogent > NOC was listed. So I called them pretending to be a Comcast support > employee. No questions asked.

How in the world did you find the correct phone number? And how did you pretend to be an employee? (Did you say "this is [random name, or maybe your own name] calling from Comcast?" or something?)

<comment><USER4> It was easier in those days to find NOC phone numbers and network engineers generally like to fix problems.

I did network event correlation in those days (using prolog and Perl to convert hundreds of thousands of log entries and events to actionable alerts), and would call various NOCs all of the time, usually to let them know that their device was spewing alerts or doing something dumb. There was very little in the way of authentication. Once you crossed the line to ask for things vs fix things you'd get more questions.

<comment><USER5> > It was easier in those days to find NOC phone numbers and network engineers > generally like to fix problems.

Yes, it is super hard now. It took over 5 seconds to find the Cogent support numbers:

[http://www.cogentco.com/en/customer-service/support- desk](http://www.cogentco.com/en/customer-service/support-desk)

It if hadn't found anything after 10 seconds, I would have given up and gone back to watching Youtube.

<comment><USER6> And if I call those numbers I get the people in charge of running the network (which the conversation was about), or a helpdesk that can't do anything directly?

</comment></comment></comment></comment></comment><comment><USER7> Presentation video: [https://www.youtube.com/watch?v=4dUqVlZ6trU](https://www.youtube.com/watch?v=4dUqVlZ6trU)</comment>


Startup Quote: Garrett Murray, founder, Karbon - <AUTHOR> http://startupquote.com/post/2385961466

<comment><AUTHOR> Time's a wasting - don't talk about wanting to do something, just start doing it.

\- Garrett Murray (@garrettmurray)

<http://startupquote.com/post/2385961466></comment>


Sift.js: mongodb inspired array filting - <AUTHOR> https://github.com/crcn/sift.js

<comment><USER2> Can someone explain me why is it useful? I.e. why not using underscore or whatever library provides map and filter?

<comment><AUTHOR> Thanks for the feedback. I'll add a few use-cases / examples to the project page.

Here are a few good examples which use sift:

\- Realtime API library: <https://github.com/crcn/guava>

\- Simple database written in node.js: <https://github.com/crcn/gumbo>. I use this primarily in command line utilities, and other applications where mongodb seems a bit over the top.

Underscore is certainly a better alternative in many cases, but the goal for sift is to provide control over filtering collections with one query versus manipulating them.

</comment></comment><comment><USER3> The first 90% of my current pymongo-backed project was great, I just came up with whatever schemas I wanted and inserted the data as serialized JSON-style objects.

The second 90% has been not so great... I spend my time either doing in-place serialized batch updates to correct my own early schema mistakes or (mostly) reinventing SQL so that I can join my schemas arbitrarily and dump them to CSV per user requests.

I hope this means I'm just doing it wrong. Time to dig my Mongo book back out.

<comment><USER4> Nope, unfortunately that's what I'm running into as well. A blissful start of the project with no schemas to tie it down or hold it back. Now that it's starting to require migrations, join-like behavior, and complicated queries, I really just wish I had my trusty old PostgreSQL back. I swear, if I have to write one more set of map/reduce functions just to do anything non-trivial with this database I'm going to end up hurting a small animal.

<comment><USER5> If you could imagine designing Postgres to be more enjoyable and productive to use in the earlier stages, what would you want?</comment></comment></comment>


Ask HN: How do we know that WhatsApp doesn't spy on messages? - <AUTHOR> Yesterday I was talking about WhatsApp with friends, trying to explain how end-to-end (E2E) encryption works. One of my friend (who is not a techie) said I was naive to believe Facebook couldn't see users' messages, considering its awful track record on privacy.
I was about to confidently reply something about how, with modern encryption, you don't need to trust the server to pass messages securely... but something held me back.
I was so sure about the system privacy, and suddenly I wasn't.
I know WhatsApp claims to implement the Signal protocol, which is considered secure (so far).
But some questions popped in my head: - What's preventing WhatsApp from not using the protocol properly, or at all? - What's preventing WhatsApp from, say, also send secretly the message to itself? Or a digest of it? Or just some keyword matches? You know, for "analytics"? Or to comply with obscure child porn laws?
I use WhatsApp every single day, so this thought makes me pretty uncomfortable. The more I think about it, the less I'm sure. What I find the most convincing is that, if such a backdoor existed, a WhatsApp employee would have leaked it on HN already...
What do you think? Do you trust WhatsApp on this? <comment><USER2> As far as I know Mark Zuckerberg already admitted that Facebook is spying on the Messenger messages:

[https://thenextweb.com/facebook/2018/04/05/facebook- confirms...](https://thenextweb.com/facebook/2018/04/05/facebook-confirms-it- spies-on-your-messenger-conversations/)

Now Zuckerberg is merging Facebook Messenger, WhatsApp and Instagram:

[https://mashable.com/article/mark-zuckerberg-speaks-on- whats...](https://mashable.com/article/mark-zuckerberg-speaks-on-whatsapp- instagram-messenger-merger/?europe=true)

Thus we can be pretty sure that WhatsApp messages are also being monitored.

<comment><USER3> The first article talks about Messenger only, not WhatsApp, and the second article claims the opposite of what you're insinuating, namely that they want to introduce E2EE across their apps:

> "The first reason I'm excited is moving more to end to end encryption by > default in our products. People like this in WhatsApp. I think it's the > direction we should be going in. I think there's an opportunity ... to have > encryption work in a consistent way across the things that we're doing."

What they certainly analyse and presumably monetise is the metadata.

</comment></comment><comment><USER4> 1\. You can't know. (Unless something confirming the opposite leaks in the future).

2\. Facebook's reputation is so bad when it comes to privacy at this point that trusting them is just naive.

3\. Even in the best case, your metadata is certainly used. Facebook didn't pay over $20 billion for a service with no monetisation model purely out of the goodness of their hearts.

4\. Whatsapp has good network effects at least here in the UK - when your flatmates or coworkers have a group chat, you can't just say "Well, let's get everyone over to Signal.". You either use Whatsapp or go without the group chat.

<comment><AUTHOR> 1\. OK...

2\. You are restating my friend's argument, but the idea of E2E is precisely to remove trust from the equation. If applied properly, there's nothing the company controlling the server can do.

3\. Most probably, but that's not the point here. My question is specifically about the messages themselves.

4\. Sure, but not related to my question either :)

<comment><USER4> > the idea of E2E is precisely to remove trust from the equation

It doesn't do that. You don't have a way to verify what software runs when you send a whatsapp message.

<comment><USER5> Oh, it's worse. End-to-end encryption assurances are essentially in conflict with centralized control over software development and distribution. Literally the same organization end-to-end encryption is supposed to protect from is the one responsible for implementing and deploying that protection and doing that well and correctly.

<comment><AUTHOR> That's interesting. Could you develop on this conflict?

For some reason it reminds me of the famous Moxie article: [https://signal.org/blog/the-ecosystem-is-moving](https://signal.org/blog/the- ecosystem-is-moving) Is it the same idea?

<comment><USER5> It's the opposite of Moxie's propaganda. Here's an example of this conflict at play: [https://news.ycombinator.com/item?id=22106536](https://news.ycombinator.com/item?id=22106536)

</comment></comment></comment></comment></comment></comment><comment><AUTHOR> (By the way, one day I sent a picture of a dress to my sister-in-law on WhatsApp. She told me that Instagram sent her an ad 5 minutes later, _with the exact same dress_.

It was so unlikely to be random that I checked right away to see if pictures were safe. It turns out that pictures received and sent are shared within all Facebook apps - Facebook, Messenger, Instagram -, at least on iOS)

</comment><comment><USER6> You should study open source software (like the Signal app or the Matrix network). Furthermore, study "trusted builds" and trusted hardware -- attempts to proof that certain lines of codes are really running on a system. Then we can talk again about encryption...

<comment><AUTHOR> I know there are other problems and unknowns when using WhatsApp on an iPhone. I do not see how this is related to E2E though... Does it mean that any try to secure communications on the iOS platform is irrelevant in your opinion?

</comment></comment><comment><USER7> > WhatsApp employee would have leaked it on HN already

Employees don't need to be aware of the backdoor if they aren't the one's listening.

At least, I assume Whatsapp is already compromised by some state actor and Facebook is getting some kind of funding to look the other way.</comment>


Entrepreneurs Beware: In the US, legal equality is myth - <AUTHOR>

This is NOT intended to be a political discussion. Yes, it can certainly take a deep and ugly dive in that direction. Let's have a discussion about how entrepreneurs can protect themselves in this environment.
Legal equality only exists when there's a good impedance match between the parties involved in litigation.
If you, as a small to medium entrepreneur, tangle with a large entity you could very well be screwed.  It really doesn't matter who is right.  He who has more money can prevail in spite of the facts by causing financial pain.  You either give-up or go broke fighting.  You are not receiving the same kind of "justice" they can effectively buy.
The same applies (sadly, apparently Aaron's case) to situations in which the government sinks it's teeth into you.  The whole idea of government-provided public defenders sounds great.  Then you realize that it is the equivalent of a call-center support person who's script always seems to call for erasing the operating system.  In other words, not a very good option when your life and liberty are at stake.
Again, I don't want to have this become a discussion about politics.  I think we can generally agree that our country is navigating an incredible surreal political period when it seems impossible to get even the most sensible things done.  Nobody is going to fix this until a significant tipping point of some sort is reached.  It's the "waiting for Superman" syndrome.  Don't count on it.
When the justice you get is directly proportional to how much money you can spend you can't really call it justice. I'm not sure we can even call it "the rule of law".
So, then, how does one protect life, property and the good-old pursuit of happiness when faced with the potential for being on the wrong side of this equation?  What should entrepreneurs do (or not)?  How have you dealt with it yourself? <comment><USER2> Your questions require buy in to a set of debatable premises. Your ideas are more appropriate for a blog post.

The way to avoid descent into a political discussion is to not post items likely to do so.

</comment><comment><USER3> Sometimes you don't have a choice but to get into a fight. In that case you would be right. Aaron had a choice. Raise awareness by educating the public about flaws in the law and work to change them OR raise awareness by provoking a fight. He chose the role of the heroic underdog. Aaron was a smart guy who made a bad choice. He wasn't strong enough to deal with the results of his actions.</comment>


'Technological fraud' discovered at Zolder cyclocross worlds - <AUTHOR> http://velonews.competitor.com/2016/01/news/uci_detains_bike_cyclocross_worlds_394233_394233 <comment><USER2> Although this is the first time something like this has been found in competition, I can remember a few prior allegations or instances that many people have found suspicious. So I don't personally find this to be a complete shock.

One thing I find interesting, for road cycling at least, is that the UCI mandated weight minimums could make it easier for a rider to attempt something like this. Many of the bikes need weights in the seat tubes to bring them up to the minimum weight, so the extra weight of a motor and battery wouldn't stick out as much. If they were to lower the 6.8kg minimum, a bike with motor and battery might end up weighing noticeably more than the average bike in the peloton.

<comment><USER3> Weight minimums are good for keeping a level playing field by keeping the cost to entry "low" by keeping it to the thousands. They're also good for safety reasons, both for the rider and others they might crash into; there's no incentive to try to cut too much weight in a way that could impact safety if there's a weight floor anyway.

The scanning is simply going to have to become pervasive.

<comment><USER4> > safety reasons, both for the rider and others they might crash into

What is the benefit supposed to be of getting hit by a heavier bike?

<comment><USER5> It's not the weight of the bike. It's the risk of a "stupid light"[1] component failing when you're at the front of the peloton and taking out you and most of the riders behind you.

[1] A component which has had its strength and durability compromised in the interest of saving weight.

</comment></comment></comment></comment><comment><USER6> Here's a good demonstration of the kind of tech we're talking about here from Greg LeMond [https://www.youtube.com/watch?v=vKgJ_Uhwfno](https://www.youtube.com/watch?v=vKgJ_Uhwfno)

<comment><USER7> Neat! I'm curious how much those kind of bikes cost, more for laziness than anything else ;)

Edit: [http://cyclingtips.com/2015/04/hidden-motors-for-road- bikes-...](http://cyclingtips.com/2015/04/hidden-motors-for-road-bikes-exist- heres-how-they-work/) \- Has some cool photos on how they work

AUD $4,300 - eek!

<comment><USER8> Why not just buy an eBike, there's a few under $1500 in this best of, and one sub $500

[http://electricbikereview.com/top-10-electric- bikes/](http://electricbikereview.com/top-10-electric-bikes/)

<comment><USER9> Decent road bikes (the one that you use more than 10k miles per year) are more than $2000 on their own. The electrical components go on top of that.

</comment></comment></comment></comment><comment><USER10> For competition, it makes sense not to allow motors. But why is this also somehow taboo for recreational cyclists? That's something I never understood. They pay thousands for carbon fiber bikes and special wheels all to make pedaling easier, but they could spend a fraction of that on electric assistance which could have the same effect - do less work to ride the same distance.

<comment><USER11> It is absolutely not. In fact Specialized makes a couple models. They're a lot of fun, but don't have wide adoption because they're a bit clunky and certainly much heavier than many bikes. Plus they're quite expensive. The people spending that much on a bike aren't the casual riding type typically and are racing (where is is against the rules), and the casual riders rarely spend that much on a bike.

I think they get much more widespread adoption when the systems get lighter and cheaper.

[http://www.specialized.com/us/en/bikes/electric](http://www.specialized.com/us/en/bikes/electric)

<comment><AUTHOR> there's already several fairly refined e-bikes around, look at the offerings by Haibike for example, only a few models are available in North America, but in Europe there is a very large selection

[http://www.haibike.de/produkte_liste_epower_en,3004.html](http://www.haibike.de/produkte_liste_epower_en,3004.html)

this said anecdotally I am seeing more and more people on e-bikes here in North America too, bike commuting every day these days at least a few times a week I get passed by somebody riding one of them, did not happen at all until a few years back

</comment></comment></comment><comment><USER12> Not as hilarious as more low-tech cheating: [https://www.youtube.com/watch?v=7E4vRtC7IcY](https://www.youtube.com/watch?v=7E4vRtC7IcY)

<comment><USER13> What am I looking for here?

<comment><USER14> At the 13 second mark you'll see the rider at the front of the pack, in light blue, getting approached by a car with the same colour scheme. Now try to keep your eye on that rider to the end of the video.

<comment><USER13> Thanks!

</comment></comment></comment></comment><comment><AUTHOR> I am wondering how long before only one bike is allowed for the stage, and there are tamper-evident seals on the bottom bracket for all bikes.

This said I wonder what principle(s) the "handheld detector" was operating under, maybe it could detect the winding(s) of the electrical motor via inductance or something?

<comment><USER15> In cyclocross, a single bike is a non-starter. Muddy courses lead to frequent bike changes and fast pit exchanges are part of the sport (not unlike pit stops in F1). Even at the amateur level, the top racers have two bikes and a mechanic in the pit to hand-off and clean bikes when the racer swaps them out.

<comment><USER16> I think what the parent might be meaning is that a single manufacturer produces all the bikes, so they're exactly the same, there's tamper-evident seals, and the teams are given the bikes just before the race.

This sort of high-tech cheating reminds me of Smokey Yunick's various tricks ( [https://en.wikipedia.org/wiki/Smokey_Yunick](https://en.wikipedia.org/wiki/Smokey_Yunick) )

<comment><USER17> Way too much money in having the big name bike sponsors all involved.

</comment></comment></comment></comment><comment><USER18> UCI will be releasing more information tomorrow, so hopefully there will be pictures. This is huge news because while there have always been allegations, nothing has ever been confirmed. Seems like they used some handheld device to quickly check bikes that were in the pit.

<comment><USER19> Apparently they found a bike with a motor in it, in the pit of one of the riders : [https://translate.google.com/translate?sl=auto&tl=en&js=y&pr...](https://translate.google.com/translate?sl=auto&tl=en&js=y&prev=_t&hl=en&ie=UTF-8&u=http%3A%2F%2Fsporza.be%2Fcm%2Fsporza%2Fwielrennen%2Fveldrijden%2F1.2559848&edit- text=&act=url)

</comment></comment><comment><USER20> > "I feel really terrible," Belgian national team coach Rudy De Bie told > Sporza. "This is a disgrace. I never imagined something like this would > happen to our team. Why would a rider do this? Especially at such a young > age. And who is responsible for her? I'm embarrassed on her behalf."

Oh yeah? I can't imagine such a cheat would pass overhead of the coach. It feels like VW executives saying it was a couple of zealous engineers..

<comment><USER21> Cycling (especially on a national team) isn't like other sports. Most riders have their own coach or trainer, and the national team only rides together for a few times a year.

For example, Lance Armstrong's "coach" Chris Carmichael (notoriously) had little to do with his training (Michelle Ferrari developed his training programs). Carmichael probably knew about his drug use, but it's likely there are plenty of other similar cases where a national coach had even less contact.

"National Coach" is often more akin to a manager/selector role.

Notably, in this case her father was her trainer. Apparently her brother is currently serving a suspension for EPO use[1].

[1] [http://cyclingtips.com/2016/01/more-details-emerge-about- mot...](http://cyclingtips.com/2016/01/more-details-emerge-about-motorized- doping-at-cyclo-cross-worlds/)

</comment></comment><comment><USER22> How much motor and battery can you get in a competition bike frame?

How much advantage can that provide, after taking into consideration the extra weight?

<comment><USER23> [http://www.vivax-assist.com/en/produkte/vivax- assist-4-0/viv...](http://www.vivax-assist.com/en/produkte/vivax- assist-4-0/vivax-assist_4-0.php)

"This model has three settings," he explained. "It produces between 50 to 75 watts for about an hour and a half, does 150 watts for an hour and in its highest setting, produces 250 watts for up to 30 minutes."

It can provide a substantial advantage at the high levels of competition.

<comment><USER15> Wow. I never imagined an in-frame motor/battery would produce that much power.

250W for 30 minutes is more than most non-racing recreational cyclists can manage.

<comment><USER16> Look at some of the brushless motors used in RC cars and planes ("drones" as the terminology seems to be today...) --- the power densities are absolutely amazing.

Here's a 4kW (more than 5HP!) motor that's less than 5cm in diameter and 10cm long:

[http://www.hobbyking.com/hobbyking/store/__21967__turnigy_c5...](http://www.hobbyking.com/hobbyking/store/__21967__turnigy_c580l_580kv_brushless_inrunner_motor_4000w.html)

One problem with fitting these into a bike is that they require plenty of active cooling to not overheat, but it shows that such power densities are definitely possible. Especially if for intermittent use with long periods of cooling. 4kW is also extreme overkill if all you're after is a small competitive advantage. As for batteries, 250W for 30 minutes is 125Wh, around the same energy as a typical 9-cell laptop battery.

<comment><USER9> Problem with those motors is you have to get from 10krpm down to 60-110rpm at the crank. This carries a surprisingly huge penalty in weight and efficiency, up to a point where it's a good idea to just choose a different motor.

</comment></comment></comment></comment></comment><comment><USER24> I am inclined to believe her when she says it's not her bike. In legal terms, the chain of custody was likely broken, and a lookalike bike got accidentally brought to the officials.

We'll see soon enough. With the amount of cameras and witnesses around it shouldn't be too hard to get to the bottom of this.

It will be interesting to see how the battery was hidden.

In Dutch: [http://www.demorgen.be/sport/van-den-driessche-fiets-is- van-...](http://www.demorgen.be/sport/van-den-driessche-fiets-is-van-vriend- zou-nooit-vals-spelen-b2bcd4b0/)

<comment><USER25> How could somebody have accidentally added a hidden motor and some electrical controls to a racing bike? Why would someone "on her team, who sometimes trains with her" have such a bike? It seems quite clear that either there was cheating, or a very inventive attempt to frame her.

<comment><USER24> > How could somebody have accidentally added a hidden motor and some > electrical controls to a racing bike?

I don't understand. Are you suggesting that's what I'm implying?

> Why would someone "on her team, who sometimes trains with her" have such a > bike?

Because it's a bike from a previous season she sold to them (a well known practice that even pro teams engage in to make some money on the side from bikes they get from sponsors), and they added the motor? And it's not someone on her team.

> It seems quite clear that either there was cheating, or a very inventive > attempt to frame her.

There's no logical necessity for choosing only those two scenarios. Here's another one: some guy bought an old bike of hers, added a motor so he could seem like a tough guy (in case he kept it secret), and it got mistaken for one of her bikes.

</comment></comment></comment><comment><USER8> UPDATE: UCI confirms motorised doping uncovered at cyclo-cross World Championships

> Van den Driessche was eventually forced off her bike on the final lap when > she was struck by mechanical problems and ended up walking with her bike. > Her bike was taken for inspection along with several other bikes after the > race. It gives Van den Driessche the dubious honour of being the first rider > to be discovered to be using a motor.

Which is slightly different to yesterday when it was reported as being discovered in the pits.

</comment><comment><USER26> Serious question: Why are cyclists such cheaters?

<comment><USER17> Let me introduce you to a little sport called baseball!

Also, I'm 99% sure the NFL's world is about to come crashing down when there is some sort of forced acknowledgement of how many players are taking HGH

<comment><USER26> American professional sports are commercial entertainment.

Cycling can't seem to decide whether it's a clean contest of human performance or a contest of artificial performance enhancement.</comment></comment></comment>


A Gentleman's Primer on Shorting Insolvent ShitCos - <AUTHOR> https://twitter.com/HedgeDirty/status/1254767346784313344 <comment><USER2> One of the best twitter threads I have read about the enormous difficulty of shorting stocks.

As any experienced short-seller will tell you, to be successful at it you either must be very, _very_ good at constructing portfolios that can handle the volatility, or you must limit your short-selling to situations in which you can identify a "catalyst" that will cause expiration within a predictable time frame.</comment>


In southern Brazil humans caused forest expansion between 1410 and 900 BP - <AUTHOR> https://www.nature.com/articles/s41598-018-24429-5 <comment><USER2> "1410 and 900 BP" means "540 and 1050 AD".

I'm not sure about the precision of the years. Why "1410" and not "1400"? Are those "10" years easy to measure or relevant?</comment>


Show HN: The Wisdom of Success - <AUTHOR> http://www.wisdomofsuccess.org

<comment><AUTHOR> Our company acquired the rights from the Napoleon Hill Foundation to distribute the original interview between Andrew Carnegie and Napoleon Hill.

Napoleon Hill used this interview to write the best selling book "Think & Grow Rich".

After reading the book, we decided to contact the Napoleon Hill Foundation to see if we can form a company to create an audio book and distribute the information online.

1) There's tons of free content on our Youtube channel if you want a sneak peak into the full 9 HOUR audio book:

[https://www.youtube.com/channel/UC13De-V1r_zjANgzAIsGZbA/vid...](https://www.youtube.com/channel/UC13De-V1r_zjANgzAIsGZbA/videos)

Thanks for your support! The principles of success are important to any startup.. including ours :) This is just a fun side-project.</comment>