The Next 1,000 Start-Ups - <AUTHOR> https://www.braintreepayments.com/blog/next_thousand_startups <comment><USER2> Good move by BrainTree.

As much as I love Stripe and their innovative moves, the bulk of my business's transactions have been handled by BrainTree over the last 4 years. That includes both SaaS subscription billing and third-party payment aggregation (we do niche ecommerce, take a transaction fee, and ACH to customers). Our transaction fee is below the (now seemingly) standard 2.9% which adds up when you get to hundreds of thousands of dollars or more in processing. BrainTree's support is great ... I'm talking Rackspace-level great.

Some of you talk like BrainTree is an old-school behemoth which is being disrupted by Stripe, which is silly. News flash: BrainTree is not PayPal. Obviously they are all competitors, but I see nothing to indicate that BrainTree can't keep pace with Stripe moving forward.

I do use Stripe for things–and I do love it. But we wouldn't be where we are today w/o BrainTree.

<comment><USER3> Agreeing with everything here, and adding the fact that Braintree has incredible support. There have been several occasions where I couldn't figure out a bug on my side, or there was a gap in our database records while testing a new feature, and I was able to get on the phone with a customer service rep and get it sorted out in minutes.

I've never had such a pleasant customer service experience before, doubly surprising because it was with a financial service.

Braintree is pretty awesome.

</comment></comment><comment><USER4> A cute marketing trick. No you're not doing this just because you want to "help new startups". That's a nice way of rationalizing it, but really

1) Braintree is suffering from the competition, especially on HN, Stripe is loved like no other

2) They're not giving away 2 million dollars. With so many startups failing to ever generate significant revenue, I wouldn't be suprised if less than 10% of companies that are the first 1000 to register actually wind up generating $50k in revenue through their service. I'm sure Braintree have their own internal calculations about how much this will cost them and that number is certainly no where near 2 million dollars.

3) The primary purpose of this is to bind new businesses to Braintree. The scenario of "getting their free processing here and then going somewhere else before they pay us a nickel." is cute, but misleading. At that point in the company's development switching the entire payments system is much more expensive and would not make any economic sense.

Props to Braintree for coming up with this, I think in the end it's beneficial to the startup community, though I dislike the "second coming of jesus christ"-vibe of the announcement. They're doing this for business reasons, not because they woke up yesterday and felt a little charitable.

<comment><USER5> I think you are getting downvoted because your comment embodies the easy snark that is REALLY hurting this community. IMHO, seeing that your comment is currently at the top tells me we still have room for improvement.

I don't think anyone is deluded into thinking this is a charitable gesture, certainly not on hackernews, so I am confused why you spent so much time to (in an agitated way) make it seem like Braintree is pulling one over us.

<comment><USER6> I don't understand why people get offended when someone tries to find a motive behind something

      "So, what's the catch - is this just a marketing promotion." There's no catch, no strings attached, no BS -- we just want to do our part to give back to the community that made us successful and this is our way of paying it forward.

Clearly Braintree wants us to think they are doing it to do 'their part'. Pointing out that this might not be true shouldn't offend you. The parent is not challenging your intellect. He is just making an observation. I got a few negative comments on something similar I wrote about github [http://minhajuddin.com/2012/09/29/github-is-not-really- free-...](http://minhajuddin.com/2012/09/29/github-is-not-really-free-for- your-public-open-source-projects) .

Am I missing something here?

<comment><USER7> > Pointing out that this might not be true shouldn't offend you.

Speaking for myself, I'm offended by such comments not because they aren't true but because yes, they do offend my intellect and waste my time. We all know that Braintree and Github are not charities, let's talk about something interesting instead.

</comment></comment></comment></comment><comment><USER8> There are multiple aspects to payment processing with basic payment processing and integration being the minimum -- Stripe currently has the most beautiful story here.

Things get more complex on the back end of the payment being processed at scale, namely fraud detection and risk mitigation. This is where some of those behemoths in the industry actually shine more.

Stripe passes the risk directly through, you are on your own.

For a lot of folks here working on startups with their first few-hundred customers, that isn't the problem -- the problem is accepting payments and getting back to work. I don't see anyone beating Stripe in that game.

For the folks that have huge customer bases, mitigating risk and dealing with fraud is a much more frequent/costly problem and having a processor help out there is why companies like PayPal (and BrainTree?) are still in people's vocabulary even though a good majority of their experience on the front-end suck.

This is one of those problems that doesn't matter to you at all, until it does... then it is a huge nightmare and you scramble around looking for a solution and suddenly realize why "everyone doesn't just use Stripe" -- or some equally hot new processing startup.

<comment><USER2> I'm not sure I agree with you. I've had to deal with plenty of fraud issues.

How is Stripe passing the risk on any more than other processors? [1] The end- result of fraud (at least, the kind I'm familiar with) are chargebacks. Those are going to fall back to you regardless of who your payment processor is.

We've had major fraud issues on our system which is powered by BrainTree. When you hit a certain chargeback rate, you basically get a call from the underwriting processor/merchant who says "Get your crap together or get lost".

PayPal is a slightly different animal IMO.

<https://stripe.com/help/disputes>

<comment><USER9> My guess is that it depends on your business model.

(1) The risk to a TPPA model would be a fraudulent payment merchant signing up with your service buying from themselves with stolen cards. Charge-backs would occur here once the card owner discovered the card was stolen.

(2) The direct sale model risk would be selling and delivering a good or service and then the card holder (stolen or otherwise) charges-back to get the good/service for free.

In case (1) fraud detection would help detect the stolen card and mitigate the risk. In case (2), legitimate charge-backs from non-stolen cards are probably sometimes the bigger risk. I most likely didn't hit all the cases here but it certainly seems to be the case that PayPal or the like would not always help your business model with fraud prevention, supporting what callmeed said here.

</comment></comment></comment><comment><USER10> Interesting move. Too bad it's US only for now.

We're currently using FastSpring but both the recent opening of Braintree towards Europe and the price getting a clear 2.9% + $0.3 are making it pretty interesting.

Make a similar promotion for Europe and I'll probably switch.

<comment><USER11> We would love to do this for startups around the world. It's tricky to do with international banking relationships, but we'll continue to work with them to bring more opportunities like this outside of the US.

</comment></comment><comment><USER12> This is classic competition at work. Along comes Stripe that forces companies that are not asleep, like Braintree, to compete on price or innovation or some other axes.

<comment><USER13> When I was doing research on this for my startup a few months ago, we found that Braintree easily beat Stripe on price. This is just icing on the cake.

Braintree's not as glamorous (I think), but if you're doing a large number of transactions, Stripe's 2.9% + 30¢/transaction is quite high.

<comment><USER14> Your analysis is true although now Braintree's pricing is that of Stripe's - at least for startups who can't or don't want to spend cycles getting a stand alone merchant account. So it's good to make that distinction. I suspect the value with BT is that once you get real traction you can opt out of the more expensive rate into something more competitive - probably as soon as when you're doing a few thousand dollars per month.

</comment></comment></comment><comment><USER15> To provide some perspective, I did a calculation using their pricing information and assuming the average transaction size of $10 - the waived fee amounts to $2950.

edit - changed language to make it more meaningful

</comment><comment><USER16> Please fix headline to:

"Braintree Waives All Fees On First $50k in Transactions For Next 1,000 _US- Based_ Startups"

Might be a good idea to do this always, just a little thing to acknowledge the other 95% of the world..

<comment><USER14> Agree. It should be at the top not at the bottom of the post. Cruel tease to many who'll see this.

<comment><USER17> Boo -- someone changed it to the much less informative "The Next 1,000 Start- Ups" :(

Mods, please prioritize informative versions of titles!

<comment><USER18> Yeah, I clicked on this expecting a piece about the medium-term future of startups (the next 1,000 startups, say). A title indicating it was a promotion targeted _at_ startups would've been more informative...

</comment></comment></comment></comment><comment><USER19> I wonder if Braintree has been suffering since Stripe launched and this is an effort to get things moving again.

<comment><USER20> Was thinking the exact same thing. Another evidence of how (quality) competition benefits the customers… :)

</comment></comment><comment><USER21> Amidst all the weird negativity and to-and-fro, just wanted to say "DEATH TO PAYPAL API INTEGRATIONS!"

Go Braintree. Go Stripe. Go Recurly. Go CheddarGettar. Go Spreedly. Go whomever has the guts to tackle this beast!

Apologies to my friends at PayPal in case they read this....

<comment><USER22> This needs to be voted up to the top :)

</comment></comment><comment><USER23> Awesome! Payment processing is probably one of our biggest headaches, and this just gave us enough of a reason to try you guys out. Excited to try it out.

</comment><comment><USER24> What about those startups that already have an account but not generating revenues since they just launched a week ago?

<comment><USER25> As with most promotions aimed at user acquisition, you're unfortunately out of luck.

<comment><USER11> @sethbannon- This is not most promotions. Our goal is to help startups get off the ground.

@davidedicillo- We're happy to help recent signups who qualify, shoot an e-mail over to firstname.lastname@example.com and we'll set things right.

-Kristi from Braintree

</comment></comment></comment><comment><USER26> yes yes yes!

"Note: we're only able to offer this to start-ups with a presence in the US today. We recently launched in Europe and Canada and hope to be able to do something similar for international start-ups soon."

Oh... maybe later

</comment><comment><USER27> Excitedly rushed to sign up as we're interested in offering alternative payment solutions - disappointed as we're in the UK we can't and this wasn't immediately obvious!

Either way looks like a very cool offer!

<comment><USER28> any company naming themselves after a town in the UK ought to be available here...

<comment><USER29> Braintree's service is available in the UK, we just can't make the free processing offer outside of the US. Check out <https://www.braintreepayments.com/tour/international> for more info.

Also, our company name comes from the town of Braintree, Massachusetts, which is the home of the American revolutionary John Adams. I hope you won't hold that against us.

<comment><USER28> Ah I guess Braintree MA is named after the original!Will have a look, thanks.

</comment></comment></comment></comment><comment><USER30> The promotion is only available to "eligible merchants", but it is not clear what qualifies one as eligible.

Anyone from Braintree willing to clarify?

<comment><USER29> Michael from Braintree, here.

The idea behind this offer is to help launch more startups. We aren't policing this with specific limits, but we're asking that you only use this if you are truly a pre-revenue start-up or just started to collect fees for your product. If you've already got your start, then congratulations - we would love to work with you and help you grow. And you'll probably find that our standard pricing works well for you.

<comment><USER31> I'm happy that you changed your pricing to 2.9% + 30¢ - it did actually feel too expensive before. Thank you for supporting The Rest Of The World too! If I needed a payment gateway right now, your service would be a total _no- brainer_.

</comment></comment></comment><comment><USER32> So 1000 startups, meaning 100 real new startups (I doubt startups that are already into payments using other platforms would switch), of which 10 or less startups could really do 50k in transactions, meaning 10x50000x0.027 = $13,500 (tops and not $1M) in loss for Braintree... But I am sure they are getting way too much marketing out for this.

<comment><USER33> Not to mention you need an account with them in the first place and Braintree is well known for having a ludicrously strict risk team.

So yes, this is just a marketing gimmick.

<comment><USER11> Kristi from Braintree here. Admittedly, our legacy bank relationships left us as the middle man to their risk departments. This may be what you are referring to when you mention the "ludicrously strict risk team." This is no longer the case. Starting with the launch of our instant product, we brought risk in house. We are able to use our years of experience working with startups to develop risk processes that help us build relationships, not get in your way.

</comment></comment></comment><comment><USER34> Tell you the company that will get my business out of stripe, braintree and the others. The one that works out how to let us open an account without an SSN. Currently we are with SAASY for that reason, they charge 5.9%.

<comment><USER29> @corkill - I work on the signup and application process for Braintree, and I would be curious to know why SSN is a deal-killer for you. Do you not have a SSN, or is it just something you would rather not share? Feel free to email me at email@example.com if you would like.

</comment></comment><comment><USER35> Is this literally the next 1000 braintree signups or is that a marketing term?

<comment><USER36> Hey, it's Caitlin from Braintree. Yes, this is literally the next 1,000 merchants who signup through this page: <https://www.braintreepayments.com/next_thousand_startups>

<comment><USER37> The "instant signup" page says I have to wait one day for underwriters to assess the app, is that normal?

<comment><USER11> Most applicants will be approved instantly. There are some circumstances, such as the specifics of your business model, that may require a brief manual review. At most this will take 1 business day, but many reviews will be much quicker.

The good thing about doing this upfront is that you don't have to worry about running into any issues (like unexpected shutdowns) as your processing ramps up.

</comment></comment></comment></comment><comment><USER38> I have 900 different startups all with a variation of the name GiveMe50000FreeAmexPoints.com

I wonder if my startups are eligible. :)

</comment><comment><USER39> Looks good for starting out. Reminds me, has anyone heard back from startuppack.org?

</comment><comment><USER9> This promotion doesn't apply to third-party payment aggregation businesses.

</comment><comment><USER40> It looks like they can't handle the traffic. Not a good sign for them.

<comment><USER11> Braintree here. Can you elaborate? We're not seeing anything slow down on our end.

</comment></comment><comment><USER41> Couldn't agree more.</comment>


Startup Quote: Ron Conway, co-founder, SV Angel - <AUTHOR> http://startupquote.com/post/2151741995

<comment><AUTHOR> As a founder you have to build a team some day, so why not start the day you found the company?

\- Ron Conway (@RonConway)

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


Editorially - Write, collaborate on, and talk about a text. - <AUTHOR> http://editorially.com

<comment><USER2> Can anyone with beta access comment about features or share screenshots? There's not much to see otherwise.

</comment><comment><USER3> Looks interesting, but this is just a landing page.</comment>


Working from Home – Lessons Learned over 20 Years and Shopping List - <AUTHOR> http://blog.dustinkirkland.com/2020/03/working-from-home.html <comment><USER2> Blog post author here... I'm happy to discuss anything in that post here (rather than Blogger comments, which are pretty unmanageable). Cheers! Dustin</comment>


Hi can anyone suggest me some interesting ideas(online) with business potential - <AUTHOR> <comment><USER2> Hi, Fidel, drop me an email email@example.com I can't guarantee anything, but I also think it's important to work on something as a team.</comment>


Beware The Broken-Hearted Mechanic - <AUTHOR> http://gilesbowkett.blogspot.com/2009/05/beware-broken-hearted-mechanic.html <comment><USER2> I can just imagine a customer saying "I'm not paying for 'periodic maintenance' when I can't tell if there's anything wrong", but I'll definitely try it the next time I'm asked to justify responsible system development.</comment>


Walt Mossberg's final Wall Street Journal column  - <AUTHOR> http://www.theverge.com/2013/12/17/5222248/walt-mossberg-final-column-for-wall-street-journal-all-things-d

<comment><USER2> No comments? Is Mossberg too old-school for the people here?

No discussion of Mossberg would be complete without a reference to Mosspuppet. [http://www.mosspuppet.tv](http://www.mosspuppet.tv) Don't pay attention to the commentary, just watch the videos. They're hilarious. Sadly the guy hasn't done any videos in quite a while.

"I'm Walt Mossberg. Shut up."</comment>


HIP – Convert CUDA to Portable C++ - <AUTHOR> https://github.com/ROCm-Developer-Tools/HIP <comment><USER2> When I write CUDA kernels I am very specific in optimizing for nVidia GPU features:

         * I have 1024 threads per block
         * I have 48KB of shared memory per block
         * I have 32 threads per warp and need make sure that
           global to local memory reads are coalesced.
         * Think SIMD and avoid branching as much as possible

My kernels usually follow a specific pattern:

         (1) Read global memory into local memory: making sure that
             if thread i reads memory[n], then thread i+1
             reads memory[n+1].
         (2) __syncthreads().
         (3) Do computation in in most thread balanced way possible.

This very specific pattern doesn't really work elsewhere. In fact, optimizing in this fashion and then porting to C++ and elsewhere loses the specific optimization. Programming in more general way loses all the things that makes the program fast. Anyway, I definitely going to look this over more.

<comment><USER3> AMD's "HCC" is C++ with templates added onto it. Unlike CUDA, HCC implements all relevant features in C++ Templates alone.

If you simply do 64-thread per "warp" (AMD's groups are per-64) and 32KB LDS aka Shared memory per block, you would be able to write portable high- performance code between AMD GPUs and NVidia GPUs.

AMD seems like its a bit behind with regards to GPGPU adoption. But AMD's hardware seems to be a good bit cheaper. You can get HBM2 models at ~$2000 from AMD (Firepro WX9100, which is Vega architecture)

Although... as they say... hardware is cheap. I'm sure most datacenters will prefer the $8000 NVidia V100 instead, because there are more people using that hardware. In particular, its easier to get started with a V100 due to AWS and other cloud-compute offerings.

</comment></comment><comment><USER4> I wonder if this performs well enough to port cryptocurrency miner software. I hope to find out with

[https://github.com/mimblewimble/grin/issues/806](https://github.com/mimblewimble/grin/issues/806)

</comment><comment><USER5> Could anyone who's used HIP comment on how it compares to programming in raw CUDA?

I considered using it for a project recently, but ultimately decided against it because I didn't need to be able to run on AMD systems.

<comment><USER2> Wait ... if you write your program in HIP you get both CUDA and OpenCL (which includes AMD) for free right?

<comment><USER6> There is no OpenCL in the story there. AMD created HIP as a direct copy of CUDA. It then gets compiled to work on AMD hardware, or can be translated to CUDA.

AMD _also_ supports OpenCL (which I prefer to both CUDA and HIP), but it's not connected to HIP.

<comment><USER7> Last time I checked, HIP didn't support reading from textures.

That's something that's not only useful for pure graphics.

So it is (or was?) not a straight substitute for CUDA.

</comment></comment></comment></comment><comment><USER8> The fact that HIP exists is why we choose cuda for our program 8 years ago. Opencl and cuda were the choices. I thought about how I would design such a gpu language aND then looked at cuda and opencl. What I dreamt up matched cuda exactly. I forsake one day that it would no longer matter what you wrote in cuda because it could be easily translated to any type of gpu hardware. In the past few years, Portland group made cuda do cpu compiler and now HIP.

<comment><USER9> *foresee:)

<comment><USER10> Mmmhhh I would say "foresaw" ;-)

<comment><USER8> Sent from my Android.

</comment></comment></comment></comment><comment><USER11> So, the logical next step would be what? Apply that tool to Tensorflow to make it run on AMD GPUs?

<comment><USER12> HIP is only useful to convert CUDA source code.

Tensorflow uses the cuDNN library, which is closed source. There is nothing for HIP to convert.

<comment><USER13> AMD is working on a cudnn comptability layer iirc (MiOpen) and is ROCm group has created a cuda transpiler (to intermediary HIP then to amd binary via hcc)

[https://instinct.radeon.com/en/6-deep-learning-projects- amd-...](https://instinct.radeon.com/en/6-deep-learning-projects-amd-radeon- instinct/)

<comment><USER10> Wait, I thought that AMD's cuDNN replacement was hipDNN, now I'm confused [https://github.com/ROCmSoftwarePlatform/hipDNN](https://github.com/ROCmSoftwarePlatform/hipDNN)

Edit: OK I was reading the docs, I think I got it: hipDNN is a wrapper that (once finished) will search and replace calls (from cuDNN to hipDNN), then hipDNN itself, in turn, will call MIOpen, not sure if that's right, I would appreciate if someone who knows more could confirm

<comment><USER14> AMD is always working on random half-assed attempts to get to parity with NVidia for neural network training.

If they'd chosen one approach 5 years ago and put decent resources behind it they might be competitive by now.

</comment></comment></comment></comment></comment><comment><USER15> Is there a legal question here as CUDA is proprietary API?

<comment><USER16> That is an interesting question, but I don't think so, because that repo shouldn't contain anything related to the CUDA binaries.

(Do NOT take my word for it, I have no idea about what I am talking about)

<comment><USER15> Obviously im thinking of this type of legal issue. [https://www.theregister.co.uk/2017/06/09/intel_sends_arm_a_s...](https://www.theregister.co.uk/2017/06/09/intel_sends_arm_a_shot_across_bow/) . Emulation is simply an implementation of API.

<comment><USER17> Also Oracle vs Google in their legal battle about the use of Java APIs in Android. [https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google...](https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google,_Inc%2E)

Google won out over Oracle in the end but it took a long time — from 2012 until 2016; four years of court cases — with some courts finding that API structures were copyrightable and others found that they were not, or that reimplementation was fair use. I guess we now have a precedent thanks to this but it could still be an issue? IANAL so I don't know.

<comment><USER18> Oracle may not have been able to use SQL anymore if the ruling had gone in their favor.

<comment><USER16> Could you elaborate???

<comment><USER19> Somebody speculated that the lawsuit was used by Oracle to establish firm boundaries in what can be considered a copyright infringement, with the intent to implement Amazon/GCE APIs for drop-in compatibility for their cloud offering. So they tried all kinds of ridiculous stuff to see what works/what doesn't in order to properly cover their backs while "stealing" other APIs.

<comment><USER20> Given that Google helped sink Sun by ripping them off, and Sun wasn't in the position to pay for lawyers, to apply the same medicine that they did to Microsoft....

James Gosling interview, at 57:42

[https://www.youtube.com/watch?v=ZYw3X4RZv6Y](https://www.youtube.com/watch?v=ZYw3X4RZv6Y)

"unwilling to help us pays the bills", so nice for the Do No Evil company.

Oracle does pay for their ANSI/ISO SQL certifications.</comment></comment></comment></comment></comment></comment></comment></comment>


Don't require a user to be interested twice: lessons on reducing signup friction - <AUTHOR> https://bbirnbaum.com/two-lessons-on-reducing-sign-up-friction/ <comment><USER2> It's a good lesson but let's not forget that completing the signup is not the goal in itself. If you look at post-signup user activity you will find _many_ users stick around for a few minutes and then leave, never to return again.

If someone can't be bothered to click a verification email, then removing that step is not going to magically turn them into an active user. More likely they will be one of the many people who leave after a few minutes.

I do a signup/onboarding optimization for startups, and here's what I found from a recent project:

1) The verification email was NOT a significant bottleneck to signups. That is, most people clicked the link.

2) Removing the verification step did NOT have a meaningful impact on conversion rates.

If you don't have a problem with user quality then sure, avoid the verification step. But if you have a good reason for the verification step then don't sweat the drop-off rates.

And more importantly: Treat signups as a leading indicator of success, not the ultimate goal.

Edit: On second reading I see the author is talking about a verification step that requires an admin approval, which could take hours. Yeah, don't do that.

<comment><USER3> Also removing that step means that I get 'spam' that contains scary amounts of PID in it.

I'm looking at you, Mint, who sent me someone else's financial data for months and months, and did not have an unsubscribe button (outside of user account preferences).

If a gamer uses my email address to sign up for a service, I'm gonna log into their account and change settings. Or once, in a mood, just delete their account (many services use email address as an identifier, so you can't use that service if someone used your preferred email address). I figure it's like someone accidentally giving out your number in a bar to get away from a creep. You just happened to lose the random digit lottery.

I'm never going to log into someone's financial system to do that. You're crossed a line from petty vigilantism (under duress) into "this is starting to resemble a felony" territory. It took ages to ask the right question of Mint support to get them to do something about it. And really, fuck anyone who puts people in this position in the first place.

If you are sending communications to a user repeatedly, you believe you have a relationship with them whether they want it or not. If you are collecting sensitive data on them, and then telegraphing it in those communications, then _verify their goddamn contact information first_.

Or, stop trying to have those conversations over unauthenticated channels.

[edit to add: and then there was the lonely guy who signed up for eight+ dating sites while I was in a rough patch with my partner and I had to scramble to unsubscribe lest she think I was planning my escape. Seriously dude, not cool]

<comment><USER4> I feel you. I have {firstname.lastname@example.com and I get so much email intended for other people. Services that don't verify email and require you to login to unsubscribe are the _worst_

<comment><USER5> Slight tangent: A lot of people might not know that periods in the first half of a gmail address actually get ignored when relaying. They're only there visually. Some services don't check for this and you can register multiple accounts with email@example.com, firstname.lastname@example.com, firstname.lastname@example.com which all get forwarded to email@example.com.

</comment></comment></comment></comment><comment><USER6> The best and most simple onboarding process I've ever experienced was with expensify. I don't know if it's still like this, but you just enter your email address and you're in... your account is running and you're logged in. Everything else can be figured out later.

Bots? Idle new accounts are probably deleted after a number of days. Password? A reset/creation link can be sent to your email the next time you try to login. Payment? That's only important if you're going to use the software -- it can be handled when appropriate.

Unless your service has some major expense or limited resource associated with account setup (ex. assigning the user a new phone number), I would love to see more signups like this. The lack of friction made me feel so happy as a customer and I instantly had a positive impression of the service because it already felt like it was adding value by making my life easier. I wouldn't be surprised if this also has a positive impact on their conversion rate.

<comment><USER7> That's fine as long as you send a welcome email immediately that says "If you didn't create this account, use this link and you'll never get another email at this address".

I've seen services forget that, and then it's possible to sign up with someone else's email address, use the account, and have someone else get spammed or harassed. That needs to be part of your threat model. "What if a bot signs up" is about protecting your service and people using it. "What happens if someone signs up with someone else's information" is about protecting _other people_ , who may have nothing to do with the service.

<comment><USER8> > "If you didn't create this account, use this link and you'll never get > another email at this address"

If I get an _unsolicited_ email for a service I don't recognise, that has a link in it and a message asking me to click on it, should I click on it?

Commmon advice is don't click on links in mails you aren't expecting. It just confirms your address is real for spam harvesting.

<comment><USER9> I don't know who gives that advice, but it seems poorly thought out. Email providers already tell people sending email when an address is real or not. You clicking the link would tell them you read your email.

I'm also not sure what you're afraid of. If your account has been in existence for long enough, you already get a lot of spam. It just gets blocked or filtered. The vast majority of your emails that actually get to your inbox are from people trying to do the right thing, not people trying to screw you over.

<comment><USER10> > Email providers already tell people sending email when an address is real or > not.

I don't think email works the way you seem to think it works.

<comment><USER9> Email deliverability was part of my job for around 8 years. Providers will absolutely send you a bounce message (via the return path email) if an inbox does not exist. Or even if it is full.

The messaging is not standard so you have to do all sorts of special case parsing because each provider can give a different message. And ignoring these messages will hurt your ability to deliver email.

So if your plan is to hide your address from people, again, I don't see the point.

<comment><USER10> I believe there's value to marketers to know "this email address somewhat reliably hits a human's eyeballs" as evidenced by a click-to-unsubscribe or click-to-refute action as a stronger signal than "well, we didn't get a bounce".

"Email providers already tell people sending email when an address is real or not." suggests a level of reliability of signal that simply doesn't exist. I have an infinite number of email addresses that you could send to, which would not give you a bounce, and none of which will reliably land in front of a human's eyeballs.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> Know your target audience too. I'm not sure if I'm it, but reCAPTCHA gives me enough friction that I often abandon pages with it. Simply using Firefox's antifingerprinting feature plus some ad/tracker blocking is enough for it to be miserable every time.

<comment><USER12> Nobody here is talking about the elephant in the room where reCAPTCHA (and hCAPTCHA has the same problem) is concerned:

The other day when Google was having issues (the same day that a bunch of Android apps were crashing due to a bad map data push), I was unable to log into my bank, unable to pay my electric bill, and a half dozen other things I _needed_ to do that day.

Because Google's servers were down, core service providers were unable to do anything either because they block access to their site without recaptcha approving the entry.

To me, as a technologist, as a builder of software, this is absolutely and entirely unacceptable. Captcha needs to be something you can self host.

I don't understand this habit of handing Google a knife and then telling them where to stab you.

<comment><USER13> I'm going to guess people aren't typically talking about it for a few reasons:

\- We started out with self generated and self hosted captcha. It was too easy to beat. Complexity of the image generation turned up until eventually it was easier to just outsource it to someone else. Going to throw out a guess here that reCAPTCHA is far from simple, and likely exceeds what most teams would want to run internally.

\- Google has an uptime that's significantly higher than most companies. I'm not defending any of Google's habits or business practices, but I personally wouldn't bet that most companies can run software more reliably than Google.

\- As someone else mentioned, fail open is an option in situations like these (depending on the threats you're trying to protect against). For something with a high probability of failure, this could make sense, but I would have a hard time imagining a team allocating time to deal with the case "when Google is down" unless it's truly life or death software (think: surgical robots, autopilots, etc)

<comment><USER14> Why was self-generated and self-hosted captcha easy to beat?

I found that generating math questions in a captcha style (curved / with other noise drawing over) and requiring that questions to be answered in a box is unbeatable. The bad actor would require very good OCR and after that also good math parser to answer. Easy for human, very hard for automation. And the script was like 50 lines long that did that.

<comment><USER13> "easy for human" is very subjective. Users very regularly have a hard time with all forms of image captcha for a whole bunch of different reasons: visual acuity, color deficiency, learning disability, unclear instructions, visually similar characters, etc. If you allow users to refresh the image until they see an easy one they might be able to overcome it themselves but some percentage of those users will get frustrated and leave. Not to mention allowing regeneration of images also makes it easier for bots to cycle until they find one they're confident in. Surely if there were a dead simple for humans, difficult to beat for bots, 50 line script option for CAPTCHA generation that could be self hosted it would be in wide use.

reCAPTCHA changed to its current model to try to significantly reduce friction in the "hopefully normal" case (down to just a check box if all goes well) because every ounce of friction you add to critical inflection points in your product translates to meaningful lost opportunity.

Even if this wasn't a problem, and it were trivial to create something that's easy for humans and hard for computers, it's just not worth most companies' time. Would they rather spend a few days properly implementing and testing a captcha solution, then whatever unknown time on future bug fixes and support, or setup reCAPTCHA in 30 minutes and move on to things that produce value for their customers?

<comment><USER14> I see that as an absolute win. If you're having problems understanding simple math questions then I won't want you as my user in the first place. Morons out.

As for visual impaired ones, I agree this one is harder to crack. Usually you do it by audio, which in itself is more then 50 lines of code, but here is my personal approach. Absolutely none is stopping you to have, for visual impaired ones, a separate step like the one described in OP, where you have mail activated. You see visual impaired users have infinitely more patience then normal "visual" ones. They are used for web to not be friendly, so they won't mind going through extra hoops if they want your service. So a checkbox saying "I am visual impaired and I want registration by e-mail" or something equivalent and you're good to go.

</comment></comment></comment></comment></comment></comment><comment><USER15> Sam at UserOnboard has teardowns of a bunch of onboarding flows. It's the single best reference I can suggest around optimizing the process:

[https://www.useronboard.com/](https://www.useronboard.com/)

</comment><comment><USER16> Asking for an email up front is already too much. Let the user use your service, they'll create some "content" or "configuration" in it. Once they do that, they'll want to preserve / persist it, and then you can ask for an email address. They're much more likely to give you a real email address and validate it, because they're already invested.

</comment><comment><USER17> I'm feeling a bit thick. Regarding the change to the sign-up process...

Originally:

> Users couldn't get started on their own. They had to first leave their email > address and then wait for me to send them an email with a link allowing them > to register and start building their Cortado email.

Afterly:

> As soon as users click the submit button, they get an email verification > message in their inbox, which they can click on to set a password and get > started.

So, what changed? In both cases users have to submit their email address and interact with a(n) (automated?) registration/sign-up email. In the second case there's the added hurdle of a captcha (which sounds worse).

<comment><USER18> With the first process, they would leave an e-mail and then author would reach out to them maybe a few days later and maybe a few weeks later telling them they could sign up.

With the new process, they go through the signup process immediately.

<comment><USER17> Oh, "wait for me" doesn't refer to an automatically-generated signup email ("me" is not "server I provisioned").

"wait for me" literally means "wait for human to create email and send it to new user".

Wow, yeah. That doesn't seem good.

<comment><USER18> It's not that bad, actually.

When a product is really early - still being developed, basically - you want to control the number of users you expose to it.

Every batch of users will improve the product but it is unlikely that users will stick around beyond one or two uses.

So you drip it out to users in small batches, and "wait for me" really lends itself well to this.

</comment></comment></comment></comment><comment><USER19> I'm convinced one of the reasons Zoom is so successful (besides being a great product) is that there is no sign up required at all.

Someone invites you to a conference and you just click the link, enter your name and go.

<comment><USER20> That, and it basically just works even if you have huge connection jitter, even if you switch networks during a call, etc. Simply put, using it never annoys me. Reliability beats any fancy designer UX every time.

<comment><USER21> It helps that Zoom's UX is worlds better than Microsoft Teams. The persistent sidebar is fantastic, so is the spacebar-to-unmute shortcut.

</comment></comment></comment><comment><USER22> > I sent registration instructions to all of them within 8 hours, but only 6 > people clicked the link in that email.

I think they drew the wrong conclusion from their data. I don't think it was the double signup that was the problem, it was the delay between signing up and getting the confirmation email.

I think the real lesson here is that confirmation emails need to be short (addressed in the article) and quick.

I know that if I don't get the confirmation email within about a minute, I give up.

<comment><USER23> 100% agree. Spoken like a user and not a PM.

</comment></comment><comment><USER24> Also important:

• Let users use the product immediately after registration (if possible). Don't make them wait for the verification email. Can haunt them with pop-ups afterwards to get that verification and double-opt-in.

• Support single sign-on via Google, Facebook, Apple, Twitter, etc.

• When people try to login unsuccessfully (wrong password), send them an email to login via a link. This was a big growth hack for Uber to increase reactivation rates.

<comment><USER25> +1 for single-sign on (opposed to a gazillion of passwords). Why is manual signup still a thing at all? I'd expect people today to start with single sign-on.

<comment><USER26> My problem with a website having _multiple_ SSO integrations is that sometimes I forget which service I used to sign up with.

<comment><USER25> I have a fixed priority order, but sometimes they add a higher priority later.... :-/ I think it's typically just used as an authority to confirm the email address, so one could be registered with multiple providers and should still work?

</comment></comment></comment></comment><comment><USER27> I think the issue with the initial scenario was that verification emails were kicked off manually and took a long, variable amount of time. Verification wasn't the problem, the delay was imo.

I have a <common-name>@gmail.com account and get to see the shitshow that happens when people signup for services don't validate email. _Many_ people screw up email entry and end up with accounts outside of their control.

What I see, every year:

\- $50-200 of gift cards emailed to me from a guy in Australia.

\- Various memberships for gyms

\- Various loyalty programs.

\- An active airline points program, which sent a password request in cleartext a few years ago.

</comment><comment><USER28> A corollary to this, don't ask users for information that you don't need.

There are a number of popular web services (Spotify was the most recent) that I haven't signed up for because they keep asking for information I don't want to give them or had to think about, such as gender. Every time I'd start the sign-up process, fill in some information, then be confronted with a question where I wasn't sure what the answer was or why I needed to provide the information, and give up. This even delayed me creating an email account by about a year.

<comment><USER29> Is there any data on whether this information is even accurate when it's filled out? I just fill out these kinds of fields randomly. Every. Single. Time.

<comment><USER30> every website i go to things i was born on Jan 1, 1980.

i thought everyone was giving junk info to all the websites. :)

</comment></comment></comment><comment><USER31> Ben - thanks for sharing what you learned.

I highly recommend reading "Don't Make Me Think, Revisited: A Common Sense Approach to Web Usability". It doesn't take long to read but is packed with wisdom. It covers the points that Ben makes in his blog post.

[https://www.amazon.com/Dont-Make-Think-Revisited- Usability/d...](https://www.amazon.com/Dont-Make-Think-Revisited- Usability/dp/0321965515)

</comment><comment><USER32> > I was worried (unrealistically) that I'd get too many users too quickly

20 year old me after putting on some AXE body spray

</comment><comment><USER33> I don't really see the useful insights that the article tries to provide. Yes, if the user wants to register and you send the confirmation email now instead of 8 hours later it will be better. Yes, having more stepts to sign-up results in lower conversion rates, as each new step is a new chance for the user to drop. Keep in mind that you also have to convert relevant users otherwise you would just end up with a bunch of inactive accounts, which is not good, at least not if your goal is more than collecting emails.

</comment><comment><USER34> One of the biggest mistakes I constantly see is that they require an email for you to even see the product or what it does. All this leads to is me never seeing your product. I'm sure you spent a lot of time on it, but I get too much spam as it is. I don't need more just to figureout what you're trying to sell me. I mean, that's your job: to sell to me.

It honestly amazes me how often I see this. No screenshots or even a description. Maybe a line or two and the page looks mostly like an email scraper. SELL ME YOUR PRODUCT.

</comment><comment><USER35> For future reference, don't host images from your blog on Google images. None of them are loading.

PNG/8 or any decently compressed JPEG format will work if you have bandwidth limitations.

</comment><comment><USER36> The best signup experience I've seen is at nextdns: [https://nextdns.io/](https://nextdns.io/)

I clicked on _Try it free_ expecting to go from a typical startup Wordpress site to a JavaScript signup form where I'd fill in an email, password etc.

Instead, bam, I'm in the app with an anonymous account and ready to roll. A big button up top lets me add my email and password later if I like what I'm seeing. Really nice work.

</comment><comment><USER37> Isn't he kind of missing the obvious answer?

Use federated login. Almost everyone has an account somewhere - Facebook, Amazon, Apple, Google, Github, Twitter, Microsoft etc.

<comment><USER38> That depends on his audience probably. I hate it when I have to give permission to things in my Gmail account.

[https://www.bart.com.hk/why-you-need-to-be-very-careful- abou...](https://www.bart.com.hk/why-you-need-to-be-very-careful-about-google- authorization-oauth/)

<comment><USER37> I'm always very careful about the permission I give when using third party logins.

</comment></comment></comment><comment><USER39> Sites that make you create an account and then re route you to login drive me nuts. Can't imagine it helps with conversions either.

</comment><comment><USER40> The third lesson might be:

Don't pick a name for your service that when googling it results in a full page of links to the coffee style and not to your service. (So how do I actually visit Cortado??)

EDIT: Found it after clicking around to your About page: [https://cortadomail.com/](https://cortadomail.com/)

And what's the stack?? :)

</comment><comment><USER41> > Only 38% of people did this. If I had instead captured everyone as soon as > they showed enough interest to leave an email address, I could've increased > my conversion rate by 250%.

How many of these were real losses and how many were people who put the wrong email address in the box, only to realize when they didn't get the verification email?

I have a very early gmail address, first initial + last, name. I can't tell you how many verification emails I get that I never signed up for. Those aren't the bad ones though, the bad ones are when I get emails about Kay's upcoming surgery and follow-up appointments, Kim's yarn orders and Ken's mortgage documents. (All of these are real examples).

Strong email verification flows aren't just anti-bot. They're a level of defense against clumsy users.

</comment><comment><USER42> You can add "don't require a user to be more interested in order to get more interested." For example, it's annoying when I'm trying to decide where to eat and a restaurant's website won't show me a menu until I select a location and start an online order.

<comment><USER43> The flip side of that is your annoyance when you've just settled on what to eat tonight, but then it says "Sorry, you're in Alaska. All menu items cost 50% more, and the exact thing you wanted isn't available in Alaska"

</comment></comment><comment><USER44> Cortado seems like an OK service, and I get that it wants an email address since it works over email.

But regarding "signup friction" – the best way to reduce signup friction is to eliminate the need for signups.

I'd like a version of Cortado that was hosted and just used a URL rather than sending junk into my inbox. Maybe call it Cortado Reader or something.

Or better yet, some sort of syndication protocol (we could call it RSSS for Ridiculously Simple Syndication System) for the web.

</comment><comment><USER45> I had the exact same experience on my app's website ([https://mimestream.com](https://mimestream.com)) as well. I think initially, I was nervous about offering a beta download, so I wanted to manually vet each subscriber and manually send invites. Of course, even a 2 or 3 hour gap resulted in very poor conversion. Presenting the beta download link immediately after a user provided an email, obviously, has resulted in a world of difference.

</comment><comment><USER46> From a mobile developer's perspective, I feel like a lot of these problems can be solved by using "Sign in with [Blah]" buttons. It requires a 1-2 taps for the user the sign in and almost always requires no email verification. Seeing that Sign in With Apple is also available on Safari, maybe this trend will slowly creep into the web and eliminate some of the problems the author was talking about.

</comment><comment><USER47> Please, keep the confirmation email. I get tons of email sent to one of my account because people register for some mailing list or other service and enter MY email address as theirs. If I get an email to confirm, I can safely ignore it and be done with it. Otherwise, it is a major annoyance.

ReCaptcha may be seen as useful to cut down on the number of bots but it screws things up royally when trying to navigate in private mode, or using a VPN.

<comment><USER26> > _Please, keep the confirmation email. I get tons of email sent to one of my > account because people register for some mailing list or other service and > enter MY email address as theirs. If I get an email to confirm, I can safely > ignore it and be done with it. Otherwise, it is a major annoyance._

Seconding this. As a holder of firstname at a-mainstream-email-service, I've had to unsubscribe to mailing lists far too often.

If a service doesn't offer me a way to unsubscribe, sometimes I have to recover the offending account's password and request for the account to be deleted.

<comment><USER48> Why not use an obscure email?

I have never had to deal with that.

</comment></comment></comment><comment><USER49> We implemented a random fake firstname.lastname@example.com account being automatically created upon a user hit's our 'Get Started' Button. The user can then lateron decide to create a real account. If our client wants to come back later they can either write down their fake & random firstname.lastname@example.com & login just with that (it's only known by them) or enter their real address

</comment><comment><USER40> I would love this browser experience when visiting a new website: "<name of site> would like to create an account for you with your (previously vetted) profile data and email. Shall I create a random password and save it to your secure Google account before agreeing?"

And then hitting "Yes" does just that, and I'm in.

The same workflow could be used for shipping info and CC info.

<comment><USER50> Is oauth that?

</comment></comment><comment><USER51> Speaking of lessons, the site is down for me right now, but here's an archive: [https://web.archive.org/web/20200513153013/https://bbirnbaum...](https://web.archive.org/web/20200513153013/https://bbirnbaum.com/two- lessons-on-reducing-sign-up-friction/)

</comment><comment><USER52> Gitlab requires you to sign up using your real name, Github doesn't. I would use gitlab if it was not for that.

</comment><comment><USER53> This is true, but I think there's something to be said about the strength of your product market fit if users put up with really shitty user experience.

</comment><comment><USER54> Definitely missing a proper CTA (call to action) button in the welcome email. It should stand out clearly in the center of the email.

<comment><USER55> Also, it says "Click to register" ... which I feel like I've already done. I think the wording should be revised to say something more like "Confirm your registration".

</comment></comment><comment><USER56> good read! also got me interested in the app :)

</comment><comment><USER57> Is it a satire?

<comment><USER58> Ah! Eop's law!

<comment><USER59> Clever. [https://en.wikipedia.org/wiki/Poe%27s_law](https://en.wikipedia.org/wiki/Poe%27s_law)</comment></comment></comment>


Brazil Prosecutors Plotted Against Lula's Party in 2018 - <AUTHOR> https://theintercept.com/2019/06/09/brazil-car-wash-prosecutors-workers-party-lula/ <comment><USER2> The alledged political motivations of the prossecutors is very much irrelevant as

a) Lula was in fact guilty of operating an extensive criminal organization that transcended his party (in fact the interim president was also caught and is currently jailed)

b) Lula and his minions quite overtly stated that if they were elected they would abuse political immunity to avoid payung for their crimes and also abuse presidential pardons left and right to ensure every single member of their criminal organization would pay for theie crimes.

Therefore any concern with Lula and his minions winning the election has more to do with not wanting the criminals they were prossecuting to get off due to political trickery.</comment>


Center Parcs Pulls Daily Mail Ads Over Tom Daley Article - <AUTHOR> http://www.bbc.co.uk/news/uk-43093154 <comment><AUTHOR> This seems to be a continuation of the "click-bait headline chasing has consequences for publishers" that is slowly playing out.

Advertising revenue that is not aimed at a specific purchase (brand advertising) must be 50% of spend at least - and that's under threat, not just by Daily Mail but Google and facebook cannot control the content they publish alongside</comment>


Invite HN: I am visiting the Valley, would someone like to meet up? - <AUTHOR>

Hey guys. I am a founder and CEO of Qbix, a 3-year-old startup based in NYC. I'm here with our accelerator program until Friday. We'll be presenting at their demo day tomorrow, but I'm interested in meeting up with entrepreneurs and others here in the Valley while I'm here. Tell me about the bay area, show me the ropes, and I can tell you about the NYC tech scene. I'm particularly interested in meeting founders and people who have been working out here for a while. <comment><USER2> I'm in San Francisco, happy to meet in the city on Thursday or Friday. Email me and we will sort times out -- tim at cloudspace dot com</comment>


If you're using Node.js, you're doing life wrong - <AUTHOR> http://codeslinger.posterous.com/if-youre-using-nodejs-youre-doing-life-wrong <comment><USER2> _The Ruby and Python communities are just now, many years after the hype has faded, learning that stuff like dependency injection and proper modularization are actually good things that help you maintain code over time._

This remark is off the mark. Dependency injection, as in _injection by parameters_ and _injection by constructors_ are so obvious people do it sub- consciously. A fluff word isn't needed for it. As far as _IoC containers_ are concerned, I don't see Ruby/Python communities using it, mainly because half of it is fighting static typing.

And people are learning proper modularization now? Seriously? Python/Ruby has proper namespaces(ruby doesn't have it), modules, classes et al. Like any other languages, Python/Ruby has it's share of programmers who write spaghetti code, and programmers who don't.

Again, if he writes AbstractConnectionDepenencyInjectioManagerAbstractFactory and calls it proper modularization, I am happy Python/Ruby isn't picking it up.

<comment><USER3> This was my first thought. Languages require different design principles. If you're calling JavaScript "spaghetti code", then you're doing it wrong.

<comment><USER4> _Languages require different design principles. If you're calling JavaScript "spaghetti code", then you're doing it wrong._

He's calling node style callbacks spaghetti code. Which it is, and it's a known problem, and there are several half-baked solutions for it.

<comment><USER3> Node.js isn't picking up a new paradigm. The issue is very present in JavaScript, and it's easy to write spaghetti code since the language by itself doesn't offer much structure. It's possible to write very clean JavaScript / Node.js code, but it takes a different approach over how you design / develop apps versus a class-based language.

</comment></comment></comment></comment><comment><USER5> Ok, as someone who has been actually building apps on Node for about 1 year AND working with a largish Scala codebase for the last six months:

> Not to mention the fact that its balls-ass slower than some straight un- > optimized Scala.

I don't see the point of comparison here. Slower/faster is meaningless without the context. Apples to Oranges. And, Scala has it's own issues. Yeah, the JVM's performance is there, but bringing your team onto a Scala codebase is not easy either.

> It provides the least amount of aid and comfort to the programmer and its > nigh-on-impossible to follow the code 6 months later.

Anyone who has developed more than a Hello World in Node will know that the problem of callback sphaghetti can be circumvented using events, promises and async libraries. Yes, until the language itself offers an async construct, this will be an issue, but frankly there are ways to get around it.

> JavaScript has very little support for any of those nice things: it doesn't > even have namespaces, for chrissakes.

Client side JS has no module system. But Node.js has. At this point, I really wonder if the OP has actually worked at all with Node.

> It seems to me that people who are really crazy about Node.js are people who > only knew JavaScript to begin with and to whom none of the above would ever > even occur.

Another baseless claim. I urge you to go see the GitHub profiles of Node core committers. Seriously.

<comment><USER6> Nit: _Client side JS has no module system._

Check out requirejs: <http://requirejs.org/>

I've used it to handle both server-side (node) and client-side module systems, and it's been great.

<comment><USER5> Yes, I am aware of requirejs. I was talking about native module support.

<comment><USER7> Native module support is a feature of Harmony and,it's pretty fantastic. I hope Node adopts this method of module loading as an alternative to require in the future.

edit: phone keyboard typos

</comment></comment></comment></comment><comment> jim-greer If you get really angry about the choices other people make for their own work, you're doing life wrong.

<comment><USER8> Approaches that become popular and highly publicized definitely impact everyone else's work in that field. Teams decide to migrate to those approaches, discarding others, based on perceived popularity, shallow impressions, small amounts of experimentation. Often, this is all we have to go on. But team members who have an intuition that the approach may have more problems than are first visible now have a choice, to either silently go along with the new decision, or to document their reservations. The anger is an issue though. It's a product of when you perceive a waterfall of hype crashing over your own perception of better judgment (please note: _perception_. subjective viewpoint). It's worth it to try adjusting those perceptions since anger doesn't really get you anywhere.

<comment><USER9> Couldn't agree more.

We're all aware of the Internet Hype Machine. We've all been duped by it before. Heck, my big project today consists of frantic backpedaling from an overly hasty decision, prompted by the IHM, to use SQLite in a project that had no business being based on SQLite. We should all be open to hearing criticism about choices to use X or Y technology.

-But- if you start by saying, "You're so stupid," then the person you're talking to will start by thinking, "You're such a jerk." And nobody really pays much attention to the opinions of people they think are jerks.

<comment><USER10> Socratic method for the win. Keep asking questions until THEY come the conclusion that what they were thinking was a dumb idea.

<comment><USER11> That works, but I think it's overkill. Generally the "don't argue like a jerk" method is sufficient.

<comment><USER9> And if you aren't good at it it's easy to come off as condescending. Thereby also causing you to be written off as a jerk.

Socrates was smart. He was also executed for being irritating.

<comment><USER4> No, he was executed for "advocating for new gods and against the gods of the city" (that was the actual charge).

You know, much alike someone insulting Mongo, Rails or Node in certain communities... (or Java, CL etc in others).

<comment><USER12> Also for corrupting the youth.

Again, much like Mongo, Rails, and Node. :)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> I'm really pretty anti-node, but this article isn't very good. The concerns here are mixed up and not very thorough. All these points need graphs, charts, something solid to anchor them to. This is the sort of article that polarizes, but doesn't add to the discussion.

It starts off strong talking about a high bug count, but never gets into specifics there.

As far as scaling across cores goes, it's disingenuous to suggest that node can't do this, there are a number of options here. Message passing, for instance, does indeed work.

As far as nested callbacks sucking, I totally agree. But a walk through why would add a lot more substance here as well.

<comment><USER14> Unfortunately, this way of stating unqualified arguments as basis for reasoning is quite prevalent on the Internet.

Keeping it to node.js bashing, this guy takes the discussion to a slightly lower level: <http://youtube.com/watch?v=1e1zzna-dNw>

<comment><USER15> Ha, I liked that. But slagging aside, are the points he makes baseless?

</comment></comment></comment><comment><USER16> > JavaScript has very little support for any of those nice things: it doesn't > even have namespaces, for chrissakes. Why would I want to repeat these same > mistakes over and over again in a new language?

Javascript doesn't have this (by itself) but node has a very nice require() system that is really excellent for long-term maintainability. When you bump a dependency in a node project that change will only affect the code near it because of how node_modules are resolved to the most local copy. You can bump dependencies without worrying how this will affect other packages.

Plus, require() just returns an object. It doesn't puke a bunch of objects into the current scope. This is massively useful for readability. I've sunk a lot of time on other systems tracking down unqualified exports to figure out which package's documentation to consult.

I've got nothing against scala and am sure it's a useful language but I wonder if the author has even used node.

<comment><USER17> How can we even be talking about node and long-term maintainability when it is about 2 years old? And require is younger than that?

</comment></comment><comment><USER18> I don't really have a dog in this fight, but I see node.js as being "disruptive":

* It's "not as good" as languages/environments like Erlang.

* But it's good enough, and significantly simpler, as an approach to tackle a certain class of problems. This, combined with widespread knowledge of Javascript, will probably make it fairly widely used.

<comment><USER19> I disagree about it being that "disruptive". The concepts that it uses aren't new. They've existed in POSIX environments for decades.

At a very basic level, Node.js is a callback-based API that's based around some(probably select) notifier loop. That's not particularly new.

<comment><USER5> The disruption is not about whether the paradigm is old or new. The fact is - today if you are building a small app and need some form of real-time features, your best bet is Node.js. Right from etherpad lite to socket.io you have the tools you need to be up and running and to support a few thousand concurrent users out of the box.

Of course, scaling it past that will be a problem with Node being single threaded and so on - but I believe that these are problems that Node.js will eventually address.

</comment></comment></comment><comment><USER20> Everybody is angry if bugs keep punching them in the face. I get that. But this post needs more info to be informative:

* If I read correctly, OP is using Chrome/V8 directly. I don't see if the bug list is on V8 itself or his bindings?

* "Callback Spaghetti". To each his/her own. I happened to read callbacks easier than other solutions. And this is coming from Python programmer, not JS programmer.

* The last 2 points are also information-less rants. What happened to HN?

</comment><comment><USER21> Here's my problem and why I don't care to use it:

It's a community built around an implementation of a language which they do not control. Who is Guido or Matz in node.js? Ryan Dahl I suppose; does he take requests or hold discussions concerning the future evolution of the language? Does he issue any rationale documents concerning his language design philosophy? Could he add multithreading to V8 and if so, why hasn't this happened?

It's a community built around someone else's tool, and Google develops it for entirely different reasons. Case in point, someone posted IcedCoffee, which adds an "await" keyword to CoffeeScript -- you have to implement a compiled language on top of Javascript to have the language features you need!

Finally, to preempt questions about my being concerned about other people's language choices -- other people are choosing, inexpertly in my opinion, the technologies with with I will contend in the future. Future employers may value and demand experience in node, and future employees may have to be disabused of bad habits accumulated during the learning of it.

<comment><USER22> This comment is just wildly off the mark. You're comparing a framework to a language. DHH can't add features to MRI Ruby any more than Ryan Dahl can add features to V8 JavaScript.

<comment><USER21> Off the mark? Perhaps. Wildly so? Unlikely.

But if that's so, then simply view this as an explanation for why I don't use server-side Javascript. And Node is still a tool built around a language implementation which is going in a different direction from where a server side environment/general-purpose language needs to go.

<comment><USER22> You're welcome to use whatever you like, of course — I'm just saying that you haven't really raised any specific objections that couldn't be (and haven't been) leveled against most other languages. Ignoring the confusion of a language and a framework, so far, your concrete objections seem to be:

• Node.js is a framework built by people other than the language's core maintainers (which is true of most frameworks)

• If you want to add fundamental language features, you can't just force it into the core implementation, but will have to implement your own offshoot (which is true of most languages, including, for example, Clojure)

If you're really concerned about other people's language choices, you're going to need concrete reasons, not just generalities, vague insinuations and your own personal preferences.

(Edited a bit to clarify and because the original phrasing sounded more combative than I intended.)

<comment><USER21> No, there is no language v. framework confusion on my part. What I'm arguing _is_ a concrete, fundamental fact that pertains to both the framework and the runtime.

I'm not sure what I can do to clarify the point anymore: the V8 engine is created and maintained for the purposes of speeding up a web browser's processing of Javascript within the context of an HTML document. The goals of the team implementing the runtime are not to create a general purpose language, they are to create an engine which excels at one specific use case, and granted this use case is broadening over time.

But to address your point: yes, the developers of Pyramid (to take an example) have not to my knowledge submitted code to e.g. optimize networking functionality in core Python so that it better suited their specific needs. On the other hand, the Python team has had an excellent track record in observing and adapting to trends within their community -- the introduction of WSGI is one such example.

The Python community has a PEP process for generating discussions about what the language needs. To my knowledge, there is no discussion within the V8 developer community about how to make the engine more suitable for server-side programming. And how would you begin the process of adding general programming features to the language itself? Join ECMA?

 _If you're really concerned about other people's language choices, you're going to need concrete reasons, not just generalities, vague insinuations and your own personal preferences._

Excellent editing. Much less combative.

EDIT: Actually I'd like to add a couple more things:

 _Node.js is a framework built by people other than the language's core maintainers (which is true of most frameworks)_

That is not a point of contention. That is a simplistic reduction of my point which conveniently serves your argument.

 _If you want to add fundamental language features, you can't just force it into the core implementation, but will have to implement your own offshoot (which is true of most languages, including, for example, Clojure)_

This entirely misses the question -- why use a language whose core feature set does not cover your use cases? Why use a language where you _must_ extend the language to get fundamental features? Moreover, no you will not have to implement an offshoot to get core features. At the risk of repeating myself: when you have control over the direction of the language's evolution, you can petition and propose changes.

<comment><USER22> With regard to getting changes made: Both V8 and the ECMAScript committee have development mailing lists and issue trackers where you can submit and discuss suggestions. AFAIK, this is basically the same way Ruby operates. They aren't likely to make vast, crazy changes, but I don't think, say, a PEP for static typing would get very far either.

And I think it's kind of a basic misconception that V8 is made just with web browsers in mind. If you look on the V8 developer site, nowhere does it say anything close to that. Their stated objective is "fast execution of large JavaScript applications." They go out of their way to draw a distinction between the browser and the engine, explaining what is and isn't part of JavaScript (e.g. the DOM is just an interface that browsers choose to expose). Is Chrome the original client for V8? Sure. And shell scripts were the original use case for Python. It seems to me that "V8 is just a browser language" is the new "Python is just a scripting language."

And I wouldn't describe the language-level ability to write asynchronous code in a synchronous fashion a fundamental feature. It's really cool and allows a lot of expressiveness, but so would a lot of potential changes in, say, Ruby. If you don't want the language feature, there are really nice libraries that get you most of the way there. (And I don't really see how the existence of CoffeeScript or ICS is any more an indictment of V8 than the existence of Scala is of the JVM. Choice is a good thing. Lots of people prefer vanilla JavaScript.)

</comment></comment></comment></comment></comment></comment><comment><USER23> It's posts like this that make me embarrassed to be a programmer. The author basically states, "Node.js is not a good fit for my company, therefor everyone using node.js is wasting their time." It's generalizations like this that just blow my mind.

I don't go around saying, "Snickers is the worst candybar, therefor anyone who eats a Snickers is wasting their time."

I bet the author is not a pleasant person to work with.

</comment><comment><USER24> I guess it depends on what I how I want to do my life. If I want to live my life by learning new ideas and using those ideas for something tangible, Node's a pretty good choice. If I want to live my life as a person with a particular language/architectual ideology, then anything that is not in that world view is wrong.

I like node for system level scripting. I find bash annoying and non portable to windows. I really don't want to have to learn batch scripting for dos on windows. But I can use JavaScript with node to script in both environments.

On the server I think that node might be helpful for certain network level tasks. But I haven't used it for much. But honestly what type of person would I be if I don't even consider it? The OP seems to be making an emotional decision rather than a technical one. Interestingly he's using Scala. There are many similar posts about Scala being the wrong way to do life. I just can't agree with any of those views.

Finally I wonder what the value is for these rage posts. They just seem to further divide people. I do see the value in the posts about I've used node for X months, here's my thoughts or here's why I'm going back to X paradigm. But just a rant where faces should be punched seems out of place for HN.

<comment><USER25> If you like Node for system level scripting, you're gonna love this: <http://www.jsdb.org/>

Don't let the name fool you, it's not only for databases. I would say that it's probably more suitable for general purpose scripts than Node, though some of the APIs are a bit clumsy.

It's not open source, but it's free and cross platform and actually pretty good for a lot of general purpose scripting. Seems that it is developed by a single guy. I found out about it a few years ago and used it to get some things quickly done.

</comment></comment><comment><USER26> Article like this needs to be sliced-n-diced in different ways:

1) If you don't know technology X and use it due to hype, you deserve to get burned

Let that be a lesson for anybody.

2) There's no silver bullet

Choosing node.js over web-framework just because you want the front-end and the back-end to use the same code-base is to trade one feature for another: Ruby and Rails still have better tools than Node.js while you get JS all over the place (assuming you're good with JS).

3) Complaining about the language is a sign that you have no clue

I used to think that Java is better than some of the hype dynamic languages out there but I was wrong: Java is better for ME because I _KNOW_ Java Better. If I know Ruby more than I know Java then Ruby is better than Java FOR ME.

4) Don't program using another language's idioms

This is documented left and right already. If you use technology X, find best- practices for technology X. Don't just apply best-practices from technology Y.

<http://dirtsimple.org/2004/12/python-is-not-java.html>

Or some of the comments here about Dependency Injection (which is quite common in Java but not so in Python/Ruby).

In the past, I had one instructor that noticed that my QBasic code looked like Fortran. He asked me if I knew Fortran beforehand and I told him that I've taken Fortran before this class.

People see and notice.

</comment><comment><USER27> Node enforces a programming model that puts you down the path to extreme vertical scalability, you know, actually using all the hardware you are paying for. CPUs and the kernels that manage them are good at running code. They suck at waiting for things to happen.

Out of the box the callback model can be difficult to wrap your head around. But if you are serious about writing a vertically scalable IO-bound service, it is currently the only option. There are some add-ons to make the code less ugly, but you still have to have the mental model down.

It's a lot like multi-threaded programming, or functional programming. It's a matter being able to visualize the flow and pass context around. This takes time to change the way you think.

If you approach problems in Node like you'd approach a problem in a functional language the spaghetti of callbacks becomes much less of a burden.

For the async haters out there operating at scale. How many of you have farms of machines with idle CPU's, maxed out memory, and practically idle network interfaces? Yeah, I thought so.

</comment><comment><USER28> Node is not for every use case,

This tech talk on node is pretty interesting

<http://sna-projects.com/blog/2011/08/nodejs/>

I watched it last weekend, and from what I understood/remember from the talk the reason the node people picked javascript was not because they liked javascript. It was because they wanted to do async programming, and they found other languages had too much synchronous baggage. In javascript, node.js could start from a clean slate and build a pure async culture and environment.

</comment><comment><USER29> The problem I see with all these kinds of negative posts concerning Node.js is that they essentially boil down to "this is so radically different and uncomfortable to me that it cannot possibly be good for anyone else." and do not provide any concrete business examples of why it should be avoided.

Until I see an actual example of how "Node.js crashed my business, cost us N dollars, and here's exactly how...", I will continue to look at such posts as developers complaining about having to learn to do things a new way — something that has been going on since there were developers.

</comment><comment><USER30> I have to agree with the rest of the commenters here. You make a blanket statement about something you've obviously never used. You're leveraging hearsay and third party complaints against a framework and language that you don't appear to be overly familiar with.

</comment><comment><USER31> The spaghetti code of node.js callbacks is really a problem of Javascript lacking monads, and in this case something like the Async monad from F#.

TameJS is a step in the right direction by adding a C#-style await.

</comment><comment><USER32> His comment about node.js only being able to use a single core is bullshit, and has been for a while:

* Before native support: <https://github.com/learnboost/cluster>

* Now, native: <http://nodejs.org/docs/latest/api/cluster.html>

</comment><comment><USER9> I've got my doubts about Node.js, since it seems like rather a one-trick pony.

But it is a good trick. Node.js deserves credit for calling attention to an underappreciated design pattern that has a lot to offer in certain circumstances. (Personally I think the .NET team hit the nail more squarely on the head with TPL, a pony that can do that trick as well as many others. But .NET doesn't have the sex appeal it takes to be a spokesmodel so meh.)

Javascript isn't my favorite language, or the most performant one. But as a "Lisp with C syntax", on a semantic level it's much better suited to the higher-order programming techniques that the pattern requires than most other popular Web languages are. Ruby also has the right features, but it isn't exactly the poster child for high-performance computing either. Might as well flip a coin, because either way opinionated folks with blood pressure conditions will call you an idiot.

</comment><comment><USER33> Programming with Node's async model makes it extremely powerful and fast to run database queries and file functions in parallel, but the downside is the potential for huge callback spaghetti indeed.

But the callback spaghetti problem can be largely solved by dropping in, for example, the IcedCoffeeScript fork:

<http://maxtaco.github.com/coffee-script/>

Or the previous JavaScript TAME functionality:

<http://tamejs.org/>

There are of course many other async helper solutions as well, and if you're doing serious Node development, it's kind of insane not to use one of these.

<comment><USER7> If you expect a lot of callback it makes more sense to design that functionality as an object rather than as a single function. That way you can spread callbacks over many functionality and still maintain modularity.

<comment><USER33> Not necessarily -- the issue is not so much code modularity as much as control-flow issues, which separating out functions (mandatory) doesn't necessarily help with (because of all the flags of what function should call what other function afterwards, etc.).

</comment></comment></comment><comment><USER34> I haven't used node.js before, but I see 2 main points being made about it, by proponents and detractors respectively:

* It uses non-blocking evented IO so it can scale well.

* It is single threaded so it can't scale well.

Someone teach me: which of these statements is true?

<comment><USER35> Neither are true.

Non-blocking evented IO is mostly attractive from a usability point of view: it's much easier to write programs that aren't multi-threaded. It can also use much less memory than a threaded model _in certain situations_.

Non-blocking, evented systems tend to be single-threaded. Single-threaded systems don't automatically scale across multiple cores. To scale, you spawn a separate process for each core (for example, this is the suggested practice for node). You must then find some way for the different processes to communicate with each other, which is usually through a database (or some crazy pub-sub thing).

Node can scale just fine if you design your program to do so. It just scales in a different way.

<comment><USER36> Personally I love it, but some programmers find non-blocking evented "async" IO completely counter-intuitive. So it's debatable on the usability.

Async IO is an absolute win from the scalability perspective because it allows you to service a great many clients with many fewer threads. OS thread context switches are relatively expensive. Ideally you would have exactly one OS thread per physical core and they would never need to block on exclusive access to any shared resources.

Now that we have a system where the user code inside the async handler doesn't need to manage exclusive access to anything, from the usability perspective it can has some of the simplicity of code that is fully single-threaded. But that's subtly different from saying ASIO makes it easy.

My guess is that many of the same programmers who aren't comfortable writing multithreaded code aren't going to find it completely intuitive to rethread their stack around an ASIO model.

</comment></comment></comment><comment><USER37> Nonsense. Perhaps your choice to use Node.js is suboptimal? That isn't an indication of Node.js's quality, it's an indication of your inability to choose the right tech. People choose tools that make it easier to do something, Node.js accomplishes that for a wide range of tasks.

I just spun up a IM API we needed in an _evening_ thanks to Node.js and community contributed packages. It's humming along great, I even wrote up a piece about it: <http://news.ycombinator.com/item?id=3547664>

</comment><comment><USER38> It seems to me like the author overly cares about languages, when the power of Node is the community and its simplicity of use - there's very little boilerplate even for complex things like network programming.

Who cares about the language. Use JS if you want, or use Scala. At the end of the day is the maintainability of the product you're developing that matters.

I feel, for example, that NPM is much easier and simpler to use than something like Maven. If it makes my life easier, I'll stick with it.

</comment><comment><USER39> "The Ruby and Python communities are just now, many years after the hype has faded, learning that stuff like dependency injection and proper modularization are actually good things"

WTF?!

</comment><comment><USER40> Node solves a problem I don't have in a so convoluted way that if I ever have that kind of problem I won't be using node for sure.

Is there a need for webstackers to go play at the server side? YES! but node is not THE solution, it is just ONE solution. I venture to say, as javascript evolves more towards a coffeescript flavor, then a coffeescript flavor on the server is what is needed.

And I'll support something along these lines.

</comment><comment><USER41> If you're using [your fav framework], you're doing life right.

Just use it and see if it works out for you.

</comment><comment><USER42> All the points that OP mentioned, whether they are correct or not, are irrelavent.

The only factor that drives technology success is the people, aka the community. There are a lot of people on board of nodejs. This just creates more gravity and pulls more people toward it. Together, the community will carry the momentum that drives its success. If v8 is not server technology like OP said, there are enough open source developers to make its on fork.

</comment><comment><USER43> Never take life advice from someone who responds to hype with a compulsion to "punch faces" while donning "rageface". To be fair though, I bet this is just a casual blog entry that the guy didn't know would hit HN.

<http://meyerweb.com/bkkt/okaythen.gif>

</comment><comment><USER44> Please give me a break. This guy made some points: spaghetti code, .... He state it in the wrong way, however one should admit that node.js is not mature enougth for many use cases. I'm still learning but, haven't seen how just by using node.js you get a scalable server.

</comment><comment><USER45> I recently evaluated Node and Scala for a presence server for an iOS app. With my naive understanding of both platforms, it was way easier to do this with Node. It would be interesting to hear more detail about how Scala was used and why it was better.

</comment><comment><USER46> This is hilarious.

</comment><comment><USER47> Okay, let's play a little game. I'm going to describe a scenario (using Python; feel free to substitute the equivalent Ruby terms if that makes it more relevant for you).

You're a pretty good Python developer. You know, and feel comfortable with, not just Python, but the entire ecosystem. Virtualenv, pip, the whole nine yards. And now you're working on a really nifty Django app, maybe a CRM or something, when you realize...

...damn. This app really needs a lot of functionality ripped out and shoved in the browser. I'm losing my marbles writing spaghetti jQuery code, but what I really need is some client side templates.

So you poke at it, and think about it, and you realize that the proper design of your app is _really_ a bunch of client-side code using Backbone, and a server that just handles authentication and is otherwise a thin RESTful wrapper around your database.

Great! But at this point, most of the actual code you will be writing is Javascript. Your server could be written in, practically, anything. And there's some compelling reasons to leave it in Python. On the other hand, if you switch to node.js it means all your code is in the same language (which is nice). It also opens the door to being able to use the _same_ code on both the client and the server - which is really good. Client-side templates are nice, but being able to render them on the server when you need to is practically a requirement. And Python's support for rendering Javascript templates is very limited. And if you're a Python coder, you'll probably want to be writing your client in CoffeeScript anyhow, which requires having node.js installed, so, at least for development, just have the whole damn stack in node.js. You can always hack together a little RESTful server in Python later if you decide that node.js isn't right for production.

Seems simple enough, right? And as you can probably guess, I just went through this process. And so now we have this blogpost, which is saying...well, it's not really clear what it's saying. That I should be using Scala, I guess. This is, frankly, so wrong it's embarrassing.

1) Even if the JVM was just so amazing and awesome, I'm not a JVM developer. The ecosystem is radically different. As a Python developer, I'm able to install, configure, and be productive with node.js very quickly. npm, nvm, coffeescript, and we're away. My IDE of choice (PyCharm) even supports CoffeeScript. There is very low impedence. Switching to Scala...where would I even _begin_?

2) I'm doing this because I need to write a client side app. That must be written in Javascript, or something that compiles to Javascript. Scala is neither. And while there are JVM language that _do_ , there are some major concerns with their suitability, maturity, and tooling. Clojurescript looks great, but it's not something you pick because you think coffeescript is too new and little used!

3) The rant would be more compelling if the author came across as someone who actually knew anything about Python, Javascript, or node.js. Contrary to his assertions: Javascript does have namespaces. Python and Python developers have ALWAYS been convinced that modularity is good. And Python developers are still quite aware that dependency injection is a way to solve problems with the design of Java which aren't even relevant to their language of choice.

4) Also, if you don't grok callbacks, it doesn't _mean_ you are a bad programmer. But it might be worth keeping in mind that there are plenty of programmers who do, and they're going to laugh at you when you reveal you don't. Not to mention that there are plenty of ways of programming in node.js WITHOUT callback spaghetti, and revealing that you have no clue about the framework your slagging is not going to improve your credibility.

5) To continue the theme, insulting a framework for not scaling well may work better if you don't reveal that you don't know how it scales in the same paragraph.

<comment><USER48> Two points for you: 1) CoffeeScript does not require Node...npm may make it much easier to install, but you can definitely run it without installing Node. We run the compiler as a Maven plugin, but it's distributed as JavaScript and all you need is an interpreter. 2) There are templating languages that have interfaces in both JavaScript and other languages to allow the same templates to render on both the client and the server. We use Java on the server, so we're looking at Closure Templates, but for Python, you might want to look at Mustache.

If you've already finished your project, I'm not going to try to convince you to move away from Node, but if you've got a lot to do still, you might consider sticking with Python. I'm not saying that Node isn't a workable solution on the server side, I just don't think it's proven that it is the way that Python and other, more mature platforms have. I don't give too much credence to inflammatory posts like the one being discussed, but when I see posts like: <http://news.ycombinator.com/item?id=2519674> from a developer I respect, it gives me pause. That post is 18 months old now, so the situation could have changed.

There's something to be said for building things you know are rock solid and won't result in 2am notifications. That's my perspective, so I try to stay away from the bleeding edge. For stuff that's not critical, I'm more ok with taking a few risks. But someone's got to be the one that takes those risks in a mission-critical environment to figure out which of the new technologies will become proven and which will fail, so I disagree that these people are doing life wrong. If it wasn't for people like them, my way of doing life right wouldn't work.

</comment></comment><comment><USER49> What's the problem if someone creates great stuff with it?

</comment><comment><USER50> Glad to see someone has been brave enough to come out against this. I too don't like Node; JavaScript was never designed to take on this sort of load.

</comment><comment><USER51> Certain tools are used for certain jobs. Node.js is a different tool and I welcome it. I don't curse a hammer because it is not a screwdriver.

</comment><comment><USER52> I love articles like this. All the dry analyses, the subtle counter-counter- arguments, that the usual tech opinion articles on HN have make me nuts.

The little layer of emotion and drama added here gets the point across much better, IMHO. Of course it doesn't do anything but preaching to the choir (hi there), and not convincing anyone not already in the choir, but it's a great read! (and so is this thread).

In other news, if you're voluntarily using a dynamically typed language and an editor without an integrated debugger, you're not fit for programming!

</comment><comment><USER53> Wow, this guy seems like a very angry person.

</comment><comment><USER54> Wow, seriously? This is just as bad as the fanboy "you'll use X for EVERYTHING!" posts. Please.

</comment><comment><USER55> different tools for different jobs

</comment><comment><USER56> From the article: "The hype around Node.js on this issue makes me want to punch faces."

"But the kind of misunderstanding going on in this video clip seems to pervade the Node.js hype and gives me rageface."

This seems like a really over-the-top response to people that have a differing opinion. I can't take the rest of his post seriously after reading these parts. This certainly isn't the sort of thing you read in an informed opinion piece.

<comment><USER57> That's also what I took away from it. Aggressive writing, insults, and condescending tone isn't a way to win friends and influence people--except, possibly, those who already agree (judging by the HN comments).

He seems to have some valid criticism, but I can't say it's anything I've heard before. If anything, the article itself is flamebait and at least partly intended to troll.

After browsing through the comments here on HN, I think he succeeded. But then, everyone likes a good flame war once in a while...

</comment></comment><comment><USER58> Node seems unnecessarily complicated and faddish, but if you really want to mire yourself in callback soup then go ahead. I'll just be over here, not tearing my hear out.

</comment><comment><USER59> You're just using it wrong</comment>