Create React Apps with No Configuration - <AUTHOR> https://facebook.github.io/react/blog/2016/07/22/create-apps-with-no-configuration.html <comment><USER3> This is great since it provides an OFFICIAL opinionated set of tools for building React apps which is typically the largest barrier of entry for new developers looking to experiment with this technology.

However, it is missing a lot of core features that typically come standard with Webpack/React boilerplates. Directly from their Github:

Some features are currently not supported:

        Server rendering.
        Testing.
        Some experimental syntax extensions (e.g. decorators).
        CSS Modules.
        LESS or Sass.
        Hot reloading of components.

So a great first set of features for a simple React starter project, but for those of you looking to expand the development toolkit from this currently limited configuration, check out the following link to search React boiler projects on github based on a number of criteria like the ability to search by features included such as CSS Modules, Hot Module Replacement, etc.

[http://andrewhfarmer.com/starter-project/](http://andrewhfarmer.com/starter- project/)

For those looking to learn more about the ecosystem, the following resource lists might be useful.

More React resources: [https://github.com/enaqx/awesome- react](https://github.com/enaqx/awesome-react)

React/Redux resource links: [https://github.com/markerikson/react-redux- links](https://github.com/markerikson/react-redux-links)

<comment><USER4> Lack of testing is a pretty big oversight given how helpful testing is for someone getting started. Hopefully it is easy to just add mocha on top of this with out any mucking around?

<comment><USER5> It shouldn't be too hard.

This is not an oversight, we literally developed this project in a single week. We plan to add testing, just need to decide on the runner and good defaults: [https://github.com/facebookincubator/create-react- app/issues...](https://github.com/facebookincubator/create-react- app/issues/80).

<comment><USER6> I really would love to see all the "features" listed above (and more) as a part of this tool.

eg; `create-react-app --hot --less`

Including commonly-used defaults first, and adding full community bundling later, would be much appreciated. There are probably <10 such packages which would account for a wide range of the first week or so of any React project.

Good luck with this project and thanks a ton for dreaming it up & getting it out the door!

</comment></comment></comment></comment><comment><USER7> > Having just attended EmberCamp a week ago, I was excited about Ember CLI. > Ember users have a great "getting started" experience thanks to a curated > set of tools united under a single command-line interface.

This is one of the best things about Ember. `ember new`, `ember serve`, ember generate component my-component`, `ember build`, `ember deploy`, `ember install`. It's opinionated but it lets you get productive right off the bat. I tried React but after a couple of days I just couldn't get it working, waaay to many options. So I switched to Ember and haven't looked back.

<comment><USER8> Kind of interesting to think about the two projects and how they diverge based on the core developers.

Ember is made by folks who work on / for small and medium companies[1]. They don't have the build infrastructure Facebook does and are able to create an anointed solution in Ember-CLI because they'll use it daily. React is stuck in a place where the environment it's developed in is unique from what any other user will see. It's difficult to solve a problem when you're not in the space.

EDIT:

This leads to things beyond CLIs too. React is still billed as just a view library instead of a solution for building an entire app. There's no official path from view layer -> complete app (no guidance for data flow, how to communicate with the server, server side rendering, routing on the client).

I think the React team needs to take a little more responsibility for the eco- system it created. You can't call it just a view library when most use cases use it to develop entire applications. You have to provide more guidance, you can't fallback to Facebook not using it that way as the default response. In my opinion most of the Great Javascript Fatigue of 2015-16 was caused by users trying to fill in the blanks left by the React team and producing one solution after another (and quickly abandoning ship as something iteratively better was released).

1 - Tom, Yehuda at tilde.io

<comment><USER9> The idea that Ember is made by/for small and medium sized companies is a bit dated. Several Ember and Ember-CLI core contributors have and continue to work at larger companies like LinkedIn and Yahoo.

In particular, LinkedIn has been using Ember (with Ember-CLI) for over a year now and has found a lot of benefits from its adoption. Having a build system and conventions that a community maintains lets us focus on building applications instead of tooling (though we still have our share of internal tools). We also can give back to the community for things which matter more for applications "at scale". LI, for instance, funded a good portion of the FastBoot work and has been a key driver in the Ember Engines effort recently.

All that to say, Ember (and Ember-CLI) can serve the needs of the whole spectrum of company/team sizes. While it still has some issues to sort out for larger applications, to say it isn't being influenced by large companies isn't really accurate any more.

<comment><USER10> Having worked at LinkedIn in the past, and seeing the state (stagnation) of their products both current and past, that's certainly not a ringing endorsement.

</comment></comment></comment></comment><comment><USER11> I think one of the best things I've done to date is actually distance myself from the React community. While I love some of the tooling that has come out of it (Redux, React-Router) I think the community (as an amorphous entity) over-emphasizes the need/desire for transpiling, linting, testing, etc.

Since then, I've "reverted" to building things in ES5, working in multiple files without bundling, etc. and I have to say the enjoyment I get out of using React has cranked up considerably.

I am happy to see they are converging on some standards - that will definitely make building new apps much easier from a common starting point. I just hope they can walk the fine line between "opinionated" and "bloated".

<comment><USER12> I was just talking about this with coworkers... I love React but the community (aside from the actual creators and leaders like Dan) is too much for me and seem to love bloat and unnecessary features. The cynical side of me thinks a lot just do it for GitHub stars and blog views, but maybe not.

Of course, we just spent two days trying to decipher a React/Redux project whose lead dev decided to use every "latest" feature even though it's a good ol' CRUD app.

<comment><USER5> We think ES6 is not the problem here. It's just a language, and arguably a better one than ES5.

The problem is the low level tooling around it. This is what we're trying to fix with this project. Hopefully you'll give it a go, and maybe it will give you just as much enjoyment as using <script> tags. If not, please let us know how we can improve.

It's not linting/transpilation/bundling that's bad, it's that it's hard to do them without shooting yourself in the foot.

<comment><USER13> I think the problem is that React is developed as more of a Node/JavaScript project than as a web project. You see this in stuff like depending on `process`, a thing that exists in Node but not on the Web. So the Web is a compilation target; not the platform that React is developed for.

From there it's easy to think about everything in terms of JavaScript, and not making the Web the intended target for usage.

<comment><USER14> Yeah, along these lines, I also hate how most of the examples/tutorials online assume your server is Node.js. I'd love to find some _official_ documentation on the best ways to use it with Asp.net and Rails, for example.

<comment><USER15> That's usually because those tutorials are also setting up sever side rendering. Node.js is only needed for that and for running the various (optional) build tools.

When doing a SPA I often set up Node.js to serve the index and provide server- side rendering and then never touch it again. Any actual API/WebSockets/RPC interfaces the app needs can be serviced by any plain old Ruby, Python, PHP, etc app backend. Since I usually use PHP from old habits, I use a Symfony API- only application.

I posted about this in a top level comment, but don't forget React can control any element in your DOM and not just the entire body like most SPA's are setup. You can continue using whatever languages/frameworks templating and view systems and augment views as needed that would be better handled by React.

</comment></comment></comment></comment></comment></comment><comment><USER16> This is actually pretty huge. #1 complaint/barrier/hate with getting started with React is all the tooling to do it "the right way"

Kudos to React team for bringing a superior pattern and making it actually practical to use.

<comment><USER17> I'm really hoping to see the React team make React more user friendly. Maybe an all in one React framework much like Meteor, where you can just do `react createapp myapp` or something and start coding right away.

<comment><USER18> React is so versatile (raw React, React + Redux, React + Relay, to name a few) I don't think they should tie it too closely to one framework. I would love to see a more official/opinionated framework that uses React, but call it something besides "React".

Ditto for Redux. They're both low-level building blocks that could benefit from some official "opinions".

</comment></comment></comment><comment><USER19> This is great. React has this weird dual nature in that on one hand, you can drop it in as a <script> tag and it 'just works'. On the other hand, if you want to build using it, you're going to end up needing things like webpack, babel, etc, not to mention other common libraries, to the extent that it takes over your front-end stack (also because it takes over any rendered document nodes, and if you want to build a SPA you eventually use it to render everything inside <body> if not the whole document). So it's good to resolve this conflict by providing quicker ways to get started with common tools.

</comment><comment><USER20> This is the most exciting thing to come out of the ReactJS project since it started. The very best investment a technology platform can make is onboarding new developers. ReactJS is recognising that and it's great news that they are making the hardest bit easier.

I whined a while back on exactly this topic.

"Babel 6 - useless by default - a lesson in how NOT to design software. "

[http://fourlightyears.blogspot.com/2016/03/babel-6-useless-b...](http://fourlightyears.blogspot.com/2016/03/babel-6-useless- by-default-lesson-in.html)

The last line of the above griping blog post says: "The right amount of configuration is none."

So it is awesome to see someone who DOES know how to design software.

Dan Abramov's blog post says: "Zero Configuration. It is worth repeating: there are no configuration files or complicated folder structures. "

Babel gets it precisely wrong, this new ReactJS tools aims to correct the Babel complexity error.

<comment><USER5> Babel doesn't get it wrong, it just wants to be a lower level tool. You can (and should) build on top IMO.

</comment></comment><comment><USER21> This is lacking tons of features that other boilerplates already have but I think this was a great move because we needed a source of truth for doing app structure in React.

In a different note, I think if you write it yourself from scratch you'll have more control and knowledge down the road when it comes to nasty bugs but I won't blame you for choosing this over spending weeks setting up a React app.

<comment><USER22> If you work with React a lot, you can setup a React project to your taste in about 30 minutes. But the catch being if you leave React for a while then come back, all bets are off.

I think most boilerplates add way too much and are overly opinionated. I like that this is simple, and "eject" gives power users an even better starting point.

<comment><USER23> Totally. My first React setup took me two days to get right. Now, starting a new project is a 5 minute exercise in CLI autocomplete that has me wishing npmjs downloads were faster. It's surreal to think that for any popular technology, there will always be newcomers, no matter how long that technology has been around. I would write up my process in a blog post, but I'm sure that that has already been written several times.

<comment><USER23> Going back over my old projects and finding four different flux implementations, that is a new and interesting kind of suffering. The crazy thing is, I never even liked flux in any of its forms. What I really want, is pouchdb / couchdb, but even that is not perfect, and my team has no problem poking holes in weird ideas.

Right now, I'm going through the Om.next tut series, and it is pretty awesome so far. I think I'm going to pass on datascript, though. This is total skunkworks though, if people at work found out that was using clojurescript on the front end, they would be very concerned about me.

The killer feature for Om.next, imo, is using a reader function to define the relationship between a component and the one application state atom. Combine that with an identifying function that associates a component with a field in the application state, and you enable the framework to make very precise component updates.

</comment></comment></comment></comment><comment><USER24> Under the hood this is Webpack + Babel + ESLint with sane initial configuration. Love it.

<comment><USER25> This is all I ever want in a React boilerplate, but everyone feels the need to throw a bunch of random shit into them that others probably do not even want. Glad they kept it sane and simple.

<comment><USER11> In all fairness, I think that flags that provide some basic bootstrapping for Redux and/or React-Router would be very spiffy - those tools are useful for many React applications.

<comment><USER24> I think Redux and React-Router are very opinionated and distract people new to React from React itself.

My workflow for ramping someone up on React and eventually Redux looked like:

\- A single React component with React.createClass

\- ES6 class React components

\- Add a component hierarchy and treat the top level component's state as the entire app state - pass down callbacks to update state. Look how this becomes harder to scale as we get more depth in our component hierarchy!

\- Redux without the redux-react bindings. Also stateless function components.

<comment><USER11> I agree. That's why I would put them behind flags. Even though most of my own projects wind up using them, I tend to start from a clean slate and apply things only as they become relevant.

</comment></comment></comment></comment></comment><comment><USER18> I think the best part of this is the "eject" feature. It's great to be able to spin something up quickly but migrate to a custom solution if you outgrow it.

However, it would be nice to be able to tweak some of the configurations (Babel, ESLint, Webpack) without completely "ejecting".

<comment><USER5> If we let you tweak them, any minor update on our part would be a breaking change. We wouldn't be able to introduce new features or update the underlying tools without a lot of risk. This is why we don't let you change the configs.

If you have a specific pain point, please file an issue. I think we can make defaults better. It takes more work but is more rewarding in the end because it benefits everyone.

<comment><USER26> This is super useful for helping beginners overcome initial barriers and quickly become productive, but do you see this as something that most will eventually grow out of?

<comment><USER5> When you grow out of it, you run "eject" and customize everything you want.

We think in the beginning many will "eject" but we will gradually make the defaults better to cover more and more use cases.

<comment><USER18> That makes sense, but I think there will always be people who want to tweak ESLint rules or enable new Babel features, but would still like to take advantage of improvements to this project.

Perhaps exposing a subset of those tools' configuration options would be sufficient.

Alternatively, you could imagine a pretty simple system that allows you to pull newer versions of the "ejected" code and handle merge conflicts using your version control software.

I'd also suggest reducing the amount of non-configuration code that's generated by "eject". I think basically everything in "scripts" could be put into a package ("openChrome.applescript" seems like it should be a feature of opn anyway). That would also reduce the number of devDependencies that need to be added to your project's package.json (rimraf, chalk, opn, etc)

</comment></comment></comment></comment></comment><comment><USER27> My team has wasted so much time configuring webpack. This is a big win for React IMO.

<comment><USER28> This right here is why I actively suggest not using webpack. It's Grunt 2.0 all over again and not worth the mess.

IMO it's the worst choice Facebook could have made for this toolkit, as it breeds some awful habits.

<comment><USER27> I actually use browserify for personal projects. It's ultra simple to get started. My boss insists on using webpack.

<comment><USER28> If you don't care about the stupid arbitrary bundling system for other assets (like CSS and images) that WebPack has (and you shouldn't: it's an awful code practice) then yes... Browserify is literally better in every way (other than tree shaking)

<comment><USER5> _> If you don't care about the stupid arbitrary bundling system for other assets (like CSS and images) that WebPack has (and you shouldn't: it's an awful code practice)_

The "stupid arbitrary" system has a number of benefits. It revs your assets for production automatically with content hashes. It saves you from filename typos because all assets (CSS, images) are part of the same build pipeline. It throws on parse errors in CSS as part of your normal dev flow, not at some later stage. It allows for fast hot reloading of styles in development.

The only downside I'm aware of is that it doesn't work with some other tools without special plugins or configuration. Well, you have to pick your tradeoffs, right? I'd love to talk about technical tradeoffs of both systems but your comment reads more like a knee-jerk reaction than a technical assessment.

<comment><USER28> > The "stupid arbitrary" system has a number of benefits.

Yes, it does. Those features aren't exclusive to webpack though (they're really, really, really old features of webdev) and can be replaced by much less silly systems.

I mean literally everything you just listed is _better_ handled by more mature, developed, tools.

</comment></comment></comment></comment></comment></comment><comment><USER29> I'm sucker for self descriptive "boring" names like "create-react-app"

Also, sweet project!!

</comment><comment><USER30> This is a great idea and sorely needed. Too many frameworks rigidly avoid integration with the ecosystem because they do not want to be seen to bless any given third party technology.

In the case of reactjs however it is extremely important because the ecosystem is absolutely necessary and absolutely damn complicated.

This is precisely what needs to be done to help people get started. Well done.

</comment><comment><USER31> I'm fairly close to finishing the conversion of my `dev-toolkit` into an npm- module. It is almost no-config, has scss, server-side-rendering, hot-reload and more. I'm a one man band but will get there. It's all on [https://github.com/stoikerty/universal-dev- toolkit](https://github.com/stoikerty/universal-dev-toolkit)

The npm-version sits in a feature branch, just look for the corresponding PR if you're keen.

<comment><USER31> I have a release ready. Just pinned it at 5.0.3 It is similar to `create- react-app` but also has CSS-Modules (with SCSS) and a few other features like Browsersync and root-relative imports.

Hope anyone reading this finds it useful :)

[https://github.com/stoikerty/dev-toolkit](https://github.com/stoikerty/dev- toolkit)

</comment></comment><comment><USER32> So I was looking through the modules in react-scripts module and I noticed postCSS, HMR is activated (I tested this myself). I also installed react- router with ease and it appears to work just fine. So far so good from where I'm sitting. I was able to start coding right away while I was half assed looking through the modules to see what is actually in there and just play while I talked with my roommates. It took me all of 10 minutes.

</comment><comment><USER33> Loving it! I always wanted to get started with ReactJs but looks like time has come! I tried the module and I am loving the "Welcome to React" page on my localhost! Thank you!!!

PS. Already in /src/App.js , and wow live reloading without gulp or browersync , it is so simple to get started! Thank you!

<comment><USER34> I thought the live reloading was just for CSS?

<comment><USER5> Yep. For components we refresh the page now. (Automatically still.)

</comment></comment></comment><comment><USER35> As someone new to React, I wonder

a) How is this different from getting a custom starter kit/generator from Yeoman. Searching in yeoman, I see several for "React" with the top one having over 9.5k stars [http://yeoman.io/generators/](http://yeoman.io/generators/)

b) Is Facebook planning to maintain and keep this generator current? Why don't they just contribute/recommend an existing generator

<comment><USER5> This is not a generator. It is a dependency, which means that we can (and intend to!) update the underlying tools without any work on your part.

Additionally, unlike a generator, it doesn't expose you to any configs so you can focus on your code. However you can "eject" if you really want to.

</comment></comment><comment><USER36> Sane defaults and pieces made to go together are critical to lowering the adoption barrier and building a community, so huge props for that. But no ability to configure anything at all? I think that for most people, at some point there will be some small change to the default configuration their environment will require[1], and that means they'll need to jettison the entire project. It's nice that this is easy to do, but it would be better if it weren't necessary.

[1]: For example, I run my app from within a Vagrant Virtualbox machine that doesn't forward filesystem notifications correctly, so I have to configure Webpack's hot reloader to poll for changes instead of listening for fs events.

<comment><USER12> [https://facebook.github.io/react/blog/2016/07/22/create- apps...](https://facebook.github.io/react/blog/2016/07/22/create-apps-with-no- configuration.html#no-lock-in)

> "Ejecting" lets you leave the comfort of Create React App setup at any time. > You run a single command, and all the build dependencies, configs, and > scripts are moved right into your project. At this point you can customize > everything you want, but effectively you are forking our configuration and > going your own way. If you're experienced with build tooling and prefer to > fine-tune everything to your taste, this lets you use Create React App as a > boilerplate generator.

<comment><USER5> We'll start with extremes (no config vs all config is yours) and see how people use it. Perhaps we'll add some configuration later but if we do it too early, we might as well become another webpack.

Configuration makes it very hard to move forward or swap underlying tools. So we'll stick with no configuration for as long as we can, and try to figure out a way to solve common problems by other means (e.g. smarter detection, platform-specific code, etc).

<comment><USER20> Please Dan keep it zero configuration.

If a person knows enough to want to configure, then they have learned enough to venture out on their own via eject.

The difference in cognitive load between "zero config" and "some config" is enormous.

"zero configuration" === minimal mental model, no scope for misunderstandings, misconfigurations, minimal documentation, almost no scope for user errors and also minimal learning time

"some configuration" \- _even one single switch /option_ === learning the mental model, understanding, version problems with the old way of configuring, documentation of configuration, potential for errors, old & out of date blog posts on the Internt telling how to do it the old way, beginner pain

You will come under constant pressure from people who want to add "just this one teensy option" and will criticize the project for not having it. Resist the criticism - beginners need zero config.

The root of all evil in JavaScript development and build systems is configuration.

</comment></comment></comment></comment><comment><USER37> Incredible turnaround! I remember seeing Dan Abramov's tweet [1] a while back saying React could learn from Ember's CLI. Two weeks later, here it is! Impressive!

[1]: [https://twitter.com/dan_abramov/status/752863664290553856](https://twitter.com/dan_abramov/status/752863664290553856)

</comment><comment><USER25> After spending hours yesterday teaching a colleague about webpack, babel, configuration, etc, this is exactly what the React community needs. Finally some fucking sanity in the ecosystem.

</comment><comment><USER38> Finally something that may convince me to switch from [https://github.com/thardy/generator- ngbp](https://github.com/thardy/generator-ngbp) \- all I want is to focus on writing components not figuring out how to link gazillion dependencies

</comment><comment><USER39> The day we now see "compiled successfully" in the Command Line as the necessary "easy" starting point for frontend web devs.

</comment><comment><USER40> This is great and I will be moving my React projects in this direction. At very least this project represents a de-facto standard and guidance about how to work with React.

However I do wish the React team would pick between ES6 classes and `React.createClass`. I think I remember the main React tutorial was rewritten in ES6 at one point, but then switched back. I've read arguments both ways, but I suspect they ES6 is still too much of a barrier to entry.

People who aren't up to speed with ES6 will still be shaving a lot of yaks before actually jumping into React.

<comment><USER41> If you're using create-react-app then you're encouraged to use ES6 classes - that's how the default App.js is set up.

<comment><USER5> >However I do wish the React team would pick between ES6 classes and `React.createClass`

We're going with ES6 classes. Expect createClass() to go into another package some time this year.

(Obviously we'll provide an automated "codemod" utility to convert your existing code.)

<comment><USER42> Please say it isn't so! Class is terrible syntactic sugar to please old Java programmers. I'd be really interested in why this decision would be made. Im just getting going in React and am looking to make a move away from Angular, because Angular 2 is so hyper focused on classes and decorators. I like React because it's closer on the purity scale to something like Cycle.js.

But nevermind me, React is a great tool, and this is a very nice and needed project!

<comment><USER43> React's lifecycle methods and other similar features require some kind of "object instance" to exist. Since React was created prior to ES6, the React team created their own "inheritance"-ish approach, which is something that every JS library out there was doing as well. One of the main arguments for classes being included in the ES6 standard is that it's a common approach that libraries can converge on and use together, rather than every library inventing their own version of inheritance.

Since ES6+ is now the actual Javascript language standard, it makes sense for React to move away from their homegrown class definition approach, and build on top of the approach that is now standardized in the language. The React community has already eagerly adopted ES6, and while React.createClass() isn't going to be deleted any time soon, it's time to start encouraging people to move away from using it.

Either way, though, React's API _does_ depend on having something "class"-like available.

<comment><USER5> Exactly.

We don't like classes, but we don't like "pseudo classes" (createClass) even more. Better the devil that's standardized.

We already offer a way to create stateless components with just functions. We will keep exploring that space and eventually might have a class-less solution we like that satisfies all our use cases.

<comment><USER44> One thing though, is that the standard classes are just not up to the job without a lot of stuff tacked on. Eg: the function binding problem pushes people to use class properties, which aren't yet a standard, and then they hit walls with tools that don't support them (eg: I dunno if it's still the case, but for a while class properties caused issues with Flow).

createClass might not have been the answer, but on top of stateless component functions, things like the good old ES3 module syntax honestly would be more flexible/powerful (giving you a closure to do things like private members, etc)

Instead we have people using babel with all sorts of plugins, tacking on 3rd party decorators and utilities, and a bunch of other cruft just to mimic features JavaScript have had from the beginning. And then (talking out of my rear here), it possibly put pressure on the TC39 to waste time discussing features we seriously don't need.

<comment><USER45> There was not such thing like ES3 module syntax. This is just programming pattern many people used: [https://addyosmani.com/resources/essentialjsdesignpatterns/b...](https://addyosmani.com/resources/essentialjsdesignpatterns/book/#modulepatternjavascript)

It was a great idea back then, but that was never syntax. This and similar patterns rely on the fact JavaScript is very dynamic and flexible language and enables creating closures and creating objects dynamically.

These are very powerful features of language, but they're dynamic, which is unfortunate because to know what _exactly_ is happening in this code you have to run it. for IDEs/editors it's hard to look at your code and guess "well, it's module pattern, I see! You mean this and that". Tooling operates usually on static analysis of syntax. They use JS parsers to parse code to AST(Abstract Syntax Tree).

And here's the thing: ES6 classes are visible in AST, there is something called ClassDeclaration. This means that every programmer can install some ES6 parser from NPM and analyse ES6 classes. This means that there will be better linting, better autocompletion etc.

On the other hand - JavaScript parsers don't understand module pattern or other homegrown idioms. It's harder to analyse them statically. Especially if they rely on dynamic aspects on language. ES6 parser doesn't run your code. That's why ES6 classes, because they're static, are better for parsers, and consequently, enable better tooling, IDE support, autocomplete etc.

Situation maybe were a little bit different if we had tooling for some sort of dynamic analysis (if tools were running code in sandbox and gathered data in runtime, not from syntax etc.).

But because currently most of tooling is syntax based I think ES6 classes (and e.g. ES6 modules) are just better for analysis.

Well... to contradict what I said early I must say that actually it's often possible to analyse such things like module pattern, createClass etc. But:

1\. not always with 100% certainty of the result

2\. there are too many idioms. If every framework, every team and every programmer has own way of writing JS, own module syntax, own class syntax etc. it's very hard to support all the frameworks and provide tooling for all people...

<comment><USER46> Classes don't do anything about the dynamic nature of JavaScript. They spit out basically the same constructor that everybody was using for pseudo-classes in ES5. You can still do crazy things like manipulate the prototype outside the class, tack extra stuff onto instances after they've been instantiated and so on...

In other words, classes in JavaScript are a poor substitute for static types, and should not be used that way. That's why a lot of React people are using flow, and a lot of Angular people are using TypeScript.

<comment><USER45> Yeah. You're right that even classes allow for great amount of dynamics. I've seen classes with decorator annotation and decorator can change classes as much as it wants. I've also seen patterns like:

class Foo {... }

// then, after class definition

Foo.A = X;

Foo.B = Y;

etc.

So... it seems that every try to make JS more static is doomed to fail... Because people will still use it in dynamic way...

Not sure how to solve this problem. Maybe we really need tooling that would run code in sandbox instead of analysing it via AST (but how to sandbox e.g. NodeJS code that interacts with file system or MongoDB? Mocking everything? Or make complete dev environments/virtual machines with NodeJS code running in it?)

(Maybe I overengineer solution ideas in my head, but I think proper tooling support is important for modern web development. It hurts me when I have to learn new large JS codebase and IDE is not helping)

> That's why a lot of React people are using flow, and a lot of Angular people > are using TypeScript.

I don't like the idea of defining types for everything but maybe it's the solution (I'm not sure because I have too little experience with TypeScript to judge).

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> Do not forget React is not equivalent to an SPA.

Almost all SPAs give the entire body over to React but its also possible to choose a smaller DOM node and add React progressively to any existing website view that would benefit from the React paradigm. In this setup (at least) server-side rendering is no longer needed and thus simplifies setting up the build process.

So its not all or nothing, you can pick and choose where to use React based on your needs and requirements.

</comment><comment><USER45> it seems like a solution to the Vjeux's challenge: [http://blog.vjeux.com/2015/javascript/challenge-best- javascr...](http://blog.vjeux.com/2015/javascript/challenge-best-javascript- setup-for-quick-prototyping.html)

(If we don't count _sharable_ requirement).

<comment><AUTHOR> Integration with now.sh ( [https://zeit.co/now/](https://zeit.co/now/) ) and uploading to gh-pages is something that was cut for the release but we are thinking about doing :)

</comment></comment><comment><USER47> > Some features, such as testing, are currently missing. This is an > intentional limitation, and we recognize it might not work for everybody.

With Ember CLI you get a great testing setup with Qunit. While I prefer Mocha over Qunit, I'm at least glad that testing is a first class citizen in the CLI.

<comment><USER48> and its easily swappable: [https://github.com/switchfly/ember-cli- mocha](https://github.com/switchfly/ember-cli-mocha) (and fully integrates with the existing test harness, regardless of the test framework you choose.)

</comment></comment><comment><USER49> This is great! Toolchain pain really sucks, and makes being able to get started on a project harder for many, when all you want to do is get a setup running and start creating app code. Having an opinionated CLI start up a scaffold is great - one can also peel apart this whenever one has to prepare for modifying the build chain for specific purposes (for example using Rollup to optimize bundled code, adding new build steps, etc.).

The only thing I disagree with here is not allowing it to be pluggable - <USER2> it should be flexible and allow users to tweak the setup as desired. Of course, it should focus on getting the core experience right, but in the long term I absolutely think it would be better to have a pluggable CLI.

<comment><USER20> Toolchain pain is closely related to configurability i.e. "having a pluggable API".

Your choices for this type of tool are zero configuration with no pain, or configurability with pain.

You can't have it both ways. In the JavaScript world, configuration and pain are synonyms.

<comment><USER49> > In the JavaScript world, configuration and pain are synonyms.

This is outright false. There is some relation, but not all configuration results in pain.

<comment><USER20> It's a good enough slogan.... if more developers took it to heart then JavaScript development would not be the torturous process it is today.

Any time anyone thinks about adding a configuration option they should think again and if humanly possible, take the configuration option out.

Developers love making things configurable - it's a way of avoiding tough decisions about what software should and should not be able to do.

The best developers are constantly looking for opportunities to remove configurability without compromising the goals of their software.

<comment><USER49> If it's wrong, it's not good enough.

I don't disagree that configuration is awful, especially if it isn't well thought out, but some configuration is unavoidable & even preferable in some situations (for example when dealing with differences between production, qa, and dev environments). Dismissing configuration wholesale though is laziness. All things should be considered carefully, and blanket statements serve little good.

</comment></comment></comment></comment></comment><comment><USER50> I created something similar a month ago

[https://github.com/olahol/reactpack](https://github.com/olahol/reactpack)

Doesn't seem like this project differs that much, although this looks to have the backing of core React developers.

<comment><USER51> I don't get why they would need to lock down the configuration and then have to offer the eject thingy.

Couldn't they just offer a "facebook-certified" starter pack/bootstrap?

I guess you could just do an immediate eject?

Edit: looks like they contemplated that in the survey: "Yes, and I will run `eject` straight away"

<comment><USER5> Many people (especially beginners) appreciate automatic updates of their dependencies. If you eject straight away you'll have to manage them yourself, which is a big turnoff to many.

<comment><USER51> Could there be some sort of npm feature that incorporates a remote list of dependencies & versions?

<comment><USER5> Yep, it's called a "package". ;-)

<comment><USER51> So could whatever create-react-app is delivering be substantially approximated with an npm-based solution?

<comment><USER5> create-react-app _is_ an npm-based solution.

</comment></comment></comment></comment></comment></comment></comment><comment><USER52> There is an alternative solution that supports CSS Modules, PostCSS and HRM with React Hot Loader. Give it a try! Create a new folder for your project, then run:

        npm install -g react-app-tools
        react-app new
        react-app start

[https://hashnode.com/post/react-redux-without-webpack- ciqylw...](https://hashnode.com/post/react-redux-without-webpack- ciqylw5ux02a2oh53w5k15cw1)

</comment><comment><USER53> This is a great start. I too got frustrated with the overwhelming complexity of the "boilerplate" or "starter kits" that have all the bells and whistles. Having something very simple that you can exit if necessary is nice. The approach I took was just to document each tool or plugin that I may want to add to my project since it is generally very quick to do so: [https://github.com/bruth/modern-javascript- starter](https://github.com/bruth/modern-javascript-starter)

</comment><comment><USER54> This is really great! However, I think this speaks to the need for a better API in general for this sort of stuff.

At the moment it's "all or nothing" in that you can decide to let everything be configured, or nothing be configured ("ejecting"). This makes perfect sense, but I think a more ideal solution would be having layers of configurability that let you more gracefully set your preferences without completely abandoning this tool's utility.

I'm not saying that's easy, but it's a direction I'd be excited to see.

<comment><USER5> I'd love that to be possible but "all or nothing" is useful as a forcing function for us to choose great defaults. We might want to relax it a little someday, but doing it too early will harm the project.

</comment></comment><comment><USER55> Very very awesome. This is very much needed. I work with a lot of older Java people and showing them the ins/outs of webpack/eslint/React is killing productivity. Thanks FB.

</comment><comment><USER34> I've solved my webpack config woes by using HJS-Webpack[0] which describes itself as "Helpers/presets for setting up webpack with hotloading react and ES6(2015) using Babel."

It provides you with a base configuration object, which has been setup with any loaders that it has detected in your node_modules. You can then extend and customize as needed.

[0] [https://github.com/HenrikJoreteg/hjs- webpack](https://github.com/HenrikJoreteg/hjs-webpack)

</comment><comment><USER32> This was one of the downsides to us using React at work. I did a presentation on Webpack and React and my manager who is the VPE said having to figure out and choose tooling was a concern for him. I responded we should know what the tooling is doing and introduce pieces into our stack rather than go all the way in. This allows us more freedom on how and when to upgrade or change different tools in our front end stack.

</comment><comment><USER56> This is awesome. Learning the whole modern build ecosystem was such a headache. It's great it see best practices rolled up for new users to experience.

</comment><comment><USER57> This is great. One of the biggest hurdles is getting started which is why there are so many react boilerplates. It would be awesome to see projects like this grow so that it would auto configure based on libraries you would like to use. Want to use Redux? Just run the `create-react-app -m redux hello-world ` and you would get everything with the addition of redux and it's configuration.

</comment><comment><USER58> Is it me, but is not Angular just taking over? Kind of Google vs Facebook thing. Just think Google won this one.

<comment><USER49> Eh, it's not a winner takes all war - it's the quest for continual experimentation and improvement on the tools available to us for improving how we build apps. The winners are all of us.

</comment></comment><comment><USER20> Covered on TechCrunch [https://techcrunch.com/2016/07/22/facebooks-new-open- source-...](https://techcrunch.com/2016/07/22/facebooks-new-open-source- project-makes-it-easier-to-get-started-with-react/)

</comment><comment><USER59> Definitely a great way to lower the barrier to entry. The eject feature is sweet since it removes the risk of lock in. Looking forward to integrated unit testing libraries in a future release. While you're at it let's add redux. :)

<comment><USER5> We won't add runtime dependencies besides React for now. We are focused on solving build tooling first.

</comment></comment><comment><USER60> This is great for someone who wants to get started to learn React, but is _missing a ton_ that is needed for a real world production app.

      * No isomorphic rendering
      * No hot module replacement
      * No generators
      * No dockerization
      * No Sass support
      * No test environment setup
      * No code splitting

It would be cool to have a production ready tool from Facebook, but I'll stick with gluestick for now [https://github.com/TrueCar/gluestick/blob/develop/README.md#...](https://github.com/TrueCar/gluestick/blob/develop/README.md#why- your-project-or-boilerplate-isnt-enough)

<comment><USER8> What an odd and arbitrary list. SASS support over LESS over PostCSS over CSS in JS? Component boilerplate generation is required for production? Hot module replacement is required for production? Everyone using React is looking for an isomorphic solution? Docker support?!

I think the point of the project is to acknowledge that React requiring transpilation to use is 100% accurate and there needed to be a transpilation / workflow solution to make it easier to adopt. It wasn't let me solve every single problem for you, including setting up your production deployment environment using Docker.

<comment><USER28> > SASS support over LESS over PostCSS over CSS in JS?

Well yes, because any CSS in JS solution (in PostCSS) is just plain bad for a myriad of reasons.

That would leave you with SASS vs LESS and SASS is massively more popular and supported.

<comment><USER61> I think parent was suggesting inline styles

</comment></comment></comment></comment><comment><USER62> For CLI generation utilities, I haven't found anything that comes close to this guy:

[http://fountainjs.io/](http://fountainjs.io/)

</comment><comment><USER63> Expectation: \- "Hey, look, this can SOLVE ALL THE PROBLEMS"

Reality: \- "Hey, look, this actually BRINGS IN A WHOLE LOT OF OTHER PROBLEMS too!"

:sad:

<comment><USER64> Would you mind explaining which new problems this creates?

<comment><USER28> WebPack for one. Using webpack brings in way more problems than it solves.

<comment><USER64> Again you've suggested the introduction of problems without mentioning a single one. I'm not saying you're wrong (because I don't know what you're saying yet), but I don't think you're adding much to the discussion here.

</comment></comment></comment></comment><comment><USER65> This is really neat. especially the fact that I can 'eject' at any time when I need more power. Love it!

</comment><comment><USER66> Is there something like this for React Native? I'm interested in recommended directory structure.

<comment><USER67> This is kind of built in to React Native already, but they use their own packager (ReactPackager) instead of webpack. Would be neat for ReactJS and React Native tools to converge at some point!

</comment></comment><comment><USER68> Does this help with React Native too?

<comment><AUTHOR> React Native already has `react-native init <project-name>` command that works in a similar fashion.

</comment></comment><comment><USER69> wanted to share [http://github.com/uptownhr/kube](http://github.com/uptownhr/kube). I also wanted to tackle this problem but also handling SSR as well.

<comment><USER69> but handles SSR as well.

</comment></comment><comment><USER70> Having a consistent API with ember-cli will make this more useful.

$ react-cli <>

<comment><USER71> Only for those used to ember-cli. For the huge majority this is irrelevant.

<comment><USER70> It provides a consistent mental model across frameworks for building front-end applications via CLI.

<comment><USER5> This would make people expect us to implement everything it does. We currently don't plan to.

</comment></comment></comment></comment><comment><USER72> Just wanted to know, am I the only person who is unhappy with react ?

<comment><USER73> There are 7.4 billion people in the world. It's safe to assume you hold no unique opinions.

</comment></comment><comment><USER74> This is not a react problem, this is a nodejs problem.

</comment><comment><USER75> What the heck is that terminal font?

<comment><USER76> Operator Mono

</comment></comment><comment><USER77> Amazing.

</comment><comment><USER78> Looks cool

</comment><comment><USER79> Thanks !!!

</comment><comment><USER80> In the spirit of zero configuration, it would be nice if it included Standard JS [https://github.com/feross/standard](https://github.com/feross/standard)

<comment><USER73> Please no! One person's "standard" is another person's "Please no!".</comment></comment>


Andrew Chen: What's your viral loop? Understanding the engine of adoption - <AUTHOR> http://andrewchen.typepad.com/andrew_chens_blog/2007/07/whats-your-vira.html

<comment><USER2> Does anybody else feel slightly uneasy about the modern practice of requesting user account information to gather all social links of a user (email is worse than MySpace, I guess, but still).

I wouldn't want my friends to submit my email-address anywhere, it is hard enough to keep spam in check as it is.

Also I think just having such a pesky "recommend me" form is not all there is to viral marketing. Some products can also be inherently viral, if they require several people to use. An example would be a multiplayer computer game. Slideshows and Photos are not that viral in comparison, because you can just watch photos passively.

<comment><USER3> "Some products can also be inherently viral, if they require several people to use. An example would be ..."

You fail at marketing 101. The point of marketing is that can greatly increase your adoption. Even if your product is the best thing in the whole world -- that doesn't at all mean that adoption of it will spread like wildfire.

<comment><USER2> I thought the point of making it viral would be to make it spread like wildfire? What does marketing 101 say about this? My guess is that "viral marketing" is not yet a word that is used in marketing 101.

</comment></comment></comment><comment><USER3> Article would have been useful with many more examples.</comment>


Amazon is the new Walmart - <AUTHOR> http://www.businessinsider.com/amazon-is-the-new-walmart-2017-8 <comment><USER2> What everybody can agree with is that AMZN stock price is massively overvalued.

Amazon is on low margin retail business. Amazons market cap is $475B. Assuming 10% ROI and 3% profit margin, Amazon must make $16 trillion in revenue some time in the future to justify the current price.

US retail sales are $5 trillion.

Total retail sales across the globe are $22 trillion.

Even if Amazon continues to grow at current pace, it runs out of markets to dominate before current stock price can be justified.

Bezos announced that he is unloading $1B per year. Smart man this Bezos guy.

<comment><USER3> If there's one thing that I've learned from living through the first internet bubble is that there's no such thing as a stock price that's "too high" or "overvalued". Some people will pay anything as long as they think they think they can sell it for a profit to the bigger fool.

<comment><USER2> This is true.

Unfortunately markets have limited supply of fools with money. When the supply runs out, there is a correction.

Figuring out when the correction happens is hard. It can take several years before the AMZN value is corrected. I would say that it happens within three years, but I could be wrong.

<comment><USER3> People were constantly predicting Amazon's fall (and that of a ton of other skyrocketing stocks) throughout the whole of the first internet bubble. They were all wrong, until they were right.

<comment><USER2> There is difference between company failing and company price collapsing. Amazon may do fine, it's just that Amazon's price will be radically adjusted.

When Internet bubble busted in last time. The Four Horseman of Tech (Microsoft, Dell, Cisco and Intel) lost 75% of their market value.

Intel was valued $73.94 in 2000, now it's 36.3. The value of the stock never recovered even if the company is still going strong.

Microsoft's value has been below it's bubble valuation 16 years and it broke it's previous record last year.

It took Amazon stock price 10 years to recover from 2000 bubble.

</comment></comment></comment></comment></comment><comment><USER4> Amazon is the Middle/Upper classes Walmart.

It's hard to have a package sent to you if you don't have a secure way to grab it.</comment>


Copyright, Fraud and Window Taxes (No, not that Windows) - <AUTHOR> http://www.oblomovka.com/wp/2008/08/07/copyright-fraud-and-window-taxes-no-not-that-windows/

<comment><USER2> _Copying as the tapping point for revenue redistribution, and correct attribution and sourcing as a side-effect of that._

Brilliant formulation. I'd note that the attribution requirement needs to be relaxed sometimes, too. It is a well known problem with the CC-BY family of licenses when applied to art. Mark Pilgrim said it well at <http://diveintomark.org/archives/2007/03/05/cc-dogs> :

 _Now imagine that every time you upgraded your kernel and rebooted your Linux box, you had to scroll through 741 lines of credits. 741 _additional_ lines of credits, cumulatively. Creative Commons is fine for one-generation remixing. But you quickly hit a wall, either from data degradation, or cumulatively onerous license requirements, or some other damn thing._</comment>


Be notified as soon as Google Chrome for Linux is available - <AUTHOR> http://www.google.com/chrome/intl/en/linux.html

<comment><USER2> Mac version:

<http://www.google.com/chrome/intl/en/mac.html>

</comment><comment><USER3> I'm sure it'll be all over slashdot/digg, maybe HN too

<comment><USER4> yeah I was just thinking why people care to know about something before it is released doesn't that just build anticipation? - trust me when it comes you won't miss it</comment></comment>


Radon Transform - <AUTHOR> https://en.wikipedia.org/wiki/Radon_transform <comment><AUTHOR> Apparently used by CAT scans, and Computed Axial Lithography, to name a few uses...

>"The transform was introduced in 1917 by Johann Radon,[1] who also provided a formula for the inverse transform. Radon further included formulas for the transform in three dimensions, in which the integral is taken over planes (integrating over lines is known as the X-ray transform).

 _It was later generalized to higher-dimensional Euclidean spaces, and more broadly in the context of integral geometry.

The complex analogue of the Radon transform is known as the Penrose transform._

The Radon transform is widely applicable to tomography, the creation of an image from the projection data associated with cross-sectional scans of an object."

[...]

"the inverse of the Radon transform can be used to reconstruct the original density from the projection data, and thus it forms the mathematical underpinning for _tomographic reconstruction_ , also known as _iterative reconstruction_."</comment>


Mozilla Releases Annual Report For 2011 - <AUTHOR> http://techcrunch.com/2012/11/15/mozilla-releases-annual-report-for-2011-revenue-up-33-to-163m-majority-from-google/ <comment><USER2> A lot of money from Google. Is this not a problem?</comment>


Signs You're a Crappy Programmer (and don't know it) - <AUTHOR> http://damienkatz.net/2006/05/signs_youre_a_c.html?

<comment><USER2> I love programming software and have been doing it for half of my life.

Whether I am or not by other people's standards, I always assume I'm a crappy programmer and never trust my own code until it stands the test of time.

For his list of items, I think it's really rare to find a developer who is as fanatically wanting to jump into those pitfalls. Most developers I know that fall victim to those issues recognize those drawbacks, but are too lazy or don't find it important enough to deal with at the time. I'm not so sure they're really as religiously bad as he phrases it.

</comment><comment><USER3> Here's one that got missed:

All your code gets nominated as a prime refactoring target.</comment>


Defining Churn Rate - <AUTHOR> http://www.shopify.com/technology/4018382-defining-churn-rate-no-really-this-actually-requires-an-entire-blog-post

<comment><USER2> The definition of churn rate was the subject of a shareholders' lawsuit against Netflix in 2004. The shareholders accused Netflix of reporting an artificially low churn rate using:

      Number of Customers churn / (Number of customers at beginning + number of customers gained).

Where the plaintiffs preferred:

      Number of Customers churn / (Number of customers at beginning + number of customers at end of period)/2.

Netflix succeeded in having the suit dismissed, since there is no official way to calculate churn.

<http://www.globenewswire.com/newsroom/news.html?d=62086>

[http://www.docstoc.com/docs/33875708/In-Re-Netflix-Inc- Secur...](http://www.docstoc.com/docs/33875708/In-Re-Netflix-Inc-Securities- Litigation-04-CV-2978)

<comment><USER3> Your comment really had me scratching my head because both of your formulas looked identical. <http://i.imgur.com/6YsQM.png>

Turns out this is because OS X has hidden scrollbars and I had no indication I had to scroll right on your calculations.

<comment><USER4> This has happened to me before in full web pages where there is no clear visual indication of the end of the page. This and makes me question the scrollbar decision from a usability perspective - there is no direct visual signal of progress.

</comment></comment></comment><comment><USER5> There isn't a good definition. At Dropbox, we try to answer the question: what percentage of signups 56 days ago were active 1-28 days ago? For larger time periods, just look at the sum of each day over the window (sum-of- retained/sum-of-signups. 28/56 day windows are useful to keep the same number of weekends.

This reports the most recent signups for which there is good data, but is lagging. You could look at another action that causes people to be retained that happens earlier in the funnel to run an actionable test in a reasonable period of time.

Looking at cohort analysis historically will get you a good understanding of the percentage of users that are active after N time periods.

</comment><comment><USER6> What if there is seasonality in your Churn (lets say in your example monthly, which is very reasonable) and you are growing?

If you calculate at the wrong time you will severely skew the numbers.

-

Its my opinion that if you have daily churn numbers and you want to be the most accurate, simple formula is no longer viable. You should model daily churn against daily sales and create a revenue model. (takes about 2 minutes in excel, less if you have the data already in a spreadsheet).

\- If you want a simple formula, you should use the first two formulas you described in the article and just see how the numbers "feel".

In my opinion, anything beyond that introduces unnecessary levels of complexity that may actually make your modeling less valuable.

\- In any event, the article is great and really got me to think about churn again. Well done, and I really liked your thoughts.

<comment><USER7> Thanks wtvanhest

I think we basically agree; you may just be taking issue with my very explicit representation of the formula. All that's really happening here is just a weighted average of daily churn rates. I really think you need to average over a period of time to deal with normal volatility.

While the number '30' is in the formulation is not intended to mean that this metric can only be measured for a month. Rather it's just there to normalize the metric to always be comparable to the monthly rate. It would be very reasonable to take this metric for a month and for every week in the month and see if any of the weeks are substantially higher or lower.

I would be cautious with using this, or anything based on daily churn, to be used in a formula for predictions. If you want to predict what customers will do over x days it is far better to measure what customers have done over x days. What you lose in currency you more than make up for in having taken a direct measurement. Though I would happily use this metric to play in a model with computed weights.

Thanks again, Steven</comment></comment>


Show HN: HideAway – An attempt at making a better VPN - <AUTHOR> https://www.firetrust.com/products/hideaway-secure-unlimited-vpn <comment><AUTHOR> We've been working on making a better VPN for a few years now to address things like speed and flexibility.

Many people are interested in VPN speed/performance, so we've made that a focus.

1\. Should be as fast or faster than your base internet speed. You shouldn't lose any speed.

2\. Uses the same encryption as Wireguard, AEAD - ChaCha20-Poly1305 encryption with 256-bit key size, 96-bit nonce size and 128-bit MAC size.

3\. Server side is so efficient we can fit thousands of people on a cheap $10 VPS gigabit server without any loss in performance. Really only limited by the bandwidth of the host. CPU rarely exceeds 10%.

4\. Instant connection to locations, no waiting to connect or disconnect. Plus your connection roams seamlessly between wifi, ethernet and mobile.

5\. Everything resides in memory on the server, and of course there's no logging.

Coming up soon we'll be introducing custom rules, so you'll be able to redirect apps, domains, ports, cidr/subnets to different locations simultaneously. So you setup your custom rules and you won't need to manually turn on/off your VPN again. Along with redirect, there's also block and ignore. Your custom rules are stored locally on your machine, so there's no logging of these either. For example, you could redirect your whole computer to the UK, except gmail.com stays at your location, youtube.com is in the USA, outlook.exe is in Australia, and so on.

At the moment it's Windows only, but it has been engineered with cross- platform in mind (just need to find time to interface with the Mac and Linux TCP/IP stack), plus Android version is not far off.

<comment><USER2> Any idea on ETA for Mac support?

<comment><AUTHOR> We're finishing up the Windows version first, so implementing a new gui now so custom rules can be used (rules are already done in the back end). Then we can do the Mac version. Sorry can't give an ETA, it's bound to be wrong.</comment></comment></comment>


A Beginner's Guide to Note-Taking (For Your Life) - <AUTHOR> https://www.ivan-ang.com/a-beginners-guide-to-note-taking-for-your-life/ <comment><USER2> nice post. another alternative I would add to roam is [https://dendron.so](https://dendron.so) \- its a local-first roam like open source markdown note taking app built on top of vscode (disclaimer: i'm the author)</comment>


The Middle Child Is Going Extinct - <AUTHOR> https://www.thecut.com/2018/07/the-middle-child-is-going-extinct.html <comment><USER2> Exceptionally poor attempt to lie with statistics. Three or more is not an avg of 4 or more, and comparing women in their 40s to all mothers isn't equivalent.

There may be something to this, but the math is so intentionally misleading as to murder the credibility of the author.

</comment><comment><USER3> Going extinct? Typical middle-child attention getting stunt.

</comment><comment><USER4> I'm an oldest child, but my mother was a middle child and growing up loved Jane the Middle Moffat by Eleanor Estes (and all the other Moffat books.) I still think it is a peculiarly good insight into the mind, and the value, of a child with older and younger siblings in a poor family.

[https://www.amazon.com/Middle-Moffat-Eleanor- Estes/dp/015202...](https://www.amazon.com/Middle-Moffat-Eleanor- Estes/dp/0152025294)

</comment><comment><USER5> Ha, funny they ask about August 12th. I'll be running a four team friendly tournament for my middle daughter's fast pitch softball team.

Three kids here. It's tough, sure. Not for everyone? You can say that too. Rewarding? The most rewarding thing I've yet to experience.

As others mentioned, I didn't really plan all these kids out. Life happens, I guess.

</comment><comment><USER6> It's interesting that the article doesn't have a comment to make about other familial arrangements brought about by shorter marriages and relationships.

For example, I'm older than my brothers, yet the oldest of them is not a middle child, because he's not a brother of my other brothers.

When families start spreading like this, a kid can be both a middle-child and a firstborn simultaneously - it becomes relative. And the attention that their position supposedly gives them becomes harder to measure.

<comment><USER7> Agreed, especially as normal as it is now.

I've had conversations with our daughter about friends and their families. Nuclear families are uncommon now. It's just what it is. And seeing enough unhealthy marriages; it's probably a lot better that way than the old adage to "stay together for the kids".

<comment><USER8> > Non-nuclear families are not "not normal" at all now.

Too much negations. Let me compile this for myself and others:

Nuclear families are not normal at all now.

</comment></comment></comment><comment><USER9> Technically, isn't it the youngest child going extinct and the middle child left to take on the role of the youngest?

<comment><USER10> Whenever a couple has any kids at all, there is _always_ a youngest child and an oldest child. Sometimes, they are the same child.

There is not always a "middle child" because that requires at least 2 other children to exist.

You're trying to say that the "third child" is going extinct, which matches what the article is saying in a different way.

<comment><USER7> > Whenever a couple has any kids at all, there is always a youngest child and > an oldest child. Sometimes, they are the same child.

Technically, that's an _only child_ and that has articles all its own...

</comment></comment></comment><comment><USER11> What a shame, back in the day people used to have odd numbers of children.

<comment><USER12> Amusingly, both my mom and her sister had 3 children because their parents had 2. They were annoyed because one of them was "daddy's child" and one was "mommy's child" and they figured that having 3 each would prevent that. Numerology matters.

They both did end up having 3 kids, and I can report that I think the problem they thought they were preventing didn't happen. Win!

<comment><USER13> Can you describe the dynamics that _did_ occur? Were the kids happier overall when there were 3 of them than 2? I know it's tough to reduce everything to that one factor but still curious.

<comment><USER14> > I know it's tough to reduce everything to that one factor

Yes, that's the whole problem with this discusion. It isn't scientific, lots of anecdata, and correlation does not imply causation.

</comment></comment></comment></comment><comment><USER15> As nice of a theory it is, birth order has not been shown to affect personality at all.

> "Contemporary empirical research shows that birth order does not influence > the Big Five personality traits."

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

The fact that such a big environmental factor doesn't effect personality at all, to me suggests that personality is mostly genetic. Anecdotally, It sure seems like kids have very distinct personalities from a very start.

Another anecdote (that personality is more nature rather than nurture), is the stories of identical twins adopted to different families. When reunited as adults, they seem to have the same personality. One such story:

> "It's not just our taste in music or books; it goes beyond that. In her, I > see the same basic personality. And yet, eventually we had to realize that > we're different people with different life histories."

[https://www.npr.org/2007/10/25/15629096/identical- strangers-...](https://www.npr.org/2007/10/25/15629096/identical-strangers- explore-nature-vs-nurture)

</comment><comment><USER16> You go raise three children. I can barely handle two.

<comment><USER17> The dynamic totally changes with three kids. I have three kids, and when one of them is not at home (doesn't matter which one) the atmosphere changes completely, hard to describe how. What I want to say: Having three is different from having two, but not necessarily harder. They have more things to handle between themselves. I could not bear to raise a single child. That must be really hard.

<comment><USER18> Me and my wife decided for a second child (he's 2 months old now). I'm curious what you feel is hard about raising a single child? before deciding for the second, we were close to staying with one. If anything we feared it'd be hard for our first son growing all alone. Is that what you meant? hard for the kid not for the parents?

<comment><USER17> Both for the kid and for the parents. For example, with single childs, you have to arrange play dates. If you have more than one, chances are, they play together. Another thing: with a single child, this one child has to fulfill all of the expectations of the parents. So it is quite a burden for the child. And another thing is, with more than one child you see that your education has a limited effect on the character of a child. Assuming that you treat your kids in a similar way, you can notice a big variety in character between them.

</comment></comment></comment></comment><comment><USER19> I knew the older and younger ones always had it in for us!

</comment><comment><USER20> Population shrinkage is not healthy for a society.

<comment><USER21> Breeding under the replacement rate does not imply population shrinkage. It's a better strategy for a rich nation state to have lower birth rates and poach the best and brightest from other countries. That increases the wealth of native-born citizens as well as improving the lives of those who immigrate whereas overbreeding disperses accumulated inherited wealth.

<comment><USER22> But I thought we need immigrants to do the low paid jobs we don't want to do, not the hard well paid ones? /s

<comment><USER23> it can indeed be both (no sarcasm intended - the menial jobs nobody else wants and the high-skill ones not enough people are capable of doing).

</comment></comment></comment></comment><comment><USER24> I see the number of children a couple has as a vote on how many people should exist on earth. If you have 0 or 1 child as a couple, you are voting that there should be fewer people. If you have 2 children, you're voting that there should be about the same number of people. If you have more than 2 children as a couple, you're voting that there should be more people on earth.

With that context, I can clearly see why nobody in a city would want to have more than 2 children.

<comment><USER25> No it is natural selection in action. Those that have children are of the future, those that don't are of the past.

There is a huge shortage of smart people on the planet to solve the many problems that exist. The best way we know to create more smart people is to encourage smart people to have more children. Unfortunately we seem especially good as a society at identifying smart people and discouraging them from having children.

<comment><USER26> Children per couple goes down as quality of life goes up. All developed countries see birthrates decrease. No one is actively discouraging smart people from reproducing -- they're just better off and don't need children as a safety net for retirement, and they can access good birth control.

The idea that smart people are only produced by other smart people is nonsense. Genes regress to the mean, so most smart people won't have mostly smart children. And intelligence is significantly affected by nurture, not just nature.

And beyond all that, smart people aren't the end-all, be-all of humanity. They make useful things, but are of course capable of great evil (or mental illness or any other issue that limits their contribution to society).

<comment><USER25> Yes nobody is activily discouraging smart people directly from having children (this is why it natural and not artificial selection), but it is still selection.

Where did I say smart people having children is the only way to create smart people or that intelligence is only affected by genes? Please read what I actually wrote, not what you think I wrote.

Smart people are the people that have the ability to solve the hard problems we face. We have a huge number of very hard problems in the world and not enough smart people to solve them all. We need more smart people.

<comment><USER26> You didn't say it was the only way. You said:

> _" The best way we know to create more smart people is to encourage smart > people to have more children"_

...which is also unsupported by current intelligence research and still relevant to my counterargument.

<comment><USER25> Actually we know that intelligence is mostly genetic (especially at the high end), but even if it isn't, the family environment provided by (most) intelligent parents is very conducive to raising intelligent children.

It doesn't matter the means (environment or genetic) as both will contribute to smart parents raising smart children (provided they have children).

<comment><USER26> Socioeconomic status is far, far more important than genes[1]. If you want more smart people, give people more money.

1\. [https://www.psychologytoday.com/us/blog/under-the- influence/...](https://www.psychologytoday.com/us/blog/under-the- influence/201204/intelligence-is-not-just-genetic)

<comment><USER25> That is not what the article says, nor what the science on this topic says either [0]. Read the section on Heritability and socioeconomic status.

0\. [https://en.wikipedia.org/wiki/Heritability_of_IQ](https://en.wikipedia.org/wiki/Heritability_of_IQ)</comment></comment></comment></comment></comment></comment></comment></comment>


Facebook's TransCoder AI converts code from one programming language to another - <AUTHOR> https://venturebeat.com/2020/06/08/facebooks-transcoder-ai-converts-code-from-one-programming-language-into-another/ <comment><USER2> This seems like a missed opportunity to have developed an AI model that works on AI models, i.e. converting Tensorflow models to PyTorch and vice versa. That would have been much more fun to see than converting Python to C++ and vice versa. It's impressive but recursively applying AI to AI code seems much more fun even if it's just a translation process.</comment>


Beginner's Health and Fitness Guide - <AUTHOR> http://www.liamrosen.com/fitness.html

<comment><USER2> I can swear by this - I've lost almost forty pounds since New Year's by cutting out the danishes, making my own lunches, and going to the gym regularly for weight lifting and cardio.

The only thing I'd add - working out is time-consuming, and getting started at a gym is both hard and intimidating. Gyms themselves are counting on you to stop going - that's how they make their money. If you're having trouble getting started, consider saving up your money and getting a personal trainer for a few months. The personal trainer will teach you how to use the equipment properly, get you more comfortable around the gym, and, most importantly, will be so godawful expensive you won't shrug it off and not bother to go to the sessions - the pain of wasting all that money will be too much.

Yes, I know this is silly - but I was getting chunkier and chunkier over the past couple of years and for me that was the only thing that worked. Personal willpower just wasn't getting it done.

<comment><USER3> First off, great job!

Working out really doesn't take that long. Most studies have shown that a typical non-steroid using weight training session only needs to last 45 minutes to an hour. After that time period, unless you consuming calories during the session the results you can get drop off dramatically from diminishing returns.

I agree that the biggest hurdle with people going to a gym is the intimidation factor. I'm in the gym 4 times/week and love seeing people who start and keep going. I want to tell them how awesome it is that they are doing it, but am never sure if that's the right thing to do some stranger lol.

If you can afford it the personal trainer is a great idea. The only problem is that many PTs plain out suck. I would try to do a session with one before committing to anything long term with a particular person. There are personality and knowledge factors that as a client you want to find out early.

Your story is also very common and is why a friend of mine is opening a gym that will cater to people who need a PT and are generally intimidated about the process. Obviously it will be a smaller niche gym, but I think it will work out pretty well.

<comment><USER4> "I want to tell them how awesome it is that they are doing it, but am never sure if that's the right thing to do some stranger lol."

General heuristic: If you are not sure, if it is right to approach a stranger, just do it. Really. Talk to them next time.

And don't end your sentences with "lol", please.

<comment><USER3> I go back and forth on things like lol. It's hard to convey in writing when something should be take lightly or as a joke. Without the standard facial cues of smiling it's easy to take something the wrong way.

And in general your heuristic is correct, but the gym is an odd place. I'm pretty social, but would prefer no one talk to me while working out. I'm usually so busy watching the clock and focusing on the task at hand that I don't want to seem rude to someone by having to eventually ignore them to finish my workout.

<comment><USER5> This is why we have these punctuation marks called "smilies". :-)

(I fear that all the image-substitution of smilies will create a generation of internet users that can't read the original ascii ones...)

</comment></comment></comment></comment></comment><comment><USER6> Looks pretty good.

Two points that I'd _not_ follow.

Diet: Eating grains. Gluten is pretty much evil for everyone, including non- Celiacs. Google for "paleo diet" or "gluten autoimmune" to get a sense of gluten's impact. Also check out the "Save my Life" HN thread for more info about gluten-free/paleo. <http://news.ycombinator.com/item?id=1399450>

Exercise: Cardio, long slow distance is pretty much useless. High intensity intervals, 200m, 400m repeats will have a much bigger impact. If you really love endurance, check out <http://crossfitendurance.com/> and google for "tabata intervals"

<comment><USER7> Those two points seem to me like fringe advice. I'm sure if I googled "gluten autoimmune" and "tabata intervals" I'd find a bunch of people agreeing with you, but no more than I'd find with any number of other fad diets or exercise regimes.

It'd take a helluva lot of evidence to persuade me that eating grains is bad, because... heck, grains are tasty, and the vast majority of humans who have lived over the last five thousand years have had grain-based diets with no obvious ill effects. Likewise, if you think long slow-distance cardio is pretty much useless, go watch long-distance runners for a while.

My advice to anyone who is unfit and wants to be fit is to ignore everybody who's trying to sell you some very specific idea of what you have to do, and just concentrate on doing the lowest-common-denominator stuff: eat less junk, do more exercise.

<comment><USER8> The research on Tabata intervals is actually pretty interesting: [http://en.wikipedia.org/wiki/High- intensity_interval_trainin...](http://en.wikipedia.org/wiki/High- intensity_interval_training)

If you Google for "tabata research", you'll find a number of studies -- including the original paper by Dr Tabata [<http://www.ncbi.nlm.nih.gov/pubmed/8897392>] -- showing that bursts of very high intensity exercise can have a greater effect on endurance than long, steady workouts.

On the one hand, I find it counterintuitive (how can sprinting on-and-off for 5 minutes help my endurance more than running for an hour??). On the other hand, it kind of makes sense, since your body improves most when you really challenge it, and sprints are generally more challenging than a steady pace.

<comment><USER9> For your last sentence, I think that you have never trained track and field. While 30-40 minutes of jogging is usually done by athletes, the core training is done by series of shorter distances that you have to compete with.

As an example, I have been training for 400m the last years. Being a short distance (although when you reach 300m you feel that is way too long) it is basically trained by repetitions of shorter distances (150/300). And by basically I mean that sometimes there will be longer distances (specially off- season) and tempo.

In general, people that train for 5000, 10000m don't run 1h to train their endurance. They will do, for example, 25x400m r:30", or shorter distances like 3000, 2000 or 1000.

There is no secret on that, you are using your body to run a higher pace that is used to, while running 1h will make your body be used to this slower pace and thus you will not improve your endurance.

If you ask me, I would say that endurance training is not worth it, and that training high intensity is better for your body.

</comment></comment></comment></comment><comment><USER10> some extra programs if you're looking for more templated options:

<http://www.rosstraining.com/nevergymless.html>

Ross Enamait's "Never Gymless" - this guy will turn you into a freak of nature ... without a gym. Also be sure to check out "Infinite Intensity" and his other programs as well.

[http://www.defrancostraining.com/articles/38-articles/65-wes...](http://www.defrancostraining.com/articles/38-articles/65-westside- for-skinny-bastards-part3.html)

West Side for Skinny Bastards 3 by Joe DeFranco - a four day split involving max effort, dynamic effort, and repetition days.

[http://www.aasgaardco.com/store/store.php?crn=199&rn=312...](http://www.aasgaardco.com/store/store.php?crn=199&rn=312&action=show_detail)

Starting Strength by Mark Rippetoe - one of the best books as far as learning the basics of barbell movements and how to apply them successfully. Also check out "Practical Programming" which will help you scale your workouts to beginner, intermediate, and advanced programs as you progress.

And finally, if you're looking for a way to get a quick and brutal (did i mention brutal??) cardio workout, I highly suggest high intensity interval training (HIIT) in the form of barbell complexes.

[http://www.tmuscle.com/free_online_article/sports_body_train...](http://www.tmuscle.com/free_online_article/sports_body_training_performance/screw_cardio_four_complexes_for_a_shredded_physique)

I highly suggest Cosgrove's Evil 8 complex, you'll be entirely gassed in about ten minutes. Complexes are GREAT for people looking to build mass and continue doing high intensity cardio without the catabolism (muscle breakdown) associated with slower, long duration cardio.

</comment><comment><USER11> Good read, although the comments about saturated fat may be questionable in light of the recent research (e.g. <http://news.ycombinator.com/item?id=1332954>).

</comment><comment><USER12> This guy has built an home fitness plan with inexpensive tools:

<http://fitness.scoobysworkshop.com/>

He has posted videos too.

Good for those who haven't got an (inexpensive) gym nearby (like me).

EDIT: His push-ups tutorial is highly recommended: <http://www.youtube.com/watch?v=S990kHLMVFg>

</comment><comment><USER13> I really hate it how many people when talking about health talk about losing weight. It somehow undermines credibility of other things theys say.

What if I don't need to lose weight? What if I actually need to eat more? Haven't you thought about it, mister?

</comment><comment><USER14> I agree with the author's recommendation to focus mainly on compound movements (squats, deadlifts, military presses, etc.) I stopped training arms directly and still packed on substantial muscle mass just by training back, chest and shoulders. I'd also point out that in my experience, training legs accounts for 50% of upper body growth due to the specific hormones released.

<comment><USER15> > I'd also point out that in my experience, training legs accounts for 50% of > upper body growth due to the specific hormones released.

I couldn't agree more with this statement. It always pains me to see guys at the gym who spend 2 days a week on chest and another 2 days on back with a day for arms and never train their legs.

It's our legs that often break down first when we're older. You've got to take care of them:)

<comment><USER3> I point and laugh at those guys :)

</comment></comment></comment><comment><USER16> This article gets huge "Hell yeas" from me just for linking to published medical papers when making medical claims.

I saw the jama link and almost clapped right then and there.

</comment><comment><USER17> Great article, agree with pretty much everything.

The one advantage of machines over free weights is that the machine will enforce your form. If you are able to maintain form with free weights, the effort exerted to do so is an added bonus, but if you aren't, it's not good. I started with machines, and every couple workouts replaced a machine exercise with a free weight exercise. This helped me get started, and let me concentrate on the form on one new exercise at a time.

<comment><USER3> The problem with machines and that most enforce 'bad' form. Every person has their own natural motion that a machine simply cannot match.

The best way to learn a free weight exercise is to simply start doing it without any weight. Start squatting and dead lifting with just your body weight (use a broom handle to simulate the bar). Once you get that down start adding weight. There is a very little that a machine will do to help you with exercises like that and in fact it could end up enforcing bad habits.

<comment><USER10> Another thing I'd like to add to this:

TAKE VIDEOS. If you're hesitant to bring a point and shoot to the gym, go later at night or before noon when the gym is relatively empty. Share your videos on any of the big lifting forums and ask for opinions. Sure, you can ask a trainer, but if you're lifting at any of the major chain gyms I wouldn't trust a lot of those guys to critique a squat as far as I can throw them.

If you're doing a lift with improper form, you might as well not do it at all. The point of maintaining proper form is to not only remain injury free, but to also point out any strength imbalances you might have (weak quads in a deadlift, weak lower lumbar in a squat, etc etc).

(example vid, i switched to sumo-stance for deadlifts and wanted to make sure i was doing it right before moving back up in weight -- <http://www.imperial.org/~jd/deads275.wmv> )

I can respect -anybody- that posts videos and asks for help on form. The amount of weight you're moving is trivial - the fact that you want to focus on your form and perform the lift correctly speaks volumes. I respect the guy squatting 95lbs correctly infinitely more than the guy squatting 405lbs to 25% depth any day of the week.

<comment><USER3> Great advice! The 2 angles you generally want for a video are the front or back and the direct side angle.

Luckily I haven't had to post and vids because I have a trainer friend who is very good at form and correction. He just adjusted a few things in my DLs and I'm closing in on 500lb DL again.

I've tried sumos off and on, but I don't they are right for my body type. I have long arms and legs and I just get so much more leverage with the traditional DL. I do sumo holds though as accessory work to keep my glutes firing properly.

And yea, the guy quarter squatting is generally a dumb ass. There are times to quarter squat, but for most people they should never need to.

</comment></comment></comment></comment><comment><USER18> _Eating healthy has to just become how you eat most of the time. Exercise has to become a habitual thing you do every day or two, like mowing the lawn or taking out the trash._

Yes! Yes! Yes! This is the key, "the secret," to fitness.

<comment><USER19> Absolutely. Becoming more fit is making a change to your lifestyle that you can sustain in the long term.

</comment></comment><comment><USER20> For those of us who have enjoyed running the past or would like to start up, I highly recommend getting Nike+ (<http://nikeplus.com>). It connects to your ipod, and via a sensor in your shoe gives you feedback about your run. You can join challenges and make friends on their site. Having graphical feedback of your run is pretty cool too. Being able to visualize your progress is very motivating.

<comment><USER21> If you have an iPhone or Android device with GPS, I'd suggest Runkeeper (<http://www.runkeeper.com>). The app and site is top-notch.

<comment><USER22> I would second that recommendation.

</comment></comment></comment><comment><USER23> This is a great article, makes me want to get off my bum and do some exercise :) One thing I'd like to know is, for women, yoga and pilates and all that seems to be quite fashionable these days, but they don't tend to be either cardio or weightlifting -- what sort of effect do they have on the body?

<comment><USER24> Things like yoga will stimulate the body and build strength to a degree, but that is a much less efficient way to get in shape, in my opinion.

One of the reasons compound lifts moving heavy weight are so important is the effect they have on your entire body. Doing heavy squats recruits nearly every muscle in your body. But it doesn't just stimulate those muscles, it also stimulates your central nervous system.

Doing something hard enough to get the attention of the CNS is important to making progress, since, for example, the CNS will respond by releasing more hormones such as growth hormone.

Doing full squats with your bodyweight on the barbell 15 times (3 sets of 5) is like screaming at your body to get in shape and it will respond. Doing yoga might be like gently asking.

This isn't to say yoga isn't beneficial, it's just not the most efficient way to get in shape.

<comment><USER25> Yoga is perfectly good for "getting into shape" and there are several varieties with emphasis on strength, especially static strength.

(Of course, "in shape" means different things to different people. I prefer endurance/cardio, many others think more in terms of strength/musculature.)

As a gross oversimplification of the body types attained, yoga == Bruce Lee, weights == Arnold Schwarzenegger.

<comment><USER26> That's an ironic comparison considering Bruce Lee was a serious weight-lifting fiend. (He just went for strength rather than bulk.) That said, I'm a big fan of yoga, more for the fitness than for appearances. It's hard to overstate the functional change yoga makes.

Edit: IIRC, Lee described running as the best exercise.

</comment></comment></comment></comment><comment><USER19> If you're interested in protein supplements in the UK I recommend MyProtein. I'm not affiliated with them, but I am a very happy customer.

<comment><USER19> I posted the above comment because the article contains the text:

"TrueProtein sells among the cheapest and also highest quality protein powders."

I thought it would be helpful for UK readers to have an alternative to the USA based TrueProtein.

I've been downmodded for the comment (at the time of writing) so if company endorsement is inappropriate here could someone please let me know?

</comment></comment><comment><USER27> How much does smoking pot affect your health and fitness? Is it in same category as bad food (i.e. you can smoke a joint a couple times a week and get away with it) or is it worse?

<comment><USER27> I'm being downvoted, but it's an honest question.

Weed's good friend alcohol gets a brief mention in the article, but it doesn't say how much the drug itself affects your fitness. It only says that many alcoholic drinks are bad for you because they have high calories from the sugar and alcohol.

For some people, especially college students like me, weed and alcohol are part of their lifestyle. Yes, they're bad for you, but my question is _how bad_?

</comment></comment><comment><USER28> Shin splints can also be caused by shoes with poor ankle support.</comment>


Lazy Loading Asyncronous Javascript - <AUTHOR> http://friendlybit.com/js/lazy-loading-asyncronous-javascript/ <comment><USER2> Another solution might be to set the sourcing of JavaScript in a timeout, e.g. setTimeout(_sourceJavascript, 300). I think this will bypass the blocking nature. This is only based on my intuition thought - it isn't tested.

\--

It's also important to note that window.onload will only fire when everything is loaded (including scripts and large images). To bypass this problem you should use something like jQuery.ready(document) or Dean Edwards onload hack ( <http://dean.edwards.name/weblog/2005/09/busted/> ).

<comment><USER3> Most scripts need access to the DOM, and waiting for the onload or domcontentloaded events ensure that the DOM has properly loaded when you run your script. Using setTimeout does not ensure that, so you can't really write a script tag then...</comment></comment>


What the affordable care act means to me - <AUTHOR> http://synecdochic.dreamwidth.org/616159.html <comment><AUTHOR> Interesting because the writer is the co-founder of Dreamwidth, and was only able to leave her employment and start the new company because of decent healthcare legislation.</comment>


Will Microsoft Skype  disrupt tech hiring? - <AUTHOR> https://medium.com/@_Guruprakash/will-microsoft-skype-disrupt-tech-hiring-1edc8f0b2f0c <comment><USER2> I think live coding is an ineffective way to determine peoples capabilities.

I need to program in quiet, without an audience, _without_ time pressure. Whilst development projects have an overall time factor, no programmer should be programming to a minute or even hour scale deadline. It's not an effective measure and therefore should not be used at all because it tells you nothing realistic.

<comment><USER3> Yeah, same here. And it's not just about programming too. Doing something 'live' with an audience requires a very different mindset than doing it at your own pace. I even struggle to play a video game as well as normal when it feels there's a crowd watching.

That said, I do worry that we'll see a rise in clueless managers and HR departments that don't understand this (and think it's some magical way to determine someone's level of skill). That could lead to even more situations where being extraverted is seemingly more valued than actually being good at the job.</comment></comment>


Need A Job? Make $1.20/hour Tagging Photos (TagCow uses Mechanical Turk)) - <AUTHOR> http://www.techcrunch.com/2008/04/02/need-a-job-make-120hour-tagging-photos/ <comment><USER2> Is TagCow paying for this out of its own pocket? I don't see any "premium" service or payment requirements...</comment>