What Twitter could have been - <AUTHOR> http://daltoncaldwell.com/what-twitter-could-have-been <comment><USER2> _Perhaps you think that the API-centric model would have never worked, and that if the ad guys wouldn't have won, Twitter would not be alive today. Maybe._

I think this deserves a bit more attention. It's easy to point fingers and make all kinds of what-if predictions, but just handwaving money aside in favor of a poorly defined API utopia ignores the reality of running a business.

<comment><USER3> Agreed. It would be a much more compelling argument if there were examples of successful API companies presented as possible models for Twitter as an API company. (In addition to the example of Google as an advertising company.)

<comment><USER4> Yes I have to agree with the two of you. That was my first thought upon finishing. It's odd Dalton doesn't define one or two solid examples of what this successful cloud API could be.

<comment><AUTHOR> I felt that discussing alternate business models was outside the scope of the post for 2 reasons: 1) I am an outsider, and no one understands what could or could not work better than the people working at Twitter. I am not sure what the pro-API camp inside of Twitter had in mind. 2) Debating which model would work better would derail the points I wanted to make in my post.

I do think there are several large cloud companies that have both their "native" UI and rich/powerful APIs. For instance Salesforce, which my company both pays for & extensively modifies and extends via their API. Given the attention this post has attracted I may write a followup post just on this topic.

<comment><USER5> > Given the attention this post has attracted I may write a followup post just > on this topic.

I hope you do, I am very interested in this topic and I would like to hear what you say and what people have to say in response to it.

</comment></comment></comment></comment></comment><comment><USER6> A "firehose" API for the net would be awesome, but it probably needs to be Open Source, in order to avoid being driven towards monetization. Of course, without the drive to make money, Twitter may have never taken off quite the way it did, and may have never had the money to spend on SMS and other expenses they were dealing with in the beginning to create that firehose of data.

The Open Source twitter clones (like identi.ca) have modeled what Twitter became, mostly, rather than what Twitter could have been...so, as far as I know, there isn't much out there that answers this description. I'd started working on something I was calling SYSRSS years ago, which was to be a realtime systems human and machine readable data stream protocol and implementation, but never got a minimum viable product out the door, as I could never quite figure out the right niche for such a thing. I think it may have been too specific, though building on top of an existing popular data format and protocol was probably a valid choice.

In short, I agree that Twitter could have been more awesome than what it is. But, I don't know if I could have made it better, or that having the API guys win would have succeeded. I haven't done any research into that field lately...I wonder if there are any new developments in the Open Source world for this kind of thing?

<comment><USER7> Telehash is the Open Source "firehose API" you seek. The proposal describes a DHT that routes JSON. However, it seems like I've been waiting for it for years. Maybe it's the obscure telephone lingo that the API is described in terms of that's discouraging would-be implementers, but it's nothing that a good old facade can't fix.

<http://telehash.org/>

<comment><USER8> Telehash is radically decentralized. How do you get a firehose out of that? It would be more like a point to point garden hose wouldnt it? I would like to be proved wrong, but I think Twitter/centralized and Telehash/decentralized will end up looking and acting like two very different services.

If the Twitter as an API group had won out the two best outcomes I can think of are either a buy out from Google, or a move to a foundation like Wikipedia. Google could afford to carry it, like it does Youtube, just so they could own a huge firehose of information and use it elsewhere in search ads, without trashing the stream with ads.

Needless to say founders looking to get rich wouldn't go for the low returns of the foundation model but it would have been the best possible outcome for the well being of the future Internet having and open, censorship resistant message bus and API, assuming you could get enough donors to support it.

<comment><USER9> With a telehash style distributed messaging bus you'd need to have clients opt in to centralized reporting and analytics providers, like the library of congress, internet archive, even commercial firehose companies like gnip, etc.

</comment></comment></comment></comment><comment><USER10> "One camp wanted to build the entire business around their realtime API."

I think the real problem with this is that Twitter made an even more fundamental mistake early on, which is that they only support text and not data/microformats. That is, there is no way for a professor to tweet out the homework in such a way that it automatically gets added to students' dayplanners, no way to list something for sale in a globally searchable way, no way to tweet out a dating profile, etc.

Twitter really should have been the company that enabled the semantic web and became the de facto platform powering the entire thing.

<comment><USER11> Bravo!

When Twitter introduced annotations, I thought that was the beginning: soon, we would have Twitter classifieds, Twitter marketplace, Twitter as a data firehose for anything... All I was waiting for is annotations in the Search API. I'm positive that's all that was needed to provide the initial infrastructure for semantics -- the community would take care of the rest. Unfortunatelly, not only has it never happened, but Twitter took an entirely different course.

I can understand them, though. They had to start making money fast and took a less risky road. But I can't help thinking: bugger, this could've been so much more than celebrities and hashtags.

<comment><USER12> I understand how ads seem like a less risky road, but I really don't like using Twitter's website. Nor, am I that crazed about their app. I can't be the only one. It seems like a good way to lose users.

</comment></comment></comment><comment><USER13> I particularly disagree with the conclusion that Twitter would have become some sort of magical panacea as opposed to the screenshot he provides: [https://twitter.com/#!/daltonc/media/slideshow?url=pic.twitt...](https://twitter.com/#!/daltonc/media/slideshow?url=pic.twitter.com%2FAPZkZ1J1)

The problem there is yet another crappy "what's hot" or "what's trending" or "what's popular" block. Google can't solve it for news, Netflix can't solve it for movies, Amazon can't solve it for related products, and a half-borked, underfunded API for accessing the Twitter firehose is unlikely to create an ecosystem for startups that magically condense the entire world's real-time chit-chat into something I find compelling.

Yet isn't that block fundamentally the (false) promise of Twitter? We'll let you, Mr. Brandybrand [perhaps an individual], target your products and ideas and political manifestos that change the world and the blog posts and cat pictures and defamatory attacks and racist sentiments that don't -- somehow to people who'll find it interesting?

The World's Fairs promised us flying cars; Hollywood promised us a flying skateboard. Both still live on in our dreams, so I have a tough time thinking "marketing" killed 'em.

Especially given Twitter's very public technology missteps. Hash exclamation point, ya digg? Half a billion later and the site still loads correctly about as often as Gawker does. He's bitching that an API can't party on their data? Hell, I can't even retrieve my own direct messages from a year ago on the site itself.

Meanwhile: somebody just replied in email with "HAHAHAHA!" Gmail inserted a widget offering to translate it from Filipino and shows an ad for Coconuts beside it. Coconuts! Meanwhile my last Twitter notification is in the Spam folder.

Nope, this isn't "the marketing guys."

<comment><USER8> Trends on Twitter just aren't important enough for everyone to constantly cite as to why Twitter sucks or why our species is doomed. Its just a source of brief entertainment to see what large numbers of people you probably don't have much in common with are obsessing over at the moment.

Effective Twitter usage is to follow large numbers of interesting people and news sources and then look at the trending topics among the people you care about, you have things in common with and whose opinions you value. Unfortunately Twitter doesn't do trends for just your stream which is one of the many reasons third party clients can rock and Twitter, the company, tends to not rock.

</comment></comment><comment><USER14> Nah. The internet was built to be decentralized with no single point of failure. Twitter and facebook and other centralized services are not the future. Cloud and tiers are fine as commodities, but having ONE company manage ALL the infrastructure for a particular type of communication is not the "internet way". The futurist in you shouldnt be upset.

Imagine if all email went through a single company's servers, and "fail whale" meant you had to WAIT until Email.com was back up until you sent that file to the coworker across the hall from you...

What we need is a protocol and a decentralized, open source reference implementation.

</comment><comment><USER15> A bit off topic, you totally psychologically hijacked me for a kudo. :-P

I was curious what the kudos were, so I hovered over the icon. It told me not to move and started filling up, so I waited curiously. Finally, it counted that as a kudo from me to you!

That said, you have a good point. They really have taken a different road recently with their crackdown on the API. They've got every right do do so, and they're making money doing it (always important for a company), but it would've been really interesting to see the equivalent of an API-based SMS- style nearly-ubiquitous service.

<comment><USER16> That happened to me too the first time I saw a link to this blog on HN. But now I'm wiser. Fool me once, shame on you, fool me, can't get fooled again.

<comment><USER17> Agreed, although I periodically "give" a kudo just to see if the platform has improved to allow one to revoke a kudo. It hasn't. It's a shame actual "kudos" get conflated with "what's this thing do" over and over. Was the design aspect overlooked or intentional? Either way It's a disrespectful UX error.

<comment><USER18> If not intentional originally, defiantly intentional now: <http://dcurt.is/unkudo/>

<comment><USER19> Wow, he's not fooling me with his rationalisations:

 _Here's what it actually does: when you hover over the button, a CSS transform animation is activated which fills the circle. After 1 second (the length of the animation), it fires a request to the server which increments an otherwise meaningless number by exactly one._

Simple response: If that number is meaningless, why give it a fancy animation, why name it 'Kudos' (which even a non-techie would agree is equivalent to a +1, Like whatever) and then why place such a meaningless element next to every meaningful blogpost? If he just wants to amuse himself, may I propose random() in whatever prog. language he uses to update some meaningless local variable. I do like Dustin's blog, but it's sad to see the self-deception going on here from an otherwise smart guy with loads of reputation to lose.

</comment></comment></comment></comment></comment><comment><USER20> This feels like an opportunity. I'd love to hear a broader description of the sorts of functionality that twitter could have become as a messaging API instead of an ad driven business.

Anybody have any thoughts to share?

I wonder if twitter's early and longlasting scaling problems affected their choice at all.

<comment><USER21> I know that when iOS 5.0 mentioned 'twitter integration' and BBM like messaging, I had assumed (wrongly) that iOS was going to use twitter DMs in the way that they are using iMessages now. This would be using a person's twitter handle instead of the Apple ID associated with the iPhone. Like I said, this did not come to pass, but it could have been used as a BBM-like messaging service pre-iMessaging.

</comment></comment><comment><USER22> As long as you have a centralized system, the entity that runs it has to make money sooner or later.

What we need is a decentralized protocol that does what the "API Twitter" could have done.

<comment><USER23> I think that's called HTTP. Then all you need is a place to search the content, where hosting that is easier than hosting all the data. And that's called google.

<comment><USER22> HTTP doesn't have pubsub built in.

<comment><USER23> Rss? FTP?

<comment><USER22> No. More real-time, more efficient than polling. You're not going to build twitter on RSS alone.

This might qualify: <https://code.google.com/p/pubsubhubbub/>

</comment></comment></comment></comment></comment><comment><USER24> Pie-in-the-sky companies have to make money eventually. Either you start making money, or you'll have to do it later and that may disappoint some people.

</comment><comment><USER25> For a year or two I've predicted the ultimate demise of Twitter, which probably means some kind of acquisition. I stand by that prediction. They have hundreds of millions (if not billions) so it's not going to happen overnight but it will happen.

What is Twitter? I see it as two things:

1\. Infrastructure: it is a means of sending thousands of short messages a second to people in asymmetric relationships. Technically this isn't a hard problem. There are many companies around who handle traffic many orders of magnitude above this. The danger with infrastructure is that it will get commoditized. The cost in terms of resources (bandwidth, CPU, power) is not that high;

There are parallels between Twitter and SMS. SMS survives and is hugely profitable because of the telco cartel that monopolizes it. Where hosting companies will provide you with bandwidth for cents per GB, SMS costs thousands if not millions of dollars per GB. That too will come to an end eventually. What saves it now is all the players want to push their own standards and they aren't interoperable. It's IM fiefdoms all over again.

2\. An audience. Twitter and its users have the ability to reach a large number of people. Originally Twitter was envisioned as a means of real-time status updates between normal people. My impression is that this use case is basically dead. The vast majority of Twitter usage seems to be as a communication tool by celebrities. There is a business in that but it isn't the revolutionary communication tool it was once thought (and some still think) it to be.

So the camps in question (the API camp and the ad camp) fit into the above.

Owning infrastructure can be hugely lucrative (eg SMS). History is full of examples of this. Railroads, oil, telephony, etc. The problem is that you get too big and the government will intervene.

Messaging infrastructure is too important for one party to own it. Email is federated and open. The future of messaging is too (I believe) federated and open.

So that leaves (2), the ad camp. The problem with advertising on Twitter is the same as it is on Facebook: it's an unwelcome intrusion.

Perhaps Twitter could have (and may still be able to) build a display ad business but Twitter is still not a particularly mainstream product (and IMHO it doesn't look like it ever will be).

Perhaps Twitter could've had a subreddit/Facebook pages type hubrid model. Upvoting of Tweets is possibly interesting.

Of course this faces the same problem Digg had: few things are globally interesting. What's interesting to you is not necessarily interesting to me so you changing what I see is again an intrusion.

Basically "content gateways" (like Digg, Slashdot, etc) were I believe transitional. I don't believe you'll have a repeat of Digg moderators being paid to promote stories. You can (and people do) pay celebrities to retweet things but that still only goes to their followers. They have to consider their brands and building and keeping their respective audiences too.

Those thinking Twitter should have an open firehose (or close to it) are neglecting the reality that Twitter is a business and needs to make money somehow. Open access to their content greatly diminishes that.

Lastly, quite a few people will speak of "betrayed" by Twitter over API access. They also believe that developers were largely responsible for making Twitter popular. As I said (just yesterday) that this is inevitable. Become too successful and the platform subsumes you into their core offering (no one wants core features controlled by third parties). Developers were I believe largely incidental to Twitter's success. Twitter succeeded (as it were) because people used it. To take credit for that as a developer community is like saying that the automobile succeeded because of car wash stations and autoshops selling rims.

EDIT: one last point. It's popular, particularly on HN, to simply build an audience or something that scales without concern for monetization. I certainly understand the logic behind this. Sometimes it works but sometimes it doesn't.

Twitter hasn't come up with a scalable business model yet because there isn't one. As much as founders can be praised for "swinging for the fences" and going all in, sometimes the best outcome is to be acquired because what you've developed isn't a viable independent business but could be an incredibly valuable part of a wider portfolio of products.

<comment><USER26> My thought about the Twitter business model has always been that they shouldn't charge for putting information into the stream, ala advertising.

They should charge for taking information out of the stream, like a polling company, or consumer research, or business intelligence.

Not for the stream, but for the firehose. And for specialized analysis of the firehose.

There would be massive value in knowing what everyone in the world is thinking about in real time.

Getting there should have been their goal.

<comment><USER27> They do this already, minus the analysis. I think the problem is this just isn't that big of a business.

<comment><USER26> I suspect the problem is more that they haven't found the way to make it that big a business, not that it can't be.

Oh well, if they don't, someone else will down the line.

</comment></comment></comment></comment><comment><USER28> The sad part of this is that Twitter was going in this direction:

<http://blog.twitter.com/2010/05/twitter-platform.html>

I don't think the reaction would be nearly as bad if Twitter was better at making clients for their own service. They aren't very good at it. Twitter for Mac (née Tweetie) is dying on the vine.

TweetBot is 10x better on iOS than the native client, and Osfoora on the desktop.

Why not meet the challenge of an ecosystem in conjunction with ad revenue rather than just blanket rule against it?

<comment><USER29> I disagree that Twitter's official iPhone client is "bad." You may like Tweetbot more, but I am a power user who actually prefers the official client.

It's not a question of good vs. bad, it's more like good vs. better (where better is a personal preference).

<comment><USER28> Do you disagree that they have abandoned their native Mac client?

Personally I don't think the "Discover" tab is worth its real estate in the menu.

</comment></comment></comment><comment><USER30> > One camp wanted to build the entire business around their realtime API. ... > The other camp looked at Google's advertising model for inspiration, and > decided that building their own version of AdWords would be the right way to > go.

There was a 3rd camp, those who wanted Twitter to become a protocol instead of a silo. From the sounds of it this camp must have been especially small. It's a shame, it was the only way to make it viable long-term.

<comment><USER31> The only way to make what viable long term?

</comment></comment><comment><USER32> What a bizarre post. A company could have entered a different market and killed it 5 years ago... however that market has still yet to materialize, whereas the market that the company actually entered was rather lucrative. Also, Steve Jobs could have invented a company to build hover cars and that company could have changed the world.

</comment><comment><USER33> Would be cool to see a startup creating a "Twitter for computers" service. An highly reliable system that can be used just to route messages via an API, with a semantic similar to the one of twitter, to be used as a building component for everything you need. Not sure about what a business model would look like.

<comment><USER34> Wasn't this one of the basic premises of Notifo? As far as I recall, they never did quite figure out the business model, though.

</comment></comment><comment><USER35> Great post. It seems like there are several different interpretations of what an API-centric business model would have looked like: the "all the data in one place" model, and the "communications bus for the internet" model. (These are not mutually exclusive, necessarily.)

I always loved the idea of Twitter as a communications bus for the internet. It probably would have been very challenging to monetize (though "we have all the data" as a thing to sell isn't bad, it works well for google in a search/1.0 context because they also have all the intent and all the UI around it).

It makes me wonder how much this set of decisions was driven by the amount of capital they raised and the need to demonstrate monetization.

It seems like deciding the business would be ad-supported was the first step toward becoming MySpace2.0.

</comment><comment><USER36> It seems to me that the potential success of the realtime API approach would be reliant on impressive, profitable applications. Although I can think of a few, I can't think of enough of them to argue against the AdWords approach, which apparently drives revenue for now. If Twitter had chosen the API direction initially it would have been partially on them to cultivate the developer community required to make their strategy works — which could be seen as orthogonal to developing a great product and solving infrastructure problems.

In the long run these two approaches may not actually be at odds with one another. AdWords-ish works for now, and as new apps are developed there may be an opportunity to move back in that direction.

</comment><comment><USER37> Not to mention their photo product (their partership with photobucket or whatever) is pretty bad... Even the two links in this article that point to twitter photos come up 404 on mobile... wtf. The third party tweet photo sites are still better.

<comment><USER38> Twitter's mobile site is a complete joke. It wasn't until last week that I could actually see a tweet somebody linked to.

What is more frustrating is I don't _ever_ want the mobile site (there's an app for that). I just want to be able to see tweets people like to.

</comment></comment><comment><USER39> This post is relevant: <http://news.ycombinator.com/item?id=552821> 'How Software Companies Die'.

The engineers/product developers lost and the marketing won. It happens many times because developers are busy building value while marketing/business is scheming/planning/making deals. When this changes we will have more truly awesome products I believe, when Japan was seriously winning they were engineer and product focused but have business/marketing bloat destroying these products nowadays. Making needs as much focus as marketing.

<comment><USER38> The "marketing screws companies up" meme is old and tired. Yes, bad marketing sucks. So does bad engineering. The reality of creating a business is you need to market it. It's one company in a thousand that can survive with no marketing, and that happens purely by luck.

Marketing is actually really hard. The internet has also drastically altered how marketing happens, since the conversation now needs to be two-way (not just blasting out advertisements). The companies who do this the best don't get credit for great marketing because it just appear natural.

What is worse about this meme is it becomes poisonous inside companies. Instead of everybody working together to build the company, you can have people trying to satisfy agendas. Engineers focus on technology instead of products; marketing tells lies in an effort to force engineering down the path they want.

The only thing about this meme that has any value is that, at its core, the meme talks about providing _real_ value instead of _talking about_ value. But it is the height of arrogance to believe only engineers can create something of value.

<comment><USER40> People just don't seem to be comfortable with grey. And this is a problem I especially see with newer devs: there _has_ to be _one_ right way that _fully_ solves a problem.

The balancing act between seat-of-the-pants thinking and methodical problem solving is THE key to business survival.

</comment></comment></comment><comment><USER41> TL;DR: This thread contemplating "Diaspora* for Twitter"

</comment><comment><USER42> Last year I wrote about Twitter as a platform for life:

[http://krisgosser.com/journal/2011/10/twitter-as-lifes- platf...](http://krisgosser.com/journal/2011/10/twitter-as-lifes-platform/)

This article has similar thoughts: if only Twitter allowed us to combine other things like our cars, bodies, appliances, and jobs so that communication was actually useful instead of simply social.

</comment><comment><USER43> Do you have many concrete thoughts on what the API-Twitter could have looked like now (if not dead, that is)? Tons of clients alone doesn't make an ecosystem.

Up until the 'stop making clients' announcement I'd always vaguely hoped that Twitter would become the true online identity - but perhaps that's just Facebook aversion talking.

<comment><USER8> Are you asking how could they have made money or what cool things would they have done? I dont care about the making money part, the cool things they could have done being the Internet's message bus:

\- Really good search, and access to the entire message archive, instead of hiding their archives in order to monetize it \- Better lists/circles with more granular control over private/public messaging and groups \- Better conversation ability, for example ability to make a list of users you want to have discussion with and have an easy way for everyone to follow the threads, ability to make it read only to the general public, so everyone can read but spammers can't ruin it, or take it private to everyone on the list. \- Video/audio chat/hangouts might be on some people's list, I'm not sure it belongs in the core message service \- Creative ways to make the message service the definitive breaking news medium. It already is but you kind of need ways to rein in the bogus news \- Curation & moderation, methods to elevate interesting messages, though this moderation should be an option and easily disabled to avoid groupthink \- Karma, though again it should be optional \- Better support for real-time streams for topical hash tags like conferences, spam killing being the main issue. Clients can do a lot of this but spam killing benefits from support from the message service. \- Openly embracing and facilitating academic research on their firehose, archives and social networks

This list could go on all night, buts just a few of my favorites.

</comment></comment><comment><USER44> You mean Twitter was better when they started out, had no way of monetizing the service & had constant infrastructure problems resulting daily service outages?

Yeah, I'd really like to make a single entity with a single point of failure a fundamental piece of the Internet's infrastructure.

</comment><comment><USER45> If there were some successful API companies in past, they would probably go an API route. The problem is that Ad based business is well understood while selling API and selling real-time information and being a 'real-time information bus' is something quite new.

</comment><comment><USER46> Agreed, but how realtime API business would have made money?

</comment><comment><USER47> often times i think twitter has become myspace circa 2006.

</comment><comment><USER48> I'd pay a few dollars a month or year in order to: (1) never see ads (promoted tweets, etc.; retweets from channels I follow are ok), and/or (2) premium features like a more sophisticated Twitter iOS app, etc. I'm always surprised by any debate on the web around "OMG how can they monetize? Ads are annoying. Conundrum!" because I thought this was a solved problem in the business domain a long time ago. Identify things people are willing to pay for, and then sell that to them. Those things exist. Do it, rinse, repeat.

<comment><USER49> Many websites have adopted the donate-to-see-no-ads model - Slashdot, Reddit, OKCupid etc - but as I understand it none of those have exactly thrived on the donated money.

Has it been more successful than I've heard?</comment></comment>


MH370: Australian official rejects theory that pilot ditched aircraft - <AUTHOR> https://www.theguardian.com/world/2018/may/22/mh370-australian-official-refutes-theory-that-pilot-ditched-aircraft <comment><USER2> After the MH370 crash, are there any initiatives to make some kind of water- deployed radio beacon standard equipment on large passenger aircraft? Seems like _a lot_ of search expense could have been spared if MH370 has been with one of these, and by now we'd already have these answers.

[https://en.wikipedia.org/wiki/Emergency_position- indicating_...](https://en.wikipedia.org/wiki/Emergency_position- indicating_radiobeacon_station)</comment>


To Launch a Nuclear Strike, President Trump Would Take These Steps (2017) - <AUTHOR> https://www.bloomberg.com/politics/graphics/2016-nuclear-weapon-launch/ <comment><USER2> The article describes what happens under the launch on warning (LOW) policy.

It's not clear if the US has LOW policy. It seems like Clinton administration made some changes to the policy after the Cold War.

It's more like launch under attack (LUA). If the US has credible second strike capability and command chain that survives decapitation attack, there is no need hurry. Mistake can be catastrophically. Confirming nuclear explosions first would seem as sane default even if you want to keep others guessing what the real presidential decision directive is.

Clinton Issues New Guidelines on U.S. Nuclear Weapons Doctrine

[https://www.armscontrol.org/act/1997_11-12/pdd](https://www.armscontrol.org/act/1997_11-12/pdd)

>Bell said the press had incorrectly indicated that the PDD "still allows" the United States to launch nuclear weapons upon receiving warning of an attack. Bell emphasized that "there is no change in this PDD with respect to U.S. policy on launch on warning and that policy is that we do not, not rely on it." In fact, Bell said "in this PDD we direct our military forces to continue to posture themselves in such a way as to not rely on launch on warning—to be able to absorb a nuclear strike and still have enough force surviving to constitute credible deterrence."

>Bell pointed out that while the United States has always had the "technical capability" to implement a policy of launch on warning, it has chosen not to do so. "Our policy is to confirm that we are under nuclear attack with actual detonations before retaliating," he said.</comment>


App Mining plans to pay developers $1M per month - <AUTHOR> https://blog.blockstack.org/app-mining-plans-to-pay-blockstack-developers-1000000-in-stx-per-month/ <comment><USER2> Muneeb and Ryan and I talked about this a long time ago and I continuously told them I didn't believe they'd actually pay app developers in App Mining and that I especially didn't believe they'd pay out an aggregate total of $1mil per month. Glad the prove the skeptic in me wrong!</comment>


Why We Should Build Software Like We Build Houses - <AUTHOR> http://www.wired.com/2013/01/code-bugs-programming-why-we-need-specs/

<comment><USER2> House fall on someone, very bad. Software crashes, meh.

</comment><comment><USER3> I love this.</comment>


Svelte 3: Rethinking Reactivity - <AUTHOR> https://svelte.dev/blog/svelte-3-rethinking-reactivity <comment><USER2> From the tutorial:

> Svelte is giving us a warning:

> A11y:  element should have an alt attribute

> When building web apps, it's important to make sure that they're accessible > to the broadest possible userbase, including people with (for example) > impaired vision or motion, or people without powerful hardware or good > internet connections. Accessibility (shortened to a11y) isn't always easy to > get right, but Svelte will help by warning you if you write inaccessible > markup.

Thank you! We accessibility advocates have wanted this kind of checking to be built into mainstream development tools for years. I hope Svelte becomes popular for this reason alone.

<comment><USER3> Eslint already warns you about issues like this, and is framework-agnostic. Does Svelte just use eslint under the hood? Otherwise you risk fracturing the ecosystem with framework-specific a11y requirements.

<comment><USER4> Accessibility requirements for the web have a centralized source in the WCAG. As long as linters/checkers conform to that, it doesn't seem like it should be a source of fragmentation.

</comment></comment></comment><comment><USER5> I'm really impressed that the release announcement starts by explaining what Svelte is. It's a little thing, but it's appreciated.

<comment><USER6> It's really not a little thing. The number of blog posts that talk about why version N+1 of X is great, assuming I know what X or version N did is stupid, and I am immediately churned out.

<comment><USER7> This is basically v1 though, so it's a bit different.

<comment><USER8> Uh, it's v3... People are using both 1 and 2 in prod...

</comment></comment></comment></comment><comment><USER9> Congratulations on the launch, Rich! It's looking like we're really starting to approach the form and function of what "a language to build the web" ought to be.

One small question about some of the pragmatic choices in Svelte 3: What was the decision process behind choosing to smuggle the new reactive features under a "standard" JavaScript skin? ($:, export let, etc.) Is it just to avoid needing to rewrite all existing JS tooling — parsing, syntax highlighting, linting — or is there something deeper going on?

<comment><USER10> Thanks Jeremy! As I've expressed elsewhere, observablehq.com provided important inspiration. I've also been influenced by your own comments in the past about a language for building web apps.

It's exactly that — there's so much tooling in the JS ecosystem that we can lean on, and by inventing new syntax we'd be throwing all that away. It'd be great if we could do `prop answer = 42` and `a <= b`, but it's just not worth it — once you get used to `export let` and `$: a = b` it quickly becomes second nature, we've found.

<comment><USER11> > I've also been influenced by your own comments in the past about a language > for building web apps

Hey Rich have you seen Imba?

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

It's not reactive, but it doesn't need to since everything is memoized. I think it's interesting that they made their own language to solve the front end problem.

They used it to build [https://scrimba.com/](https://scrimba.com/) which is pretty awesome.

<comment><USER10> I have seen it, yes. I'm impressed by the ambition, though I think that in the long term it's better to work with the grain of the platform by extending the web's existing languages rather than creating a new one.

Memoization certainly makes Imba a lot faster than VDOM-based frameworks. Of course, it's only really beneficial when not many things have changed!

</comment></comment></comment></comment><comment><USER12> "The magical disappearing UI framework" was a much better tagline than "Cybernetically enhanced web apps" …

<comment><USER13> Magical disappearing makes it sound like a cheap parlor trick.

<comment><USER14> Also includes the word "magical", which is risky.

</comment></comment></comment><comment><USER15> Nice handling of reactivity - I think this should already be in language as well.

I'm not sure I like this single components approach and embedding JS in HTML.

The problem with this is that it's too frameworkish.

The big benefit of JSX/React rendering is that it's composable and declarative (as it's just functions), but it's also simple to get - render just returns wanted structure, given the state and you can use simple assert to verify that.

Solutions like angular/vue/svelte rely on custom template parsing which IMO sucks, because it's hard to extend/test without specific template compilers. JSX in contrast is embracing language.

I think that render functions written like in react and data reactivity is the simplest approach to describe application. Seems like VueJS with JSX is closest to this right now.

It would be cool to keep similar API but maybe use compiling to have smaller bundle/older browsers support/different platform support etc.

To be clear by similar API I mean just pure JSX components, where you plugin reactive data, that could be tested without any frameworks and without rendering. This is the simplest way, yet nobody build it yet - MobX + pure React components is close to this (problem is that still rendering is done by React, so rendering isn't most performant - depends on components hierarchy) - with compilation/integration you could make it more performant, but I would keep declararive nature and simplicity of JSX.

<comment><USER16> Check out my library DOM Expressions([https://github.com/ryansolid/dom- expressions#readme](https://github.com/ryansolid/dom-expressions#readme)) It's almost exactly what you are talking about. The libraries I've written on top (Solid.js, MobX JSX, and KO JSX) are among the fastest on the JS Frameworks Benchmark([https://krausest.github.io/js-framework- benchmark/current.ht...](https://krausest.github.io/js-framework- benchmark/current.html)). The future is already here.

</comment></comment><comment><USER17> I'm currently working on a giant React frontend codebase and it's baffling how slow certain simple things are for our users. Yes it makes it easier for us to reason about, but performance should be able to scale without hacks.

Svelte seems to show a lot of promise, but I have a few things that I'm not 100% on.

1\. How are the higher level abstractions for Svelte? Any framework can be easy for simple applications, but how easy will this be to reason about as we get to larger applications? React deals with this through a semi-functional mindset. What does Svelte offer?

2\. Is there any plans for facilitating incremental rollouts? Changing your application to an entire new framework is not always worth it, and is greatly difficult. I could imagine Svelte being incredibly useful for large-scale, performant applications. However, unless it can be incrementally rolled out, then I can't see how the biggest players will be able to utilise the power of Svelte.

I'd love to see the game changed in web frameworks, and I love the idea of using compilers where possible. If anyone could answer these queries, I'd be very much grateful.

<comment><USER18> > I'm currently working on a giant React frontend codebase and it's baffling > how slow certain simple things are for our users. Yes it makes it easier for > us to reason about, but performance should be able to scale without hacks.

What's the underlying reason for the slowness?

React applications can definitely be written to be performant without resorting to "hacks", typically using immutable data structures (that support reference equality checking) in combination with judicious use of PureComponent/shouldComponentUpdate/React.memo. Also using something like react-virtualized/react-window for large lists/grids.

<comment><USER19> I've never worked with React, but I have worked on giant AngularJS (1.x) apps and medium-sized Vue apps. I've only seen performance issues on pages with long repeated lists that create a lot of $watchers. This is fairly straight- forward to solve, and I know that Vue and Angular are both a lot smarter about tracking changes than AngularJS was.

Is React more difficult to keep responsive as an app grows? What sort of UI paradigms lead to poor performance? Just the phrase "using immutable data structures (that support reference equality checking) in combination with judicious use of PureComponent/shouldComponentUpdate/React.memo" makes it seem like you need lots of in-depth React knowledge and additional packages to write a performance React app.

<comment><USER20> React's default behavior is that when a component re-renders, React will render all of its children recursively, even if they are receiving the exact same props as before.

In many cases, these re-renders return the same render output as the previous render, which means that no changes need to be made to the DOM. These renders are referred to as "wasted", because React went through the work to ask your component "what do you want the UI to look like?" and diffing the output, when nothing actually was going to change.

The two key aspects of optimizing performance in a React app are:

\- Decide if the props and state for this component have meaningfully changed

\- Tell React to skip the rest of the rendering process for this component (and therefore skip the rest of this subtree as well)

The standard approach for checking for changes is simple reference checks: `prevProps.a === props.a`. For larger amounts of data, this assumes you've updated that data "immutably", by making copies and modifying the copies instead of the originals. This can be done with plain JS objects and arrays, it just can take a bit more diligence. (Libraries like Immer [0] can help with applying those updates immutably.)

For the "skip rendering" part, React has offered several APIs over time, but they all basically boil down to "do shallow comparisons of data, and bail out if they're the same":

\- The old / deprecated `createClass()` API allowed use of a `PureRenderMixin`

\- Classes have a `shouldComponentUpdate()` lifecycle method where you can implement whatever custom comparison logic you want, and return `false` if the render should be skipped

\- Since the typical comparison in `shouldComponentUpdate` is a shallow equality check of both props and state, the `PureComponent` base class was added that does that by default

\- More recently, the `React.memo(MyComponent)` API was added to allow wrapping any component (class or function) with that same bailout behavior.

All of those are actual React APIs, not separate packages.

All that said, the React team advises that you should just write the app first, _then_ profile it later (in a production build!) to see where the key bottlenecks are and just optimize those. In most cases, you probably don't even have to do anything - performance will often be sufficient as-is.

React's DevTools have a performance profiling tab [1] [2] that helps show which components rendered for a given update, which makes it a lot easier to track down unnecessary renders. The community has also created various "why did you update?" libs that log unnecessary renders.

[0] [https://github.com/mweststrate/immer](https://github.com/mweststrate/immer)

[1] [https://reactjs.org/blog/2018/09/10/introducing-the-react- pr...](https://reactjs.org/blog/2018/09/10/introducing-the-react- profiler.html)

[2] [https://www.netlify.com/blog/2018/08/29/using-the-react- devt...](https://www.netlify.com/blog/2018/08/29/using-the-react-devtools- profiler-to-diagnose-react-app-performance-issues/)

</comment></comment></comment></comment><comment><USER21> How easy would it be to "hook into" Svelte's compilation pipeline so that users can create their own optimisations? I ask that because I work in a huge codebase with many layers of component abstraction and performance is starting to take a hit. For example, most of these components:

      <Box flex flexAlignItems="center" marginTop={5}>
        <Heading level={2} caret="down">
          Profile info
        </Heading>
        <Media>
          <Avatar id={avatarId} size="small" lazy />
          <Media.Block marginLeft={2}>
            {displayName}
          </Media.Block>
        </Media>
      </Box>

would be compiled into their simplest forms:

          Profile info

            {displayName}

I believe the technique is called "component folding". I tried to do it with Babel but it's a real pain.

Thanks for putting so much work into exploring alternative ways of making the web faster, because, at the moment, it still requires an immense effort.

<comment><USER22> Yeah, I search the same solution. Because, I don't like write CSS and prefer use component abstraction layer, which allow write much simple code and it's really nice to read

</comment></comment><comment><USER23> Immer.js (a library to work on data structures, not a framework) uses a similar concept, using Proxies.

The gist of Immer is that your framework needs immutable structures, but you want to interact with them imperatively.

It's very interesting, and a reversal of the traditional "functional core, imperative shell" architecture.

[https://github.com/immerjs/immer](https://github.com/immerjs/immer)

<comment><USER10> Yep, and Svelte <3 Immer — they work nicely together.

<comment><USER24> Great work, just looking in to Svelte now after reviewing your latest release and video. First thing I looked for was routing, and I see Sapper is essentially batteries-included solution to using Svelte.

Will these always be separate libraries? Is Sapper basically the create- svelte-app for your framework? What's the roadmap for Sapper and integrating Svelte v3 changes?

<comment><USER10> Bringing Sapper up to date is the next big task. In some ways yes, it's a bit like create-svelte-app, though a closer reference point if you're versed in the React world would be Next.js.

We've also mulled creating a React Router equivalent, for people who prefer components-as-routes to files-as-routes.

</comment></comment></comment></comment><comment><USER25> I recommend everyone to take a look at the talk linked in the article. It gives you a good overview of how awesome svelte is and how easy it is to use.

I chose vue over react for simplicity and I'll be damned if I don't choose svelte over vue for the same reason and more after this talk.

</comment><comment><USER26> _Hooks have some intriguing properties, but they also involve some unnatural code and create unnecessary work for the garbage collector._

Thank you for pointing this out. To me hooks were always a way to solve problems in React that wouldn't be there if it weren't for React. They help, but come at a cost which barely anybody seems to talk about.

 _We really want to add first-class TypeScript support._

Yes, please!

<comment><USER27> Hooks solve a definite problem that I'm not sure is limited to React, but at the end of the day they feel too much like magic to me.

Reasoning about hooks is hard.

<comment><USER28> I find this interesting. Could you give an example of a case you find hard to reason about?

</comment></comment></comment><comment><USER29> I'm excited about the updated Svelte. Although it is currently nowhere near being in the top handful of frameworks by adoption, it has some very forward ideas. Most prominently, look at the first main value proposition on its website:

"Write less code"

Svelte has a ways to go to catch up with the leaders on popularity and future breadth, but it is focused on the right problem: reducing the cost/size/effort of making things.

<comment><USER30> Funny: problems I think are important are "ship less code" and "read less code" (and perhaps "require reading less code to understand what's going on"). The writing part is not something I've considered to be especially problematic, thus far.

<comment><USER10> Allow me to try and convince you of its importance :) [https://svelte.dev/blog/write-less-code](https://svelte.dev/blog/write-less- code)

<comment><USER30> I actually read that just before this comment :)

 __Edit: __Some more clarification about why the arguments don 't hold for me.

\- More code = more bugs

I think code that is harder to understand leads to more bugs, but more characters typed does not necessarily directly result in more bugs, as far as I know.

\- Writing code takes more time

Again, it's not the typing that takes time, but thinking of which code to write. If I have to type more, but there's less for me to keep in mind while typing (i.e. lower cognitive load), I'll be faster at that.

As said: yes, readability is important, but that's a different value than "write less code".

I'm trying not to make a judgment about Svelte here specifically since I haven't worked with it yet, and the general concept (of being a compiler rather than working during run-time) appeals to me. That said, concepts like bindings do scare me - with e.g. `useState` I know that the only places that can change `a` are those that call `setA`, whereas it appears that with Svelte, it can also change e.g. in response to `bind:value` attributes? I'm (perhaps misguidedly) afraid that that's saving a few characters at the cost of readability.

<comment><USER10> > more characters typed does not necessarily directly result in more bugs, as > far as I know

Most of the discussions I could find on the topic before writing that post suggested that the error rate per thousand lines of code is surprisingly constant across languages, which suggests that more characters typed _does_ result in more bugs. I learned that from the internet though, so take it with a grain of salt!

It's true that `bind:value={foo}` offers another way to change the value of `foo` besides `foo += 1`, since at that point you're explicitly opting in to two-way binding. If you prefer, you certainly can do the `on:change={handler}` thing instead, but as I argue in the post I think that's less effective at capturing the _intent_ of your code (and gives bugs more places to hide). This is definitely a subjective area though.

<comment><USER30> > Most of the discussions I could find on the topic before writing that post > suggested that the error rate per thousand lines of code is surprisingly > constant across languages, which suggests that more characters typed does > result in more bugs. I learned that from the internet though, so take it > with a grain of salt!

It's an interesting subject, but I'd like a causal explanation rather than just the correlation. For example, this would imply that TypeScript code would be more buggy than its Javascript equivalent, since it's the same code I'd write otherwise, with additional annotations. (Then again, there is _some_ code, like null checks, that I _don 't_ have to write with TypeScript, so perhaps that evens out.)

> I think that's less effective at capturing the intent of your code

It's been a while since I've worked with Angular.js, the last framework I used with two-way databinding, but now having this conversation I think I recall the main reason it was confusing. A pattern that would sometimes arise is e.g. for a component to receive data through a two-way databinding from its parent, and then likewise passing that on to a child. That could make it very hard to trace where a change was coming from.

It might well be the case that it is far less problematic when e.g. only used to bind form values. Again, I'd have to try it to get a proper feel for it, so I'm looking forward to doing that.

<comment><USER31> > It's an interesting subject, but I'd like a causal explanation rather than > just the correlation.

A large benefit with less code is about the signal/noise ratio. If you need plenty of boiler plate logic, you will have less signal that you can physically read & mentally process at a given time. We naturally ignore the noise, but the noise takes screen space & miscategorizing noise leads to bugs.

Less code leads to less bugs, especially high-level bugs, because the programmer can see more signal at a given time, thus being exposed to a larger system.

The study that Rich mentioned could be interpreted as relating to the comprehension of the code, where more code inherently means the system has more information & is more difficult to comprehend.

Re: two-way binding, the data flow is inherently confusing whether you use imperative or declarative logic. Do you want a clear concise representation or do you want to spread out the implementation over more code/files?

<comment><USER30> Absolutely, and "higher signal-to-noise-ratio" _is_ something I'd count as a selling point. However, I don't believe fewer characters necessarily result in a higher ratio.

So in the case of two-way data binding, if I'm trying to trace how a certain value was be modified, data flow in the opposite direction might count as "noise", in terms of extra cognitive load.

Again, this might not be something that is the case for Svelte, but it's what I observed in Angular.js.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER32> Since you are reading here Rich Harris; while I really admire your solutions, one weak point with Svelte seems to be a clear unit testing solution, or at least docs last I looked. I also noticed this with Ractive, and feel it weakens these in the eyes of many businesses considering these tools.

I know it's a solved/solvable problem but it feels like better docs and samples in quick start guides would help.

<comment><USER33> I admire Rich Harris' work as well. 4 years ago I was picking my first SPA framework. Narrowed it down to Ractive and Vue. Picked ractive, it had a beautiful documentation and tutorial. Still have an app in production based on ractive. But author abandoned it. Then vue 2 took off. I didn't have a choice but switch. Recently I started playing with Svelte/Sapper again. I like it a bit better than vue for some reason and was looking to use it in the next project of mine. So svelte 3 comes at right time for me.

The author is a brilliant developer, but he should narrow his focus on Sapper/Svelte now, beside which he has many other projects (rollup, etc...)

<comment><USER32> > But author abandoned it.

To be clear though, Ractive is still under development by other maintainers: [https://github.com/RactiveJS/Ractive](https://github.com/RactiveJS/Ractive).

> he should narrow his focus

Not to speak for him, but I think Rich is an "idea guy" and we'd all miss out if he were throttled to just one thing :-)

</comment></comment></comment><comment><USER34> This is roughly how QML works too right?

> Cybernetically enhanced web apps

That is pretty terrible! It seems to me that the main think that distinguishes Svelt is that more work is done at compile-time? Why not a slogan that says just that?

"Compile-time optimised reactivity." or "Low overhead reactive web apps" or something like that. Cybernetics is nonsense waffle.

Anyway good luck! Seems like a better approach than shadow DOM etc.

<comment><USER35> Agreed: compile-time optimization is a pretty good pitch. Rust and Typescript and Haskell have done all the PR necessary for this pitch; you have a prepared audience.

</comment></comment><comment><USER36> One area where the virtual DOM seems to be important is for rich text editors, where the VDOM can basically take the input, diff it using an immutable structure, then render it to properly structured HTML.

An example use case where this would be valuable: a user hightlights text, bolds it, then highlights it again plus some more text, and bolds it. A naive approach would have: This text is bolded plus I bolded this when what you want would simply be: This text is bolded plus I bolded this

Libraries like DraftJS and SlateJS use immutable data structures to parse the input/formatting in the VDOM and reconcile them into "blocks" (basically javascript objects containing the formatting) that deduplicate formatting.

The talk below on DraftJS is pretty good.

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

What's the recommended way to handle a rich text application in Svelte? Is there anything like the above for Svelte?

<comment><USER10> Rich text editing is possibly a special case, though the right person to ask about that would be Jacob Wright ([https://github.com/jacwright](https://github.com/jacwright)). He's the creator of [https://www.dabblewriter.com](https://www.dabblewriter.com) (which uses Svelte) and a Svelte contributor, so he probably knows more about this topic than just about anyone else!

<comment><USER36> Thanks for sharing! Looks like Jacob has open-sourced a svelte-based rich text editor based on Quill. Link below for anyone who is curious.

[https://github.com/typewriter- editor/typewriter](https://github.com/typewriter-editor/typewriter)

</comment></comment></comment><comment><USER37> I tried Svelte/Sapper a few weeks ago. It is definitely not the new framework of the month that come and go.

I love it. I cannot believe how fast the app load on both first and second time visits. 100% in lighthouse.

I think Svelte is the way to go! I hope the community will accelerate and eventually catch up with React and Vue!

</comment><comment><USER38> Mithril.js has been doing plain javascript variables for years :) Basically, React's decision to use setState is an overoptimization. Mithril (and flutter, interestingly) opts for global redraws, greatly reduces end-user code complexity while still being fast for most all cases.

<comment><USER39> Thanks for mentioning Mithril. When I saw Svelte example output js, I thought it was actually a better developer experience layered on top of Mithril. (Mainly because of the similar m() mounting function)

```

function create_fragment(ctx) { var h1, t0, t1, t2;

return { c() { h1 = element("h1"); t0 = text("Hello "); t1 = text(name); t2 = text("!"); },

      m(target, anchor) {
       insert(target, h1, anchor);
       append(h1, t0);
       append(h1, t1);
       append(h1, t2);
      },

      p: noop,
      i: noop,
      o: noop,

      d(detaching) {
       if (detaching) {
        detach(h1);
       }
      }
     };

}

```

</comment></comment><comment><USER40> I went through the tutorial. It's quite confusing. I've been doing front-end SPA apps for about 10 years now.

The framework that has blown me away with it's simplicity and elegance but power is snabbdom.

It's small, it's fast, it's modular. You can use it with jsx, you can use it with webcomponents if you want. You can type it with typescript. Animations check, custom module extensions, check.

As the recent experiments in wasm has shown, you can make extremely fast vdom diffing that is memory allocator friendly.

So my bet in the future is this. Vdom will be here for a while. It's simple, elegant and we'll figure out how to make it faster with newer tricks.

More non web UI frameworks will use similar approaches. React Native is paving wave here but I can see desktop apps and terminal apps embrace the same concepts too.

View as function of state is a very powerful paradigm. State being a simple dumb old nested object. No magic tricks.

Svelte feels too magical. Vue has same issues. It's hard to reason with magic when you hit edge cases.

You ideally want a simple model in your head so you can build really complex apps by connecting simple axioms of logic.

<comment><USER13> The whole point is that there is even less magic than react, vue etc. If you have time I'd strongly encourage you to watch the video shown in the post.

[https://svelte.dev/examples#dom-events](https://svelte.dev/examples#dom- events) Look at the compiled output (the "JS output" tab), it's so readable and stepping through it with a debugger is actually possible for mortals unlike trying to step through code using react (I know, I've had to do it..).

</comment></comment><comment><USER41> This is really cool. That said, I noticed that it cites performance vs vdom as a selling point. Something I've been wondering lately is how big of an issue is UI performance for most web apps really? So many of the little apps and prototypes I develop aren't hurting for performance. It seems to me the industry made a huge leap from JQuery/Backbone/etc to reactive/vdom. But declarative UIs and virtual doms don't solve exactly the same problem; they just go well together. Are there any frameworks out there that provide a JSX/VueSFC/hyperscript development experience, without adding the complexity of a virtual dom implementation? I think developing UIs in a declarative fashion is a big win, but having a virtual dom seems like it should be treated more like an optimization to me.

<comment><USER42> It's really surprising that people put faith in virtual Dom implementations, when browsers have been optimized for decades for efficiency. With the right batching strategy that minimalistic libraries like FastDom [1] offer, there's no real reason to use the virtual Dom.

A frequent argument for the use of vdom has been that it reduces Dom trashing. I am willing to bet that if a vdom library has figured out what elements don't need updating, the browser's Dom implementation tuned over decades has that logic built-in. So go ahead and trash the Dom, but batch your updates and the browser's logic will likely not trash more than necessary. And since that logic is implemented in an AOT compiled language, it probably is much faster than a js v-dom

[1]: [https://github.com/wilsonpage/fastdom](https://github.com/wilsonpage/fastdom)

<comment><USER43> I was waiting for someone to post this. We have tried hyperhtml, various VDOM implementations like Vue and React, but nothing compares for our complex app. We use FastDOM however we are starting to realize it may in fact be causing some issues with write conflicts with third party scripts requiring DOM mutations. That said requestAnimationFrame which FastDOM also uses, can be majorly helpful for any thrashing. Curious what Rich thinks of FastDOM library or while I'm at it his opinion on (not a UI)..[https://meiosis.js.org/](https://meiosis.js.org/)

</comment></comment></comment><comment><USER44> Their interactive tutorial with sandboxes is really impressive. That's a great onramp into actual usage. It might also be cool to have a good way to "eject" the sandbox into a functional local build.

<comment><USER10> Anything built inside [https://svelte.dev/repl](https://svelte.dev/repl) has a 'download' icon (top right) which gives you a zip file containing a ready-made project. We basically just need to have a way to take you from tutorial/example pages to the equivalent REPL page — it's on the TODO list :)

</comment></comment><comment><USER45> I'm wondering how good Typescript support is. Can I use Typescript in the component script?

<comment><USER10> Sort of, via preprocessing, but you won't get any real benefit from it at present. There are two barriers: the compiler itself needs to become TS-aware, and we need to teach editors like VSCode how to typecheck inside


Finding money and meaning in the blue collar trades - <AUTHOR> https://www.artofmanliness.com/articles/blue-collar-trades-career/ <comment><USER2> I have a lot of respect for tradespeople (my dad was a builder) and there's money to be made everywhere. I just paid a few hundred for some damp-proofing - a couple of guys, taking their time, doing an excellent and non-backbreaking job, good cash money for it too. Their rate of pay per hour was greater than mine, tapping away at my keyboard.

</comment><comment><USER3> So good. I work for a guy like this. Dropped out of school at 16 to work in a trade. Now he owns and runs a massive business and has written some of the code that runs a very complex manufacturing system.</comment>


How Fighting Wildfires Works [video] - <AUTHOR> https://www.youtube.com/watch?v=EodxubsO8EI <comment><USER2> I'm a structural firefighter and routinely spend time inside burning buildings. Wildland firefighters are _crazy_

"That mountain is on fire. Here's your shovel..."

<comment><USER3> I had an emergency response training with a firefighter today and he said they call regular firefighters "pavement divas". He said he would never trade with forest firefighters. Their work is just too hard.

<comment><USER4> Here's how I think of it wildland firefighting: it's just emergency landscape maintenance under the worst possible, potentially life threatening conditions.

[I'm a volunteer in a local rural area, at the last all-volunteer station in the state.]

[P.S. I missed closeparen's comment below. We think similarly]

</comment></comment></comment><comment><USER5> > Cal Fire

Unfortunately the general pilot shortage and the longer fire season is starting to impact Cal Fire, leaving a few airtanks grounded without pilots. These pilots traditionally worked on a seasonal schedule: ~four months of heavy firefighting with minimal time off, with the rest of the year spent recuperating (aka "unemployment"). Trying to extend the heavy-work period (or even make it year-round) is burning people out.

[https://www.youtube.com/watch?v=ZWf-H9vnBjY](https://www.youtube.com/watch?v=ZWf-H9vnBjY)

</comment><comment><USER6> It's striking how much fighting wars is "just" extreme construction, and fighting wildfires is "just" extreme landscaping.

</comment><comment><USER7> i feel like where i live, they don't fight wildfires, they just watch them burn and do structure protection.</comment>


If my startup makes it to a series A stage, am I rich personally? - <AUTHOR>

<comment><USER2> No, you're not rich personally. The money belongs to the company and any sane founder will put more money back into the company rather than taking substantial salaries.

You can upgrade from ramen to TV dinners though.

</comment><comment><USER3> Closing a VC round is meant to HELP your company take off, not settle. There's a very good reason why it's often referred to as "runway."

The number one motivating factor for startups and the reason why they're able to operate more efficiently than larger competitors boils down to one thing: desperation. Having limited resources makes you desperate and hungry. Besides, living in a cramped apartment and eating ramen is a good reminder of what you get when you don't win (and having a roof over your head ain't too bad).

Paying yourselves $300K when you guys probably don't have revenue is a great way to mislead your investors, create politics amongst employees, and, most of all, make you complacent.

Now, (mis)using investors' money to live the life isn't unheard of. I once interned at a company that basically lost hundreds of millions of dollars every year and addressed this by systematic studio closures and layoffs. The company's misfortunes resulted from poor oversight by the management team and had almost nothing to do with those being laid off (they all went on the be headhunted by competing firms). Following suit, every year, product-producing employees were let go while executives maintained their $400K salaries. The management team basically did whatever they could to keep the company alive while they drew as much salary as possible. Interestingly enough, this behavior actually began when they got funded in the late 1980s.

</comment><comment><USER4> On paper you're close to rich, in the sense that your stock in the company is worth a lot. But it's illiquid, and most of it may not legally be yours yet because of vesting. On the other hand, after a series A round you'll be able to pay yourself a decent salary-- maybe 1/2 or 2/3 of market rate, which will probably be a great improvement.

In a startup you generally want to make your salary as low as possible. You're not going to get rich from salary but from the company scoring, so why take money out of it?

</comment><comment><AUTHOR> Let's take Loopt as an example. Y combinator gives the founders $10,000. They code and live like animals for three months. Their hard work pays off... another VC gives them $5M.

At this point, do the founders still have to share a crappy 2 bedroom rental and eat ramen? Or, can they pay themselves $300K a year and use their salaries to put a down payment on a decent condo?

<comment><USER5> Rich is a subjective thing, but in a short answer: no.

You are not rich. The money comes with strings and it will almost certainly say what you can and cannot do with it. It is not your money, it is the companies money. The company which you no longer have full control over. As well, when and if a liquidity event occurs, conditions on the series A financing may have the VC's taking several times their listed percentage. On the chance that this doesn't happen and you go out of business, which you probably will if you give everyone a quarter million dollar salary and a cushy office downtown, the VC's will take several times their initial investment and this time... this time you get nothing.

VC funding is not an end. It is only a step. And it is a step that can, and in my mind should if possible, be skipped. Five million VC bucks in the bank isn't cash in your pocket, it's debt. Holding debt doesn't make you rich.

<comment><USER6> I beg to differ.

In the Bay Area, VCs expect and want the founder/CEO to make approximately $150K to $175K per year after the VC round (i.e. Seies A). I have confirmed this by asking VC panels here in Orange County during open-mike sessions.

What should be clearly understood is that you are actually financing a part of that compensation via your significant equity dilution that would result from the new vesting schedule put in place by the VC! You typically can't escape this new vesting if you want VC money...which is why PG's question about how much cash will you take to just walk away from it has real substance behind it.

<comment><USER7> Ok:

This seems useful, but I don't fully understand it. Are you saying that the VCs will force you to take a high salary, so that they can take a bigger chunk of your company?

<comment><USER8> No. They will not do that. No good VC would not force you to take a high salary if you would rather the money went into the business. They'd probably even like that. A founder should be setting the vision and culture of the company. Compensation is one piece of that culture. You set a precedent by taking a big salary and you set a message by taking a small one (i.e. Jet Blue - CEO, COO, CFO each have a base salary of $200,000 / turned down bonuses during bad years).

<comment><USER6> It's not a question of forcing. It's the norm. All other things being equal, why should someone take a lower salary?

And there are other factors. If your compensation becomes a benchmark for the rest of the team, now your company is in real trouble. You can't expect to hire key team members at less than the norm. It just won't happen. VCs know that.

Also, a VC's main job is to put out as much of their committed capital as possible into good deals. Allocating a large part of a preferred equity tranche to fund the maintenance and creation of a solid team is the right thing to do.

And comparing with large companies is not apples to apples. That's a different world; here's an extreme example of that world: <http://valleywag.com/tech/greed/the-grotesque-1-salary-251104.php>

</comment></comment></comment></comment></comment></comment><comment><USER9> Why do you ask such a question? Getting VC money is validation that what your working on has the potential to solve a really big problem. Depending upon th liquidation preferences the angel investors can cash out or retain a new class of share. Its still ramen and hard work until you a) build a super sustainable company (recurring revenue, cash, employees, scalability) or exit (being bought by another company, trade sale, IPO etc) Then you've made it as an entrepreneur...

</comment><comment><USER7> All -

This is an important question, and one that may have not been answered. To the people who say you can take a $150K salary: how sure are you? ($300K seems wildly excessive to me, as CEOs of 400M corporations don't make that much in salary, they usually get stocks + benefits to augment salary to the $500K range)

This would have been great to ask at startupschool.

</comment><comment><USER10> Not at all, let me tell you ;)

And if you care about the business, you won't take a $300k salary either.

</comment><comment><USER11> good question, most vc's will be ok with the CEO and a co-founders paying themselves $150k salary. They do not want you to starve and salaries are a component of every companies operating costs. $300k is a bit excessive. VC's love frugality.

So while you won't be rich, you will be able to upgrade from a 7-11 diet to Whole Foods.

<comment><USER2> Saying $300k is a bit excessive is like saying gas prices are only a bit excessive -- huge understatement. I don't know how plausible a $150k salary is after a Series A, but I can't imagine any good founder paying himself close to that amount.</comment></comment>


Apple to Build $1B Server Farm in North Carolina - <AUTHOR> http://www.charlotteobserver.com/597/story/820351.html

<comment><USER2> I'd love to hear other people's speculation as to what they're doing. I think that they're going to build a massive suite a cloud-based apps, potentially even offering things like your iTunes library wherever you are on the internet. And I wouldn't even be surprised if pro-level stuff like Final Cut & Soundbooth made its way to the cloud at some point.

It makes sense to me as there's a big overall shift in that direction. Thoughts?

</comment><comment><USER3> State of Georgia needs to do similarly.

<comment><USER4> Why? Data centers provide a small number of jobs and use enormous amounts of electricity. They gave Apple $46m to get 50 jobs that pay $50k a year. Do the math, Apple got essentially free labor for the next 18 years.

<comment><USER5> That's not quite correct. They didn't give Apple $46m. The $46m that they're "giving up" is money they would never have had otherwise. The town had 2 choices:

1) Don't give any tax break. Apple will likely go elsewhere, and the town doesn't get any additional tax revenue.

2) Give Apple a break on some fraction of their taxes, amounting to $46m. They will still get some tax revenue from Apple.

It's like saying a store is giving money when it puts a product on sale. The town is just lowering the price to sell more goods.</comment></comment></comment>


YouSendIt Raises $10 Million in Series B Round - <AUTHOR> http://startupmeme.com/2007/04/24/yousendit-raises-10-million-in-series-b-round/ <comment><USER2> What's the barrier to entry here? It looks easy to implement.

<comment><USER3> Yes, it's called FTP.

Remember that article about webifying unix commands? This is yet another example.

And they got $10m! The bubble is back!

<comment><USER4> YSI really is a good service - I use it all the time to send stuff to friends, or did before I switched to SendSpace. Many of my friends don't understand FTP, don't want to download a client, and just want to click on a link and get the file.

Only problem is they have basically no barriers to entry, so it'll be hard for them to ever become more than a commodity. If they're lucky, they may be able to make a tiny profit by charging or advertising just above their costs, but if they ever get decent margins they'll be swamped by the competition.

</comment></comment></comment><comment><USER5> What they need all that money for is beyond me. I guess VCs need to prop it up even more before they flip it.

<comment><USER6> Bandwidth and storage costs could easily get into the millions over a year or two.

</comment></comment><comment><USER7> Who would pay for file sharing? Who would invest $10 mil in something like this?

I've always wondered... if you raise millions through venture funding etc, are you allowed to just put it in your personal bank account?

<comment><USER8> I'm sure there are 50 million strings attached to this amount.</comment></comment>


Ask HN: Best way to create and send snail mail via an API? - <AUTHOR>

I'm working on a web app that is going to need to create and send mail via the USPS to various businesses and government agencies. I really, really want to outsource this part of the process. Anyone have any vendor ideas or suggestions? <comment><USER2> <http://postful.com/>

<http://click2mail.com/>

<http://www.viapost.com/>

<http://www.postalmethods.com/>

<http://www.cfhdocmail.com/>

<http://www.l-mail.com/>

<http://www.pc2paper.co.uk/>

</comment><comment><USER3> You need to clarify what is being mailed. Is it teddy bears or form letters?

Have you considered finding some "mom power" via Craigslist and hiring them for an hour a day?

</comment><comment><USER4> PostalMethods have great SOAP XML (and HTTP POST) Web Services which would make enable you to quickly complete the integration development and focus on your website.

The development is free including professional support and code samples.

Good luck. PostalMethods (<http://www.postalmethods.com/>)

</comment><comment><AUTHOR> Looks like Postful is what I am looking for, I still can't find it via Google, thanks oldgregg!</comment>


Lou's Pseudo 3d Page - <AUTHOR> http://www.gorenfeld.net/lou/pseudo/

<comment><USER2> I made a few games and demos on the C64 using this technique (switching colours every few raster lines). That part was easy to figure out. The hard bit to my 15-year old self was finding the foreshortening relationship. Through trial and error I finally settled on a lookup table calculated using 1/tan(z)... which as it happens is a good approximation of the true 1/z relation for small angles. Crazy...

</comment><comment><USER3> Has anyone seen an HTML5 canvas demo that uses these techniques?

</comment><comment><USER4> Really interesting. I'm curious if there are any iPhone car/racing games that use some of the road techniques described.

<comment><USER2> There's no need for that. The iPhone's PowerVR chip can push tens of millions of triangles per second (depending on the artificial benchmark used...). It's roughly comparable in capabilities to a Dreamcast (also PowerVR), and ten times better than a Nintendo DS.

<comment><USER5> From the article:

Why Pseudo 3d?

Now that every system can produce graphics consisting of a zillion polygons on the fly, why would you want to do a road the old way? Aren't polygons the exact same thing, only better? Well, no. It's true that polygons lead to less distortion, but it is the warping in these old engines that give the surreal, exhillerating sense of speed found in many pre-polygon games. Think of the view as being controlled by a camera. As you take a curve in a game which uses one of these engines, it seems to look around the curve. Then, as the road straightens, the view straightens. As you go over a blind curve, the camera would seem to peer down over the ridge. And, since these games do not use a traditional track format with perfect spatial relationships, it is possible to effortlessly create tracks large enough that the player can go at ridiculous speeds-- without worrying about an object appearing on the track faster than the player can possibly react since the physical reality of the game can easily be tailored to the gameplay style.

<comment><USER2> Pffft... sorry, that's very nostalgic and all, but if you really wanted non- realistic road effects, you'd still use polygons in any modern implementation. And I know what I'm talking about, I have used both systems.</comment></comment></comment></comment>


Oregon Proposes Investment Model For Student Loans - <AUTHOR> http://techcrunch.com/2013/07/07/move-over-peter-thiel-oregon-proposes-investment-model-for-student-loans/ <comment><USER2> No reporting on this idea ever discusses what appears to be a fatal flaw in the basic idea: there is still no incentive for universities to lower their costs. They can still charge as much as they want for an english degree and the state pays them for it up front. The public is on the hook for the bill when the english major fails to get a job.

EDIT:

Just wanted to add that this is the sort of brain-dead reporting that allowed the student loan industry to essentially socialize loan losses by not permitting students to default on student loans and by allowing the federal government to guarantee them, subsequently allowing education costs to sky- rocket.

<comment><USER3> The incentives are actually _worse_ than the student loan model, since the incentives to the student to major in something that makes money are now reduced.

</comment></comment><comment><USER4> This has a critical flaw: those expecting to work in a high-paying field will self-select more traditional loans, whereas those pursuing a degree with less promising income expectations will disproportionately opt for this type of loan.

If a university (or a state) chooses to force everyone to study under this model, they'll find that students expecting high-paying jobs will go elsewhere, and students expecting low-paying jobs will flock to those schools.

Fundamentally, if I'm planning to study CS for the next four years, it's a good bet that I'll be making more money than someone getting an English degree; and I don't particulalry want to subsidize their education with my future earnings.

There's a close parallel here with John Galt quitting his job in Atlas Shrugged.

<comment><USER5> This is the part I am always confused. If we all know graduates getting an engineering degree(CS,EE) make more money than graduates with english/arts degree. We should see an obvious trend students heading to engineering majors. Why still so many students go to english/arts/... major and they know they will make less promising income?

<comment><USER6> Same could be said of doing a MBA or medicine compared to STEM. Yet few people on HN made that choice.

<comment><USER7> Not even close RE: MBA. There is an insane glut of MBAs because of rational choice to go there where MBAs used to have a ton of opportunity. Then the economy crashed and now STEM fields are being mined for business intelligence / game theorists that can learn rudimentary business practices on the fly (or the company will pay for a night-time MBA).

<comment><USER8> The majority of people who struggle with getting high paying work after an MBA previously struggled with getting high paying work as a Stem graduate. Something like 40% of MBAs are engineers.

</comment></comment></comment></comment></comment><comment><USER9> I think education should be covered under the social contract ... "we'll give you a good education, you pay your taxes and pay off that huge debt we accumulated".

I'm not sure how we expect these next few generations to pay off their rapidly increasing student loans, deal with the massive debt we are leaving them with AND fund social security/medicad.

<comment><USER10> So they're not employable enough to cover their loans, but suddenly employable enough to boost tax revenues?

<comment><USER9> My point is that we can't keep loading them up with debt, both personal and institutional. I'm not sure what your point is.

</comment></comment></comment><comment><USER11> 1\. This s not a bad idea. 2\. Student loans should have zero interest. 3\. Don't take out student loans for any school that is for profit, or advertises on T.V.. 4\. Remember student loans are not bankruptable. 5\. Your interests will change as you age. 6\. If you can swing it, get a bachelor's degree. 7\. I despised "networking". I made friends with people I truely liked. Well, I'm paying for it now. I hate to say this, but force youself to be friends with "people of means". I know they have the personalities of drift wood. 8\. With the right direction; I feel an ambitious student could lean what they need off the Internet. 9\. If you do make a lot of money in your life--Remember what it was like to have nothing. 10\. Oh, yea--really think about marriage. I'm not sure it's necessary anymore.

</comment><comment><USER12> This betrays the true views of government with regards to education. Government's true goal is to add additional taxes on high earners for the rest of their careers to capture the premium they earn due to being the best and brightest. It would seem the goal is to marginalize the value of work. The only thing this is going to accomplish is to remove the incentive to study and move into advanced careers. If Oregon wants to put an additional income tax on college graduates, I suggest they think about what this will do to their graduation numbers. If anything, they should be giving tax breaks to college graduates.

</comment><comment><USER13> How is this different from indentured servitude? In any way what so ever?

"Free trip to the colonies, in exchange for a chunk of your output for the next 20 years."

<comment><USER14> > How is this different from indentured servitude?

If the state raised a 2% income tax on everyone to pay for free college education, instead of a 3% income tax on students getting a free college education, would that also be indentured servitude? Are all taxpayers indentured servants of the state?

<comment><USER13> You can leave taxes behind by moving / etc. You won't be allowed to leave this behind in any sense.

</comment></comment></comment><comment><USER15> One nice thing about this is it would seem to more directly incentivize state universities to provide a curriculum that maximizes student earning potential; I think that's a great thing especially for people who've chosen their fields for reasons other than money. 25 years is a somewhat scary number, but this very exciting.

</comment><comment><USER16> I propose different model. Either you'll pay for my education to become engineer who'll pimp up your self-driving flying car, or I'll become uneducated mugger who'll beat you up and steal your stuff or I'll become uneducated cop who'll beat you up and shoot your dog for not respecting my authorita.

</comment><comment><USER17> The thing with investment model is that VCs filter their applicants very carefully before investing. Rejecting many applicants that may seem and indeed later prove very worthy, but are not to the particular VCs liking. With higher ed today, anybody with a technically functioning brain can go into higher ed institution and get a paper saying "degree in whatever" on it. Investment can not work this way - in order to invest, one needs to select and reject. Current policy would aggressively resist the idea of selection - and indeed, how would you select high school students by their future earning potential? Nobody can do that with any degree of accuracy or any appearance of fairness and basic dignity. Without selection, however, the whole model would become uneconomical unless the sums charged are raised significantly. Free is very powerful attractor - so the number of people wanting to use it would explode.

</comment><comment><USER18> This is a brilliant approach! I'm sure it will look nothing like this by the time it comes for a vote on the house floor. Will probably have an anti- abortion rider and a lifetime payment cap by the time the lobbyists are done with it...

<comment><USER19> They already voted - "The plan passed unanimously in Oregon's Senate on Monday and in the House the previous week. The state's Higher Education Coordinating Commission will next develop a pilot program and in 2015 lawmakers will decide whether to implement the program."

[http://abcnews.go.com/Business/oregon-legislature- approves-t...](http://abcnews.go.com/Business/oregon-legislature-approves- tuition-free-college-pilot-program/story?id=19577994#.UdnVy2RAR3Y)

<comment><USER18> Thanks for the update. I'm really glad this passed!</comment></comment></comment>


RCMP arrest 'money mules' tied to scam calls from India - <AUTHOR> https://www.cbc.ca/news/canada/toronto/rcmp-cra-telephone-scam-fraud-investigation-1.5463838 <comment><USER2> Thanks you CBC Marketplace for getting the RCMP to finally do something.

Marketplace has been exposing these scam companies for years. They even traced their location in India multiple times.

Canada needs to secure our telephone systems. It is way too easy for a scammer to get a Canadian VOIP number or to spoof phone numbers. Scam calls lately are have been spoofing my number to call me.

<comment><USER3> CBC is Canada's publicly funded TV and radio news - [https://en.wikipedia.org/wiki/Canadian_Broadcasting_Corporat...](https://en.wikipedia.org/wiki/Canadian_Broadcasting_Corporation)

</comment></comment><comment><USER4> How about putting a small tariff on every phone call originating from countries that do not shut down these fraudulent call centers? The tariff perhaps could be as small as 2 or 10 cents per call to make these operations unprofitable. I'm sure that the telecom operators in the foreign country could easily track down (or already know precisely where to find) the call centers. Once the fraud falls below a threshold the tariff can be removed.

Punitive tariffs, quotas, bans get applied to every kind of product -- counterfeits, contaminated foods, polluting vehicles. I never heard any government agency suggest applying it to countries that are the overwhelming source of scam calls.

<comment><USER5> It may be a surprise to the HN "incentives are the only way to do anything" crowd, but there simply is not an incentive structure that will fix this problem, because nobody knows where the calls are coming from. Not the US, not the telcos, not the countries the calls are coming from, _nobody_. You can place the tariff on countries, and then the countries just have to accept the tariff because there's not a damn thing they can do about it as long as scammers can spoof phone numbers.

The converse of this is that it's pretty ridiculous to assume that countries have scammers in them because they're just tolerating them.

Sure, we could rush out a technical solution, but then it would run the risk of being broken rather quickly, and further it's important to not compromise the reliability of the phone system. Too many critical services rely on it. It's worth taking the time to do it right.

Last I heard, the FCC was in talks with telcos to finalize a solution, but I would expect it to take at least another year to implement and deploy it.

Until then, I guess we'll all have to deal with annoying scammers and comments by people who don't understand why spoofing makes their pet incentive idea irrelevant.

<comment><USER6> It's not right, that a sensible comment like yours is being downvoted. Spoofing is real, and not easy to track down depending on the resources you have at your disposal. And Indian law enforcement is certainly behind the western world in that regard.

Besides, it's not like these scammers are paying taxes to the Indian government, so they don't have any national incentive to facilitate scammers. Tax compliance in countries like India, outside the first world, is very poor. Though the article mentions that Indian authorities are cooperating with Canadian officials, it needs to be understood that this cooperation isn't based on any incentive structure, other than civilised societies need to crack down on crime. Crime in Canada is a low priority for Indian officials, just like I'm sure it's the other way around.

Finally, Canada doesn't even feature in the top 15-20 trading partners for India, last time I checked, so I don't know what punitive incentive can be hoped for here. If you need a solution, it would be more productive to approach from a more pragmatic, cooperative point of view, rather than being all high and mighty and taking a carpet bombing style approach that affects legitimate business as well. Or, you could do that but it wouldn't even matter.

Edit: I'd like to add that every day there is news about people, here in India also losing their life savings to these scammers. So it would be wrong to have an impression that authorities and citizens of this country take pleasure in people from richer countries being scammed. I've old, not so tech savvy parents myself, who I realise are pretty vulnerable to this evil.

<comment><USER7> > Spoofing is real, and not easy to track down depending on the resources you > have at your disposal

Mmm, but some Canadian or American legal entity is bridging these onto the phone network, and needs to be doing its due diligence better.

<comment><USER8> The problem is that the way the phone system is currently set up, it is _not possible_ to do this due diligence. That is what's being worked on.

<comment><USER9> This is mostly true, but it would be worked on a lot harder if the companies involved had a financial incentive to work on it. Currently the scammers pay their bills and the incentives work the other way - it's best for them to say they are working on it but drag their feet.

<comment><USER5> You think "people are switching away from using the traditional phone system entirely" isn't enough incentive? And how, exactly, does an Indian scammer paying a bill to an Indian telco incentivize US telcos to drag their feet? You can blame the Indian telcos, but they also don't have incentives to tolerate scammers--their business would benefit a lot more if calls from Indian numbers weren't automatically assumed to be scams.

While you don't understand the problem, you can't possibly have anything of value to say about the solution.

There may well be perverse incentives causing certain entities to tolerate scammers, but we shouldn't pretend we know what those perverse incentives are when we can't even trace the calls. On the other hand, it is much more likely that once the spoofing problem is solved, the incentives are all already in place and the vast majority of scam calls will be solved.

If a rational person only knows how to use a hammer, they pause when they come across a problem that isn't a nail. But when the HN crowd comes across a problem that isn't immediately solved by incentives, they argue that the people who actually are qualified to solve the problem with other tools, should be using incentives!

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> I get 2-3 calls like these every week. It's getting really bad.

<comment><USER11> Its doubly frustrating for me because I'm on a kidney transplant list and there is a small change I might get a call out of the blue even thought there is still some wait time. So I end up answering the phone most of the time...

<comment><USER12> Pick up the phone and stay silent until they speak. It should also help reduce incidence of scam calls.

</comment></comment></comment><comment><USER13> > _" "We have disrupted the necessary flow of money from Canada to India, > which will have a big impact on the operation and bottom line of scammers," > Ogden said Friday, in announcing the charges."_

Perhaps so, but to what extent and for how long? How many other mules are there, and how long will it take them to find replacement mules to replace those arrested?

I hope they throw the book at the mules, but I don't expect this to be a real solution to the problem.

<comment><USER14> It seems like a small story about a small bust, but if you keep reading the story keeps going. They are directly going after the scammers too.

> "Police have since worked with Indian authorities to carry out a flurry of > raids against suspected illegal call centres in the country. Canadian > officials said Friday they know of 39 call centres, in the New Delhi and > Noida area, that have been shut down.

"Ogden said still others will face police scrutiny and that he anticipates more arrests and charges "in the next few weeks."

<comment><USER13> Yeah, but is 39 call centers a lot, or just the tip of the iceberg? It wouldn't really surprise me if there were hundreds of these companies, but I don't know.

<comment><USER14> Probably hundreds of them at least. But there may be only a smaller fraction of them targeting Canada.

</comment></comment></comment></comment><comment><USER15> Now hoping they put an end to duct cleaning services calls. Another scam. I get 10 of those a week.

<comment><USER16> Marketplace actually did a video about the air duct cleaning service scam a while back: [https://www.youtube.com/watch?v=O13Vv4n__J8](https://www.youtube.com/watch?v=O13Vv4n__J8)

It's really good, and they traced it all the way back to the call center (with an insider)! But of course, no one was arrested. Sadly, I don't think the punishment will fit how much annoyance and time wasted.

</comment></comment><comment><USER17> Good for the Canadian cops! Tax money well spent.

</comment><comment><USER18> So the dude had a regular job so it doesn't seem like a kingpin of any kind. They've been tracking him for months, but they decided to take him down once he arrives for work, because ???

His wife is wanted too, but instead of going to where she is, they just call her and ask her to turn herself in?

By publicizing the arrest, the police likely killed their change to get the mule to lead to higher-up takedowns, no? Or have the police completely given up on shutting down the overseas operations?

<comment><USER19> That made me laugh, "unmarked vehicles tailed him, switching positions to avoid detection". Knowing Toronto drivers, I wouldn't be suspicious at all if someone tailgated me all the way to work.

<comment><USER20> The best part is after the police got done playing James Bond the couple was released under their own recognizance.

</comment></comment></comment><comment><USER21> i stopped answering my phone a long time ago, if someone really needs to contact me they can text, email (no guarantee on that though), or hit me up on discord, no spam there</comment>