Efnet klines all Hetzner netblocks - <AUTHOR> http://forum.efnet.org/viewtopic.php?t=5866 <comment><USER2> "One of our EFnet operators located a server that a client was using, the server was most likely hacked and/or used for illegal activities." -- so they contacted the ISP and the ISP sent their request to whoever owns the box.

That sounds entirely reasonable to me. Hetzner has no idea whether or not the box owner is the suspected hacker (even EFnet assumed the server was hacked) in the same way that EFnet has no idea about whether an Hetzner employee was the suspected hacker. So three possible outcomes: (a) the box was hacked, so sending said info to the box owner was not a bad idea, (b) the box wasn't hacked, it was the box owner himself doing bad things, in which case Hetzner just gave the box owner personal information about his victim, or (c) the box wasn't hacked, and it's a Hetzner employee doing bad things, in which case EFnet just gave the employee personal information about the victim.

So, exactly why are they blaming Hetzner?

<comment><USER3> The issue is that Hetzner passed on personal information. It's a breach of trust.

<comment><USER2> You're missing my point though.

The operator passed on personal information without knowing if a Hetzner employee might be the bad guy. Hetzner passed on personal information without knowing the server owner might be the bad guy.

If the operator had contacted the server owner directly to let him know his box was hacked, the result would have been the same.

Why did the operator have the expectation that an uplink of the server wouldn't just forward the mail to the server owner?

<comment><USER3> Because Hetzner is an award winning business who sells professional hosting solutions. You'd have a point if the company in question was some dodgy garage operation, but Hetzner isn't.

If EFNet are going to report the issue then there has to be a trust worthy contact at some point along the chain of network ownership, and Hetzner _should_ have been that point. Quite frankly, it's irresponsible for a company of that size to behave in that way.

<comment><USER4> What would Efnet lose by redacting the name of the operator themselves before doing it? They still show timestamped logs, and [operator redacted]@ef.net would be enough to note that an operator reported the issue.

If the log included chat between the malicious user and the operator, the malicious user __already knows__ the operator's nick, so there's no additional information. If the log doesn't include that, then what reason is there to include the nickname of the operator?

Rather than expecting Someone Else to sanitize our information (which fields do you feel are critical to redact? real name? phone number? IP? zodiac sign? Made-up-nickname?), it seems like it's a good idea to proactively redact the information ourself before making that abuse report.

<comment><USER5> The operator is the one that sent the email. Who are you suggesting should have redacted his name before transmitting it? Magic fairies in the SMTP servers?

</comment></comment></comment></comment></comment></comment><comment><USER6> _Unfortunately, the past few days many EFnet servers (and more are following) have had to ban an entire ISP, which has not happened in over a decade, if not longer. Naturally, something extreme must happen for this to be even considered._ [... and the extreme thing is ...] _the email also contained sensitive information about who this operator was, including nicknames_

This is ridiculous. Why would an IRC op want to keep his/her nickname from becoming public? On IRC, even IP addresses are public. Hetzners reaction seems entirely reasonable to me, especially if the server in question was "mots likely hacked".

<comment><USER5> > _Why would an IRC op want to keep his/her nickname from becoming public?_

That isn't what they said.

> _On IRC, even IP addresses are public._

This may still be true on efnet. It has ceased to be true on many IRC networks. And even where it is, VPNs, shell accounts, tor, and similar methods are readily available to make the IP address worthless.

> _Hetzners reaction seems entirely reasonable to me_

Please tell us where you work so we can all be certain never to report any sort of abuse to your employer non-anonymously.

<comment><USER7> > That isn't what they said.

How not? The forum seems to be down now but the announcement heavily implied that all that was "leaked" was the nick name of an operator, which they claimed could somehow be used to deduce the real name and address.

<comment><USER5> The problem is not the public knowledge of a nick, but the information that the person using that nick made the complaint. It paints a target on a person whose nick is very often publicly associated with a real identity.

</comment></comment></comment></comment><comment><USER8> I have reported spammers/phishers to Hetzner in the past and experienced the same: Hetzner's default policy is to forward a complaint to the server's owner - which also kind of surprised and annoyed me. On the phone, support staff told me that Hetzner sees itself just as an uninvolved messenger between both parties. Apparently, their support ticket system automatically forwards all complaints to the server's owner without any way to opt out. The support person offered two alternatives: send anonymous complaints through a freemail service, or send the complaint to the personal address of a support team member, so that they can manually enter it into the system. Yes, this is pretty annoying.

<comment><USER9> As a Hetzner customer I think this is more than fair. If someone reports abuse from my server, hetzner should forward me the report. They do not have access to the server, so why in the world would they do anything but forwarding it to the person or company that does in fact have access?

Protip: Don't put your credit card number in the abuse report. Just put the logs or whatever is required to prove that there was in fact abuse from that server.

<comment><USER10> The problem is that if you have someone using Hetzner's network for spamming or other illegal activities, you'd expect the ISP to want to keep their network clean of these sorts of things and investigate. Instead, they just say 'whatever, not our problem'.

On top of that, though, forwarding the complaint to the server owner just makes a mess of things, because now the server owner can target you and make your life hell. They can send you threats, DDoS your mail system, flood your inbox, etc., all the while knowing that Hetzner has their back.

It's like if you saw someone assaulting someone in an alley and called the police, and the police took the information you gave them and gave it to the person who assaulted them. Now they know who you are, and they can come after you too. Now your only real solution is to just not report it when someone does bad things, because you know it's not going to get fixed and it's just likely to cause problems for you down the road.

<comment><USER11> Well, Hetzner does not state it in their RIPE record ([https://apps.db.ripe.net/search/query.html?searchtext=5.9.12...](https://apps.db.ripe.net/search/query.html?searchtext=18.104.22.168&flags=&sources=RIPE_NCC&grssources=&inverse=&types=#resultsAnchor)) that the email is NOT handled by Hetzner staff. In contrast, Manitu (another German hoster) explicitly states this: [https://apps.db.ripe.net/search/query.html?searchtext=217.11...](https://apps.db.ripe.net/search/query.html?searchtext=220.127.116.11&searchSubmit=search#resultsAnchor#resultsAnchor#resultsAnchor)

</comment></comment></comment></comment><comment><USER12> > Unfortunately, according to trusted sources (ex-employees) of Hetzner.de, > this is policy and not an exception. They have realized they can save money > (by limiting attacks) by redirecting the attacks back at the person > reporting them. That way, the hacker/cracker/kiddie using their services > will not cancel their contract with Hetzner, and in return Hetzner will > remain protected.

I don't think that this has to do with Hetzner needing criminal business but rather with Hetzner not wanting to shut down an entire server if a part of it has been breached. Forwarding that complaint in it's entirety is definitely not best practice however making such allegations is neither.

<comment><USER13> That was roughly my take away. Hetzner looks really bad - but the explanation that they are incompetent and lazy sounds more likely than the criminal explanation.

And EFnet looks wronged. But also looks bad for spreading allegations against Hetzner of profiteering from criminals without much more substantial backing.

Sticking to the facts of the situation would have produced a more powerful, and damning condemnation.

<comment><USER14> This isn't court, I think it's reasonable to forgive humanity entering into the issue. Besides, this appears to be a citizenship issue, so banishment also comes as no surprise.

</comment></comment></comment><comment><USER15> That announcement should have clarified whether the communication they sent to Hetzner explicitly requested confidentiality. If not, the incident is as much Efnets's fuckup as Hetzner's. Why did it even need to contain such sensitive personal information about the sysop in the first place?

<comment><USER16> Even if their initial email requested it, wouldn't you assume that a large provider like Hetzner has at least partially automated their abuse handling? I wouldn't count on a human actually reading it before it gets forwarded to the customer.

</comment></comment><comment><USER17> "This has worked very well due to our personal involvement with a lot of said organizations. If we find an abuser on IRC, we try to not only ban him or her, but also to contact the provider so that the problem is handled at the right end, often with the involvement of law enforcement, as was the case with Kevin Mitnick, t0rn and a lot of other well publicized hackers/crackers."

I'm not sure that is something to be proud of.

<comment><USER3> Of course it is. If someone cost you time and money and severely harassed users of a service you're offering by illegally attacking your servers, then I bet you'd be all for reporting them as well.

The problem with script kiddies is that they're too lazy to create anything of their own and thus cannot emphasis with how hard it is to set up and maintain a free public service. So they don't have any second thought about destroying other peoples hard work. Plus the pseudo-anonymity of being online and the ability to not look your victims in the eye make such crimes easy for even some of the more ethical kids to shrug off.

The only way to have an open internet where everyone is free to create and contribute is to rat out those who seek to destroy it. People like the aforementioned might enjoy all the perks of an open internet, but their actions have the opposite effect.

So I'm not only in favour of reporting abusers, but have actually reported attacks on my own servers to their respective ISPs.

</comment></comment><comment><USER18> God forbid we should mildly redesign the irc semantics so that splits don't allow you to take over channels or collide clients off.

I mean it's only been a big enough problem for 20 years now that you can't even host an ircd on most standard hosting contracts.

<comment><USER19> Efnet has had chanfix for quite awhile now, which makes taking over channels from a split much harder, if not impossible.

<comment><USER18> Really? Hmm. It has been 5+ years for me, my bad. But what's the point of the ddos's then? I see netflow graphs of huge attacks on major efnet servers on a regular basis.

<comment><USER19> I'm honestly not sure why people still DDOS servers these days. Maybe just fun and games, it is EFnet after all.

Not too long ago there was an ircd exploit that killed servers and split 100% of efnet, which had never happened before. Not to mention its down 50% of its user base from a few years ago. Tough times for efnet.

</comment></comment></comment></comment><comment><USER7> This seems like a ridiculous overreaction to me. Not only do I not see much wrong with an ISP forwarding abuse e-mails to the admin of the hacked server (who is probably a victim too), but I also find a bit hard to believe that the nickname of an operator is enough to "derive a home address".

<comment><USER20> you'd be surprised

as an operator of a large IRC network I am forced to keep my real name off my employer's websites, websites like github and my home address out of the public record (director's addresses and such like)

it's a major nuisance

<comment><USER21> Here is an idea: use different nicknames for different things then you wont have to live in a self prescribed virtual prison

</comment></comment></comment><comment><USER11> Uhhh... that's bad. Real bad, for both sides.

I can totally understand Hetzner for just forwarding abuse complaints to the client (for root servers, the hoster usually has no "emergency ssh keys"), so the faster the original owner of the server can boot out the hacker, the better. At least it's better than disconnecting the customer from the internet entirely, especially as "haxx0ring" a server is damn easy these days, given the numbers of aged Wordpress installs alone. Also, a server owner who knows his server can support me as a hacking victim better than the hoster support who often knows nothing about configuration details, OS, disk encryption etc. on the server.

But I also understand EFNet, that their emails got blindly forwarded is bad, too...

<comment><USER22> > I can totally understand Hetzner for just forwarding abuse complaints to the > client (for root servers, the hoster usually has no "emergency ssh keys"), > so the faster the original owner of the server can boot out the hacker, the > better.

Removing confidential information from such an email should take ~2min, I think that's time well-spent, especially given that email per se is not a real-time medium.

<comment><USER11> I guess their automated forward system regex-greps the IP out of the complaint email and then forwards the mail to the applicable customer(s), so this system actually _is_ realtime.

Also, it places the burden of dealing with spam on the customer, so that the hoster doesn't have to do spam-filtering.

</comment></comment></comment><comment><USER23>
        "[...] someone at Hetzner chose to forward
        this complaint to the actual abuser him/herself. [...]
        Unfortunately, according to trusted sources
        (ex-employees) of Hetzner.de, this is policy and not an
        exception."

I really hope this is not true.

In 2011 there started to appear pornography when I searched for my name in image search. The reason was that a stackoverflow.com scraper showed my answers (which I post under my real name) but my profile picture replaced with porn. I have no idea why he replaced the profile pictures in the first place, but anyway.

The scraper site was hosted at Hetzner. I phoned Hetzner. They told me to write to email@example.com, which I did (in German). I received an auto-reply but nothing else happened. I tried to reach their phone support (09831 610061) several times during their business hours (Mo-Fr 7:30-18:00 Uhr) but no one picked up. I wrote several other mails to Hetzner but never received another reply.

After about seven months the scraper went down but I have no idea if it had something to do with my complaints because I never received any feedback from Hetzner.

I have know Idea who was behind the site. They could have found out about me anyway because I posted this publicly on meta.stackoverflow [1], but still: The thought that they might have learned about my identity through Hetzner is discomforting.

[1] [http://meta.stackoverflow.com/questions/81872/copycat- site-c...](http://meta.stackoverflow.com/questions/81872/copycat-site-causes- disturbing-images-to-turn-up-in-image-search)

</comment><comment><USER24> Can somebody tell me, what "kline" means? I never heard that word and dont find a dictionary entry.

<comment><USER25> I was just musing that the only word in this headline recognizable to someone outside this small subset of the tech world is "all", and yet it makes perfect sense if you know all the words.

<comment><USER26> Happened to me. Incomprehension is the reason I clicked the link.

</comment></comment></comment><comment><USER27> The article doesn't seem to mention if the sensitive information from the email was marked as such.

<comment><USER28> Why would it need to be? Surely Hetzner and the like would be familiar with how sensitive it could be.

<comment><USER7> If you consider nicknames sensitive you are gonna have to mention that, because a lot of people wouldn't.

<comment><USER28> Hetzner, as a hosting provider, would likely be well aware of the workings of IRC networks, so I doubt that.

</comment></comment></comment></comment><comment><USER29> Doesn't explain why efnet themselves are not at fault for failing to redact the details if they are so concerned. What if the attacker was Hetzner staff?

<comment><USER30> Should we perhaps have sent the request through anonymized pidgeon? When you send an e-mail to someone you can find out quite a lot of information from headers, from a nick or a given name.

When contacting ISPs some people attach contact information so that the ISP can request more information, maybe even make a call to verify identity and discuss the matter to help resolve it.

This doesn't mean that the information is intended for the abuser himself. I'd expect the ISP to send anonymized information/questions to the owner of said service, and not just forward "everything" (especially without discussion with the reporting party).

Reporting DDoS and abusers risks putting a huge target on yourself, your company, your servers, etc.

That is what the issue is about.

<comment><USER29> I specified redacting the details, i.e. the irc nickname.

If the information within the headers is that sensitive, the headers should probably not be forwarded from efnet to hetzner. At its most basic their servers are attacking efnets and so should be considered hostile.

By all means pass on contact information to resolve amicably - but don't leave sensitive information.

There's no reason to pass on irc nicks or sensitive email addresses - what use are they to hetzner? I have the same expectation of efnet as you have for the ISP.

If the issue is that efnet is being identified as the reporter to the rogue attacker, then that is not what is stated in the efnet admin's text.

<comment><USER30> EFnet didn't pass anything on. EFnet reported abuse, and the EFnet reporting staff members information was the information that was leaked/forwarded to the abuser. Not a third party to whom EFnet acted proxy.

You seem to misunderstand the situation.

</comment></comment></comment></comment><comment><USER16> Are there any actual standards for how abuse reports should be handled by service providers? What Hetzner is doing here appears to be pretty reasonable to me (it matches what companies like Level 3 and nLayer do).

I can understand why you might not want sensitive email forwarded to the abuser, but why would you send that information in your initial complaint? For all you know, the person you're reporting to is the abuser.

</comment><comment><USER31> This posts makes me trust more in Hetzner as a provider than the other way around.

I know that if there is any problem, they will forward the problem to me as soon as possible, and they are not going to take the law into their own.

</comment><comment><USER32> I got an abuse mail from Hetzner once (they mistyped my ip).

The original complaint was something autodetected by their own system, mailed to themselves. The original complaint was attached, header and all. Something about malware on an IP similar to mine.

Also, when will this be in effect, the server i tested from had no problems connecting.

<comment><USER33> I had the exact same email last week .-.

</comment></comment><comment><USER34> Full text:

Posted on behalf of Silence, EFnet admin:

Dear users,

EFnet has always been a network that promotes freedom of speech. One of the core pillars of a free virtual society is trust. Trust not only amongst ourselves internally, but an undying trust in the companies that allow their users to connect to our wonderful network. We have survived over two decades, in a world that is increasingly image- and video-based. IRC can offer neither of those. IRC is based on ideas. Ideas that are exchanged in text. With text, as opposed to images and videos, one has to be put extra effort into the subliminal, the meaning, the message. This has been our catcher in the rye, and we intend to protect this content-based communication form, for as long as it is appreciated by the hundreds of thousands who every day turn to IRC for philosophical debates, dating and just about anything you can think of (I'm sure a lot of the things in that last category does not belong here in this text, but you get the picture!).

We rely solely at the goodwill of others, as is the case with most things worth saving. There is no money to be made. We all do this for free. Sure, some companies might have benefited from a small level of advertisement, attracting customers to their products. But all in all, it has mostly been an uphill battle against enormous attacks, sometimes exceeding 75Gbps of DDoS. This has made it impossible for all but the largest organizations to host a server on our network, or any other large virtual society. We are Don Quijote and the weather mills are often winning.

One of our key strategies is to preserve a close relationship with the major Internet- and Hosting Service Providers, as those are the networks that our users connect through. This has worked very well due to our personal involvement with a lot of said organizations. If we find an abuser on IRC, we try to not only ban him or her, but also to contact the provider so that the problem is handled at the right end, often with the involvement of law enforcement, as was the case with Kevin Mitnick, t0rn and a lot of other well publicized hackers/crackers.

Unfortunately, the past few days many EFnet servers (and more are following) have had to ban an entire ISP, which has not happened in over a decade, if not longer. Naturally, something extreme must happen for this to be even considered. Almost always can we find a solution through the use of good old fashioned communication. Alas, not in this case. Well, here is the story (to the best of my knowledge):

One of our EFnet operators located a server that a client was using, the server was most likely hacked and/or used for illegal activities. As IRC is often a playground for these people to use, before moving on to more serious targets (where they can make money through extortion), we take this extremely seriously. Because of the serious nature of this, our operator sent an email to Hetzner.de, a German hosting provider, to help them lower the abuse of their servers, as well as ours. This is usually a fruitful symbiotic relationships, where both parties stand to gain.

However, the big difference between this case and all the other thousands of cases we have handled in the past, is that someone at Hetzner chose to forward this complaint to the actual abuser him/herself. This might seem fair enough, as anyone accused should be granted the right to defend him- or herself. However, the email also contained sensitive information about who this operator was, including nicknames (from which names can be derived, and thus, also, home addresses). We know what an impact this can have on your social, not to mention your professional life. We have seen people lose their jobs, after constant attacks and we have also seen companies lose money that is hard to fathom, considering this is still just a simple chat for friends. This is a fundamental breach of that mutual trust that has allowed us to accept clients from Hetzner to use our network - free of charge, just like we do with anyone else wanting to connect.

This a give and take network, where mutual trust is vital for our survival. We are maintained by the community, and we exist solely for the community. Hetzner.de has broken one of the most fundamental aspects of any report of criminal activity or suspicion thereof; source protection.

I expect us to get attacked now, which will result in a lot of work for the company kind enough to donate money and time to continue to provide us with servers, in an era where almost everything else would be more profitable. But this is an ideological problem, more than a financial one. We have been attacked before, and we will again. We are prepared. But these preparations rely on the fact that we know who the enemy is. Hetzner.de has made that impossible.

As a result of this, we have decided to ban all Hetzner IP ranges (both IPv4 and IPv6) from our servers. It seems other networks are following, and I know QuakeNet has published a similar statement. We simply do not want anything to do with a company that values money over source protection and integrity. Some may argue that this was a one time mistake, and that we should not jump to conclusions so fast. Could this have been a mistake? Sure. Does it matter, given the consequences this could have had for this operator's personal life and health? No. We do not appreciate cowards that would rather see someone else hurt, than take their responsibility.

Unfortunately, according to trusted sources (ex-employees) of Hetzner.de, this is policy and not an exception. They have realized they can save money (by limiting attacks) by redirecting the attacks back at the person reporting them. That way, the hacker/cracker/kiddie using their services will not cancel their contract with Hetzner, and in return Hetzner will remain protected. Left are those of us that work for free, and who will continue to do so, for as long as there are honest, reliable companies out there, willing to go the extra mile to protect the freedom of the Internet, and, above all, freedom of press and source protection.

Questions on this matter must be directed to Hetzner.de, as our involvement in this situation is over. This has been their decision based on questionable methods. It is unfortunate for them that they got caught, but it is good for the sake of the free Internet.

Sincerely yours,

Johan Boger, on behalf of EFnet and anyone else believing in integrity, source protection and a free Internet.

<comment><USER35> > chose to forward this complaint

> ...

> the email also contained sensitive information about who this operator was

> ...

> This is a fundamental breach of that mutual trust

> ...

>Hetzner.de has broken one of the most fundamental aspects of any report of criminal activity or suspicion thereof; source protection.

Excuse me? How is this in any way Hetzner's problem? The only "fundamental breach" of trust I can see here is the one that occurred when efnet gave "sensitive information" on its own operators to a third party at all. It sounds to me like efnet is the one in need of a lesson on "source protection." This reads more like a "we screwed up bad and are about to divert blame as hard as we can" letter than anything else. But I'm more than ready to listen to any further context that can be given to this.

<comment><USER36> For abuse reports to be taken seriously you need to provide timestamped logs and legitimate real world contact details, in exchange there is the expectation that reports are not forwarded in an unsanitizied fashion to end users. (I worked an abuse desk for a few years)

<comment><USER31> The problem is that if you have a problem and want to solve that problem, the first thing you do is talking with the person.

Instead of trying to fix this like normal persons, you want others to work for you by free.

Who gives you the role of a judge in this case, to even consider that the actions from that ip where illegal.

If they were illegal why don't sue? If you ask a lawer the first thing he will tell you will be to talk with the other parties before starting legal actions.

<comment><USER36> I really hate to use this analogy, but consider abuse desks the police of the Internet for a second.

Your local ops team notices a lot of SSH break-in attempts coming from Sprint's network (for example). They forward the logs on to the abuse team, who reach out to the abuse team at Sprint. In the same way that a cross jurisdiction investigation would be handled by two police departments working together, the two abuse teams will work together to investigate and remediate the problem.

Now imagine if the Seattle Police Department contacted the Chicago PD about an ongoing investigation of a jewelry heist, and the Chicago PD says "we are too busy to deal with this" and forwarded it on to the thieves so they could respond directly and help the Seattle PD with their investigation... Now the investigating officer is compromised and at risk. Sure, he was a known as a cop to the bad guys before, but now his enforcement actions have made him a direct target.

This is a system that has worked for 20+ years. We have our own mailing lists, meetings and conferences, heck even a private direct dial phone system.

<comment><USER27> Except that the communication between police departments is clearly marked or known (because of various regulations/laws) to be confidential. Here it's not clear (as I've also mentioned in a previous comment [1]).

[1] <https://news.ycombinator.com/item?id=5518161>

</comment></comment></comment></comment></comment></comment><comment><USER11> I do see why EFnet makes a drama out of this situation... check out the RIPE entry for one of their IPs: [https://apps.db.ripe.net/search/query.html?searchtext=5.9.12...](https://apps.db.ripe.net/search/query.html?searchtext=18.104.22.168&flags=&sources=RIPE_NCC&grssources=&inverse=&types=#resultsAnchor)

They do not mention that these emails get redirected to customer!

</comment><comment><USER37> Hetzner offer the cheapest dedicated servers with pretty hefty resources. Hence the invitation for abuse.

</comment><comment><USER38> Nice to see efnet retaining some of its old magic :)

</comment><comment><USER39> This sounds like whining on the part of efnet...</comment>


ACH File Parser - <AUTHOR> Do you know of any open source ach file parser? <comment><USER2> Just write one. It isn't difficult.

[http://www.osc.nc.gov/secp/Bank_of_America_NACHA_File_Specs....](http://www.osc.nc.gov/secp/Bank_of_America_NACHA_File_Specs.pdf)

</comment><comment><USER3> Parser? Or viewer? [http://sourceforge.net/projects/achviewer/](http://sourceforge.net/projects/achviewer/)</comment>


Ask HN: Windows Laptops with Good Keyboards? - <AUTHOR> I'm looking for an ultrabook with a good keyboard, but I can't find one. Apparently every company has copied Apple and reduced the key travel on their keyboards in favour of thinner devices (which I hate).<p>As a programmer, I _need_ a good keyboard, but the only ones I can find are on gaming notebooks, which are too heavy for me to carry around in college. Any recommendations? <comment><USER2> Worth considering Lenovo Thinkpad - can be pricey, but you know, you don't have to buy brand new! I recently purchased a refurbished T460s (1080p, 6th gen i7, 20Gb RAM, 512Gb M2) for about USD 700. It's a complete typing pleasure to use, with lots of travel and a satisfying 'thunk' at the bottom of each key. It's not as fast as my 2018 15" MBP for multi-core work, but I've not really noticed any performance issues with dev work (watching, building, compiling). It's also about 35% lighter than the 15" MBP. Another plus is that you can configure the keyboard via their management software (Lenovo Vantage) to swap around the 'fn' and 'ctrl' keys if you're used to 'ctrl' being at the left edge of the keyboard.

</comment><comment><USER3> thinkpads, the only laptops worth thinking about if keyboards matter to you</comment>


The Zen of "Go Away" Rates - <AUTHOR> http://www.caffeinatedcoder.com/the-zen-of-%E2%80%9Cgo-away%E2%80%9D-rates/

<comment><USER2> A high price signals high quality, a high time estimate signals either a complex implementation, or an incompetent implementor.

If your manager gets excited about your "go away" time estimate, he's likely hoping you will "go away".</comment>


Don't Build APIs - <AUTHOR> http://ceklog.kindel.com/2012/04/18/dont-build-apis/ <comment><USER2> OP here.

When I wrote this post, I didn't imagine so many people would react by saying, essentially

"Screw the customers. Just break 'em."

One of the reasons I have my panties in wad over this topic is the Web has made it far easier for people to create APIs that get used by others. Back in the olden-days you HAD to be Microsoft or similar to get the kind of traction a kid in his parent's basement can get with a little Python and a Heroku account.

But something else has changed along the way: Composability.

Yes, I worked on COM, OLE, ActiveX and all that crap. I was thinking deep thoughts about composable software back in the stone ages (and even then, it had all already been done by others smarter than I in the 70s & 80s).

But today it is REAL. The Web technology stack has actually, finally, enabled massive distributed systems composed of loosely coupled components from multiple independent parties! The dream of my computing youth has become reality!

These things are connected by APIs.

(Which, by the way are not just function calls. A API can be a REST end-point, a file format, or a database schema, amongst other things).

Yes, you as an API provider can choose to deprecate your API anytime you want. Use kill-dates, warnmessages, etc... You can even create new, independent & parallel versions. It will help.

But you will find that someone else has built something that uses your API, that exposes its OWN API and now there's a 3rd party indirectly dependent on you. Be prepared for it.

APIs are actually easy to build. That is the problem. The solution is to realize that statement is actually false.

<comment><USER3> OP, I really don't want to be that guy, and I don't know why I'm being that guy tonight, but regarding your sentence, "I then spent hours pouring over..." - come on man, it's poring.

<comment><USER2> I don't mind you being that guy at all.

I consider myself to be an ok writer with a reasonable vocabulary.

I never knew it wasn't pouring.

Consider me educated. Thanks. :-)

<comment><USER4> poring and pouring have different definitions - so pouring is correct for liquid, and poring is correct for poring over.

</comment></comment></comment></comment><comment><USER5> This post is very accurate. I build APIs for a living (CUDA), and this lines up pretty well with my experience. Writing APIs is very tough, you will get a lot of things wrong, and the fixes available to you after you realize your mistake are all ugly at best.

One quick example:

In CUDA, you have to explicitly copy memory to and from the GPU. We have two basic kinds of memcpy functions--synchronous and asynchronous. Asynchronous requires some additional parameter validation because the GPU has to be able to DMA that particular piece of memory, etc. After we had been shipping this for a release or two, we noticed that our parameter checking for the asynchronous call was missing one very particular corner case and would silently fall back to synchronous copies instead of returning an error. We thought, okay, let's just fix that by returning an error because surely no one managed to hit this.

Absolute carnage. Tons of applications broke. This particular case was being used _everywhere_. It provided no benefit whatsoever in terms of speed; in fact, it was just a more verbose way to write a standard synchronous memcpy. People did it anyway because... they thought it must be faster because it had async in the name? I don't know.

In the end, we made the asynchronous functions silently fall back to synchronous memcpys in all cases when the stricter parameter validation failed.

<comment><USER6> Thanks for your work on CUDA, it's really a great tool! My one hope is that Nvidia decides to make it a direct competitor to OpenCL by allowing it to target different platforms (though I recognize that it's not completely up to Nvidia and requires cooperation from others).

<comment><USER7> What would be the value in competing with OpenCL? CUDA and OpenCL ship pretty much an identical feature set with small changes in the API. The biggest difference is that OpenCL requires you to use buffers+offsets where CUDA allows "pointers" to GPU memory.

It's nice that Nvidia has CUDA so they can go ahead and expose functionality in new GPU's without having to (first) deal with OpenCL standardization. However, for the long term, it would be better if we'd stick to OpenCL so at least parts of source code can be shared between CPU's and GPU's of different vendors.

<comment><USER6> Competition is a good thing, and CUDA isn't a direct competitor to OpenCL because it only targets Nvidia's platform. OpenCL is obviously the longterm winner because nobody in their right mind would want to lock themselves into a single vendor. I'm saying that I would appreciate it for Nvidia to challenge that, which will drive both CUDA and OpenCL to become better.

</comment></comment></comment></comment><comment><USER8> At some point, we need to kill the myth of backwards compatible. This has caused more problems than it fixes. Further, at this point in history, app updates are trivial and built into everything, so retaining backwards compatibility is not so much of a necessity.

When designing APIs, use versions and have a kill date in place. Even if you don't change the API, release the same one under a new version number. Kill access to the old version on the kill date. Keep N versions accessible at a time, to reduce the burden on app writers, but don't slack on the kill date. This will give you a timeline and procedure to avoid hacking in crazy backwards compatibility, and targets for total rewrites.

Yes, people will still complain. It's OK though if you provide a reasonable balance.

<comment><USER9> Myth? MS built a very successful business on it.

You know what happens when you get kill dates? One day all of a sudden half the web will stop working. There's a reason why people start back flipping to support out of date calls.

Customers don't care why your software just broke or whose fault it was, all they care about is it broke.

<comment><USER10> I'm actually quite fond of the way Microsoft historically bent over backwards for backward compatibility, but OTOH Facebook is also very successful and has a very successful ecosystem of third-party users of their APIs. Facebook is like the anti-Microsoft in that they randomly change and break their APIs at such an alarming rate that you have to wonder if they are intentionally fucking with you if you code against their APIs.

Obviously the needs for a web API and the needs for an API with a specific binary ABI on a local OS are quite different but I think for either environment, most API developers can comfortably fit somewhere between those two extremes where they don't continue to support inherently unsupported API usage, but they don't break something randomly every week.

<comment><USER11> I think developers tend to love backward-compatability while users hate it.

As a developer, it means we don't have to keep digging out the old projects and porting them to the new API.

As a user, it means we are left with systems that have many years of cruft and with features being held back from systems because they couldn't make it backward-compatabile.

I think most users are willing to pay any higher price that will result from developers being required to work harder to port their software.

<comment><USER12> As a developer, I would rather have my code break than continue to use a terrible API.

<comment><USER13> How about fixing your application, because your terrible API were deprecated, for an application that is quite old, bit still in support ? (and of course for free, because client don't expect to pay for a compatibility fix).

</comment></comment></comment></comment></comment></comment><comment><USER14> The key problem here is that "backwards compatibility" means "backwards compatibility for people abusing the API in undocumented ways".

Don't do that. That way lays insanity. Be very, very clear up front that you _will_ break backwards compatibility for those folks. Don't sweep it under the table, be very vocal about having done it. There will be short term pain as important customers (eg Adobe) learn the hard way that you really mean it. And long term relief as you don't have that legacy headache growing so quickly.

One estimate is that a 25% increase in requirements results in a 100% increase in software complexity. (See _Facts and Fallacies of Software Engineering_ for a source.) That means that the complexity grows as the number of requirements cubed. Therefore the key to a good API is that it be short and simple. When you start to add implicit requirements on top of explicit ones, it quickly becomes long and complex, and the necessary software to support it and make future modifications becomes much worse.

This does not mean that designing APIs is not hard. But don't let your API become what is published and quirks that are not. Just don't.

<comment><USER2> OP here.

I think this is very naive/utopian.

Yes, be super focused in your design.

Yes, only expose APIs you have clear use cases for.

Yes, keep the surface area as small as possible.

Yes, have very focused requirements.

Yes, document the hell out of things.

Yes, implement strong parameter validation and other things to try to reduce the chance people do bad things.

Do all these things and more (these are all part of what makes exposing APIs hard work, that many people don't do).

But do not, for one second, believe that someone still won't do it wrong or abuse your perfectly designed API eventually... especially if it is successful.

<comment><USER14> I agree with all of what you just said. But I think that the post is not a good demonstration of that.

Microsoft failed at keeping the surface area as small as possible. When their surface area expanded to a hack to deal with Adobe's hack of replacing code behind Microsoft's back, they went into very dangerous territory.

<comment><USER15> If an end-user upgrades their operating system, and Adobe WhateverIUse stops working, who do they blame?

<comment><USER16> It's not as simple as that. If it's just Adobe WhateverIUse that breaks, sure, people will blame Adobe. But if it's Adobe WhateverIUse that breaks AND WordPerfect WhateverSomeoneElseUses and maybe also Borland SomethingSomeoneElseYetAgain uses word will get around that the new operating system "breaks things" and people will stay away from it.

Even if noone will ever use all three of the broken apps.

In this sense, maintaining backwards compatibility is simply a matter of reputation management.

<comment><USER17> > If it's just Adobe WhateverIUse that breaks, sure, people will blame Adobe.

Not a chance. People will blame Microsoft, because WhateverIUse worked perfectly before. The only parameter which changed is that they updated the OS, therefore the OS is to blame.

</comment></comment></comment></comment></comment></comment><comment><USER18> Upvoted because I find it interesting, not because I agree with it.

FreshBooks has a very _significant_ amount of their usage/profit from their API. These are just their endorsed/vetted add-ons, let alone all the ones out there in the wild: <http://community.freshbooks.com/addons/?header_addons=1> and they clearly built an app AND an API.

The API for FreshBooks was a major portion of their (very successful) strategy, so I can't see why people can't do both, provided they do it _intelligently_.

</comment><comment><USER19> This post addresses many of the issues we've dealt with at RadioReference.com. We version our primary APIs which has worked very well, but occasionally we have to abstract and write translations for backwards compatibility. We also need at times to deprecate versions and features.

But, this quote in the post is important: " _When exposing APIs be absolutely certain the value you get from doing so is worth it._ "

In our case, our APIs are a significant revenue driver and are worth it. Don't let OP discourage you from exposing your platform's data via APIs. Instead, let this post warn you what to look out for when exposing APIs.

</comment><comment><USER20> This boils down to a simple question:

Are most of your API users ahead of you, or behind you?

If you have an immature API with a smallish number of users, and you think that incompatible changes in the API will improve adoption with the vast bulk of your (not-yet-on-board) potential market, then go ahead, break the API.

If the only reason people use your API is because of its legacy -- if you think that by changing your API people will wake up from their inertial slumber and investiate your superior competitors, then don't break your API under any circumstances.

Obviously there are grey points in between, and a series of small breaking changes will be worse than occasional large breaking changes. But by and large, the success of your platform will depend on its utility, not legacy compatibility. This is why stripe and wepay will eventually conquer paypal, why python will continue to be a vibrant community, why java will eventually fade to cobol-like obscurity, and why Microsoft Windows is fundamentally doomed. It's hard to look backwards and forwards at the same time.

</comment><comment><USER21> This reminds me of a Joel Spolsky post from years ago:

<http://www.joelonsoftware.com/articles/APIWar.html>

Essentially, Microsoft shoots itself in the foot by trying to stay extremely backwards compatible, even to the detriment of making their products better.

</comment><comment><USER22> Public APIs are forever – you get one chance to get it right. Unless nobody's heard of your API and thus nobody uses it, in which case you're safe, but also screwed.

</comment><comment><USER23> Build the best API you know how to build and ask questions later. If your business is doing well, then supporting your API forever is a high quality problem.

<comment><USER24> This is often good advice, but not in this case. Versioning your API is a trivial thing to do from the beginning and has _massive_ consequences down the road. Some things _are_ worth getting right in the beginning.

</comment></comment><comment><USER25> My biggest issue with web APIs is the speed at which they change means you often get a lack of maintenance of documentation. The speed of change compounds the effects, the discussions you find on the API usage only months old have lost relevance in non obvious ways.

Facebook and Paypal are or have been guilty of this in the past though Facebook is a lot better than it was.

</comment><comment><USER26> The OP's enemy is not APIs, but rather proprietary software.

</comment><comment><USER27> Open source APIs and libraries improve this situation to some degree.

At least you wouldn't be stuck debugging assembly code.

</comment><comment><USER28> Netsuite has a different url for each new version of their API (and they keep the old one live as well).

This was great for me because my code never broke, which was important because It was running the back-end of an e-commerce site. It gave me more than enough time to upgrade when I wanted bug fixes/features.

<comment><USER29> Yes! This wasn't what the OP was referring to, though: he had shipping shrink wrap software with APIs in mind. But still, you're totally right and this occurred to me as I was reading the post, for Web APIs: keep versioning the URL for every shipped revision of your API. You'll have to document like crazy, of course. You can even detect stragglers on old versions and help them get on the new version.</comment></comment>


A Short Lesson in Perspective (2012) - <AUTHOR> http://www.lindsredding.com/2012/03/11/a-overdue-lesson-in-perspective/ <comment><USER2> What the article describes is something I also see in the electronics/software industry. So many people are competing about who works the most insane hours, but do not take the time to sleep over things.

<comment><USER3> This! I'm a programmer and I get looked down on at work because I don't work extra time over weekends. Sorry, I have a wife that I'd actually like to be able to spend time with. When I'm 80 and I look back, would I be glad that I spent every weekend in my 20s and 30s at work instead of enjoying myself? Doubtful.

<comment><USER4> I am glad that you have made a conscious decision about what is important to you.

It took me about two years of work in a commercial environment to actually internalise this and realise I much preferred working 40 hour weeks and freeing up more of my time to enjoy an equal relationship that was not polluted by the involvement of money.

I am at the point now where I think my "passion" for programming has been destroyed by work, and I think I am happier for it. I am still very willing to negotiate and participate in trades where I exchange valuable programming in return for money. Working 40 hours a week for $1.5x in an environment where everyone goes home by 5:30pm seems more promising than working 55 hours a week for $1.0x where employees are starting to fall apart.

</comment></comment></comment><comment><USER5> The context:

[http://www.businessinsider.com/its-not-worth-it-linds- reddin...](http://www.businessinsider.com/its-not-worth-it-linds-reddings- short-lesson-in-perspective-2012-11?IR=T)

Also:

[http://www.lindsredding.com/2011/10/12/my-shits-fucked- up/](http://www.lindsredding.com/2011/10/12/my-shits-fucked-up/)

</comment><comment><USER6> > It is a universal truth that all artists think they a frauds and charlatans, > and live in constant fear of being exposed.

This makes me wonder what people working in advertisement are thinking of their jobs.

<comment><USER7>
       This makes me wonder what people working in advertisement are thinking of their jobs.

Isn't that the entire point of the article, more or less?

</comment></comment><comment><USER8> Insightful post, it felt refreshing, thought provoking and personal to read how he dealt with the fact that he believed his job was meaningless and fun. Many people I talk at uni nowadays are having the fear that they will choose wrong for what they want to do after they graduate. This blog post shows that when an executed career plan does not pass the overnight test, you still live to see the morning.

</comment><comment><USER9> Work reasonable hours, get paid what you're worth, and damn the rest.</comment>


A Radical Approach to Computation with Real Numbers [pdf] - <AUTHOR> http://www.johngustafson.net/presentations/Multicore2016-JLG.pdf <comment><USER2> The original unum proposal is in [1] which was very interesting read. This is a newer version of the format that replaces NaN with a notion of an empty set and represents 1/x exactly. Rather splendid!

[1] [http://www.amazon.com/The-End-Error-Computing- Computational/...](http://www.amazon.com/The-End-Error-Computing- Computational/dp/1482239868)</comment>


"I confirm that I am not a resident of Iran, Syria, North Korea or State of NY" - <AUTHOR> https://www.reddit.com/r/Bitcoin/comments/3gr1je/hahah_check_out_the_registration_page_on_vaultoro/

<comment><USER2> Reddit is down; what was it?

<comment><USER3> It's just a bit of posturing over the fact that New York requires Bitcoin exchanges to follow some financial regulations.

IMO it comes off as unprofessional, but maybe it appeals to the target audience.</comment></comment>


Ask HN: Is There a Tool to Know Which Companies Are Using Your Web Service? - <AUTHOR> I have a site that I run that gets about 55,000 visitors a month.  I want to know if anyone knows of any web services that I can track if employees at companies like Amazon, Apple, and Facebook are using my product? <comment><USER2> Making a ton of assumptions on your situation, here is how I would go about it.

Record the IP addresses of your users (multiple per user), link these to user profiles and do a whois for each IP address.

Big companies like the ones you mention will sometime appear to have their own IP address and you can then deduct the employer of your users.

Additionally and assuming you have your users full names and email addresses, you can scrape the web and get their professional profile.

Alternatively, you can probably buy some kind of user data but I would not know where to start except by googling around.

All this can be build in a nice administrative UI for your application, from which good old human investigation can lead you to the specific people you are looking for to manually validate each user's employer.</comment>


Multiple Single Page Applications' Application - <AUTHOR> https://github.com/M-SPA/M-SPA

<comment><AUTHOR> Multiple Single Page Applications' Application

There more and more single page applicaitons, to my point of view, it's time to discuss M-SPA!</comment>


Chrome 67: How do I get the old Chrome video player back? - <AUTHOR> https://productforums.google.com/forum/#!topic/chrome/kyoTaizAgtY;context-place=topicsearchin/chrome/category$3Awindows8%7Csort:relevance%7Cspell:false <comment><AUTHOR> From a reddit post at r/chrome:

> Here is a screenshot. > [https://i.imgur.com/aPdZRNz.png](https://i.imgur.com/aPdZRNz.png)

> The play/pause button in the center of the player distract from the actual > video, and places it too far away from the other video controls.

> The volume control is now a on/off toggle, without the ability to adjust > volume at all.

> The download button is the only item hidden behind the new three dots menu, > requiring two clicks to achieve what used to need one click, while taking up > the exact same amount of space.

Source: [https://www.reddit.com/r/chrome/comments/8npg8w/the_new_vide...](https://www.reddit.com/r/chrome/comments/8npg8w/the_new_video_player_on_chrome_67_sucks/)</comment>


HTML5 Map of the the World Migrations using SVG, Raphael.js and offline storage - <AUTHOR> http://migrationsmap.net/#/IND/departures

<comment><USER2> People who like exploring statistics like this (as opposed to just being impressed by the nice technical implementation - which I love, btw) should take a look at GapMinder.

Eg:

[http://www.gapminder.org/world/#$majorMode=chart$is;shi=t;ly...](http://www.gapminder.org/world/#$majorMode=chart$is;shi=t;ly=2003;lb=f;il=t;fs=11;al=30;stl=t;st=t;nsl=t;se=t$wst;tts=C$ts;sp=5.59290322580644;ti=2009$zpv;v=0$inc_x;mmid=XCOORDS;iid=phAwcNAVuyj1jiMAkmq1iMg;by=ind$inc_y;mmid=YCOORDS;iid=phAwcNAVuyj2tPLxKvvnNPA;by=ind$inc_s;uniValue=8.21;iid=phAwcNAVuyj0XOoBL_n5tAQ;by=ind$inc_c;uniValue=255;gid=CATID0;by=grp$map_x;scale=log;dataMin=295;dataMax=79210$map_y;scale=lin;dataMin=19;dataMax=86$map_s;sma=49;smi=2.65$cd;bd=0$inds=;example=75)

[http://www.gapminder.org/world/#http://www.gapminder.org/wor...](http://www.gapminder.org/world/#http://www.gapminder.org/world/#$majorMode=chart$is;shi=t;ly=2003;lb=f;il=t;fs=11;al=30;stl=t;st=t;nsl=t;se=t$wst;tts=C$ts;sp=4.67741935483871;ti=1990$zpv;v=0$inc_x;mmid=XCOORDS;iid=phAwcNAVuyj1jiMAkmq1iMg;by=ind$inc_y;mmid=YCOORDS;iid=0ArfEDsV3bBwCcGhBd2NOQVZ1eWowNVpSNjl1c3lRSWc;by=ind$inc_s;uniValue=8.21;iid=phAwcNAVuyj0XOoBL_n5tAQ;by=ind$inc_c;uniValue=255;gid=CATID0;by=grp$map_x;scale=log;dataMin=1438;dataMax=45906$map_y;scale=log;dataMin=1.7;dataMax=1551$map_s;sma=49;smi=2.65$cd;bd=0$inds=i175_l001990bfbH;i65_p001990afa7;i231_l001990bVba)

The Hans Rosling TED talk is fantastic too: [http://www.ted.com/talks/hans_rosling_shows_the_best_stats_y...](http://www.ted.com/talks/hans_rosling_shows_the_best_stats_you_ve_ever_seen.html)

</comment><comment><USER3> This is really informative, and very well done to boot. Great work!

The colour scheme struck me as a little odd, though. It goes from darker (more migration) to lighter (less migration) but then abruptly to dark grey (no migration), making it harder to interpret at first glance. It would be nice if it were somewhat monotonic: bright colour = more migration, darker/duller colour = less migration, dark grey = no migration.

<comment><USER4> I also found the bright "alert" red to feel like "more" than the darker more saturated one for me.

</comment></comment><comment><USER5> Nice and interesting, well done! I also like the offline caching feature.

The only tiny imperfection I see it's in the lines connecting two countries, I'd like to see an arrow so I know if I'm looking at arrivals or departures.

Is there a way to filter the GMO database to see only the current migration flow (say, last 5 years)?

<comment><AUTHOR> I have tried to add arrows at some point, but it cluttered the visualization too much (especially for countries where migrations are quite local : limited to border-sharing countries).

That said, there may be a solution I did not think about.

<comment><USER6> How about drawing the arrowhead on the middle of the line? (And not drawing it on short lines. The arrowheads on the long lines will reveal whether 'departures' or 'arrivals' are depicted)

<comment><USER7> This. And if possible, add a subtle gradient on each curve. So, even without arrows on short lines the direction is clear. Plus it looks cool.

</comment></comment></comment></comment><comment><USER8> Fascinating how boring data may be presented interesting and fresh by simple vizualisation. This remings me of the TED talk given by Hans Rosling about global statistics of population, mortality, internet access etc. Whoever made this map should contact mr. Hans, I smell collaboration there.

<comment><AUTHOR> Thanks for the tip....

</comment></comment><comment><USER9> It's understandable that several places don't have data (NaN), but I found it curious that Burma/Myanmar is missing from the map [1], much like the "Poland Sea" in a Microsoft Date/Time screen from yesteryear [2].

Did you create this map data or get it from somewhere else? Is this some kind of joke?

[1] <http://i.imgur.com/m8Wce.png>

[2] [https://blogs.msdn.com/b/oldnewthing/archive/2006/10/27/8804...](https://blogs.msdn.com/b/oldnewthing/archive/2006/10/27/880411.aspx)

<comment><AUTHOR> No, it's just a bug. I have been using two sets of data where the name of the countries were not perfectly matching (example: United States VS United States of America). I fixed most of the inconsistencies and showed the map to some people to help me spot the problems. This one slipped through (as the geocoding of Serbia and some NaN).

<comment><USER10> Puerto Rican per-capita income is NaN, by the way.

</comment></comment></comment><comment><USER11> The blue arrow next to the arrivals and departures selection, acts like a radio buttion, but looks like an arrow. This is misleading... I was wondering why it said "Arrivals => Deprture" which looked weird... only after i clicked around, it was obvious that it was acting like a radio button.

<comment><USER12> I was also initially confused by that.

Maybe the arrow and the name of the currently selected item could be enclosed in a bounding box with a darker background, so as to more clearly show that it is currently selected.

</comment></comment><comment><USER13> Really Responsive too and it all works in Opera or seemed to anyway, so many developers forget about Opera because it doesn't have the same amount of marketing as the others. But anyway Sweet Build!

<comment><USER14> _"many developers forget about Opera because it doesn't have the same amount of marketing as the others."_

Um, no. Many developers forget about Opera Mobile/Desktop because nobody uses it. Many developers forget about Opera Mini because it's worse to develop for than IE6.

<comment><USER15> So I'm _not_ using Opera right now then? Thanks for clearing that up for me.

Perhaps you should consider that even a few percentage point share of the browser market still translates to _millions_ of users. About 50 million on Opera Desktop to be more precise.

If you don't care about them I guess you certainly don't care about the few people using screen readers; or how about Safari which has only roughly double Opera's measly market share?

</comment></comment></comment><comment><USER16> What is this data? Is it last year's migrations? Averages? More context is needed.

<comment><AUTHOR> I added some context through the links at the bottom of the map: you can go to <http://migrationsmap.net/about.html> or directly to the page where the data is coming from: [http://www.migrationdrc.org/research/typesofmigration/global...](http://www.migrationdrc.org/research/typesofmigration/global_migrant_origin_database.html)

<comment><USER17> No, you _need_ to have units on your data. Without units, numbers mean nothing. You select a country, and then you're presented with a list of other countries and some numbers. It's not clear that these are lifetime immigrants or permanent residents. There should be a title on the country info box "Total lifetime immigrants" or "Total lifetime emigrants", and ideally a legend at the bottom defining what that means.

It's also confusing in that the number format follows a European convention of using decimal points rather than commas in between every three digits the numbers, though I can accept that localising your site isn't a big concern.

<comment><AUTHOR> No, I don't NEED to do anything... That said, your comments are totally relevant, I will implement them.

</comment></comment></comment></comment><comment><USER18> This is awesome really enjoyed it, spent about 20 mins checking out how people and moving around the world.

I would include a zoom function, some small countries are hard to find.

<comment><AUTHOR> I totally agree, that is the main missing feature in my opinion and the reason why I added a select box on top.

At first I wanted to use polymaps, which supports zoom and pan, but I found it difficult to draw on top of it (for the "arrows") and it lacked ie support. So I went for Raphael.js, but found it to cumbersome to implement zoom and pan.

</comment></comment><comment><USER19> Some data seems strange to me. Why would 123k mexicans go to pakistan? Or 30k mexicans go to Congo? <http://migrationsmap.net/#/MEX/departures>

and I understand this is lifetime, but still those two destinations seem unlikely to me.

fascinating map nonetheless.

<comment><USER20> Nevermind Pakistan, why would 2,626 Mexicans go to Greenland? <http://migrationsmap.net/#/GRL/arrivals>

</comment></comment><comment><USER21> Great job and I really enjoyed the visualizations. If you have the data, I would love to see migrations over time.

</comment><comment><USER22> Very impressive, nicely done! Spent a couple of minutes exploring migrant streams.

Minor nitpick: When I click on 'Macedonia' the origin point appears in Sweden. When I click on 'Serbia' it appears in Canada.

<comment><AUTHOR> Oops, I will fix that.

</comment></comment><comment><USER23> There's an ordering issue for Faroe Islands departures. I think it might be doubling single-digit quantities - everything below Panama (10 departures) is a duplicated number. I'm on Firefox 6.0.2, Linux AMD64.

</comment><comment><USER24> Very nice. I was wondering how difficult it would be to capture a particular state of the map (say UK departures) as a PNG for embedding or generating a PDF. Could you do that on the server side?

<comment><USER25> I've been looking into a few ways to do exactly that with Raphael. The short answer is that it's possible but a little tricky. I've found three methods so far:

1) If you're using a browser that supports SVG (basically, not IE), Raphael will generate the images as SVG nodes in your DOM tree. You can just grab that entire section of the DOM and send the SVG markup to the server where you render it using the image library of your choice.

2) If you have to support IE the above method won't work. Only IE9 has any SVG support and I've heard reports that it's spotty. In these cases, Raphael falls back on VML, an older MS extension that provides more or less the same experience. Unfortunately, I don't know of a server side generation library that supports VML. What's worse, in my testing, IE won't even print the VML image so you can't even use a PDF writer in the browser.

So, the simplest workaround is use the VML fallback in IE for display but when the user wants to download a final version, generate the same drawing as HTML + Javascript on the serverside and then use wkhtmltopdf on the html. (For those who don't know, wkhtmltopdf is an awesome tool that uses a headless webkit browser to convert HTML files to shockingly good PDFs).

As long as the javascript is triggered on load, wkhtmltpdf will include it in the resulting pdf. This doesn't always work perfectly but odds are it'll work for you.

As an added bonus, SVG bits also seemed to be rendered as vector in the actual PDF. This also prevents any chance of the server side image rendering slightly differently from the user preview.

3) If the wkhtmltopdf method isn't rendering properly or is too exotic for your server, you can try using the great raphael.serialize plugin ( <https://github.com/jspies/raphael.serialize> ). This works around the SVG/VML problems by exporting the data as a JSON structure. This can be re-rendered inside raphael easily but exporting to PNG is trickier. You can convert the JSON to SVG and render that as in method one, Ben Barnett has a small code example on how to do that: ( [http://www.benbarnett.net/2010/06/04/export-svg- from-raphael...](http://www.benbarnett.net/2010/06/04/export-svg-from-raphael- js-to-create-a-png-bitmap/) ) but there's no complete library for doing this yet so you'll have to write some extra bits yourself. If you do write a library for this, please open source it so I don't have to do it too. ;)

Also, Raphael 2.0 is being launched at jsconf.eu next month so it may have a more clever approach for this but I haven't looked into it yet.

<comment><USER26> IE9 SVG support is really good. It has some differences in coverage, but is excellent overall.

</comment></comment></comment><comment><USER27> Looks great! The population of Saint Helena is NaN and also there is something wrong with the arrows..

BTW changing #hashcode based on the country looking at would be great too.

<comment><AUTHOR> I'm not sure that I understand well, the hascode is indeed changed base on the currently viewed country.

<comment><USER27> I missed that, now I see!

Then check that <http://migrationsmap.net/#/SHN/departures> is still broken.

<comment><AUTHOR> Ok, it's a problem with the geolocation of Saint Helena, I will fix that.

</comment></comment></comment></comment><comment><USER28> The GDP of Somalia is apparently so low it is NaN.

<comment><AUTHOR> For some countries, the world bank is giving no data. That said, it should not display NaN but rather "No data". I will investigate.

<comment><USER28> I should have also added that it is a really cool page, aside from the one bug I pointed out.

</comment></comment></comment><comment><USER29> Interesting...there is a huge migration from Brazil to China..can someone point out whats the reason?

<comment><USER30> I'm inclined to believe it's wrong data.

It could be there was some so-called return immigration, with Chinese- Brazilians going to China during the times of high unemployment rate on Brazil (as lots of Japanese-Brazilians did). But as a Brazilian I've never heard of that, so 50k sounds implausible.

</comment></comment><comment><USER31> Kind of crazy to see how almost every Country on the list has the United States as a destination.

</comment><comment><USER32> The English on the About page needs some work. Pay attention to singular and plural, for example.

<comment><AUTHOR> I will fix all the typo.

<comment><AUTHOR> Done.

</comment></comment></comment><comment><USER33> I see various migrations lacking - f.ex. Polish to Brazil, and Vietnamese to Poland. why is that?

<comment><AUTHOR> The reason is probably because the map is only showing the top 10 for each list of countries. Vietnam is probably not in the top ten for arrivals in Poland.

You can easily verify this here: [http://www.migrationdrc.org/research/typesofmigration/global...](http://www.migrationdrc.org/research/typesofmigration/global_migrant_origin_database.html)

<comment><USER33> there's said to be 30-40k Vietnamese in Poland, some say even 50k. also there's a huuuuuge Polonia in Brazil.

</comment></comment></comment><comment><USER34> I'd like to see this in the Peters projection, but otherwise quite fun!

</comment><comment><USER35> For more data visualization check out www.bricbracs.com/splash

</comment><comment><USER36> Fantastic</comment>


The Invention of Email - <AUTHOR> http://www.inventorofemail.com/

<comment><USER2> This guy is becoming a famous net kook. Perhaps he should be on a plinth next to Sergar Argic.</comment>


Polish DeWalt site has no TLS, registration is mandatory for extended warranty - <AUTHOR> https://twitter.com/radoslawc/status/960880267169812480 <comment><USER2> The real thing I'm seeing with these patterns is that a lot less corporates actually ever cared about the "Not Secure" warning that many of expected, when Chrome introduced the warning.

I really expected marketing departments to see this and want to act, but my own experience had contradicted that.

<comment><AUTHOR> Also I'm not a lawyer but for me it violates Article 25 of European General Data Protection Regulation: "Data protection by Design and by Default (Article 25) requires that data protection is designed into the development of business processes for products and services. This requires that privacy settings must be set at a high level by default and that technical and procedural measures should be taken care by the controller in order to make sure that the processing, throughout the whole processing lifecycle, complies with the regulation. Controllers should also implement mechanisms to ensure that personal data are only processed when necessary for each specific purpose." [https://en.wikipedia.org/wiki/General_Data_Protection_Regula...](https://en.wikipedia.org/wiki/General_Data_Protection_Regulation)

</comment></comment><comment><AUTHOR> There is no other way according to customer service reply I've got to obtain extended warranty than register via local page. Name, Address, Phone number and password, all this is sent via plain http. Power tools manufacturer DeWalt is subsidiary of Stanley Black & Decker which according to wikipedia ([https://en.wikipedia.org/wiki/Stanley_Black_%26_Decker](https://en.wikipedia.org/wiki/Stanley_Black_%26_Decker)) 2012 revenue was $US 10.19 BILLION. To add insult to injury saw I've bought costs twice as much as priciest wildcart certificate I've found.

</comment><comment><USER3> Seems like pure negligence on their part.</comment>


Zuckerberg-Linked Group Releases Ad Blasting House GOP For Immigration - <AUTHOR> http://techcrunch.com/2014/03/03/zuckerberg-linked-group-releases-ad-blasting-house-gop-for-immigration-reform-intransigence/

<comment><USER2> The STEM worker shortage is a myth. The Zuckster just wants to keep that cheap labor rolling in. He wants a "healthy" labor market.

<comment><USER3> How is this related to STEM workers? Illegal immigrants are not STEM workers.</comment></comment>


An Ex-Car Rental Agent's Money Saving Advice - <AUTHOR> http://bucks.blogs.nytimes.com/2010/11/15/an-ex-car-rental-agents-money-saving-advice/

<comment><USER2> While the NY Times article is a nice summary you still can read the source

[http://www.edmunds.com/advice/buying/articles/165627/article...](http://www.edmunds.com/advice/buying/articles/165627/article.html)

which is part of a broader series

<http://www.edmunds.com/confessions/></comment>


Alternatives to JSX - <AUTHOR> https://blog.bloomca.me/2019/02/23/alternatives-to-jsx.html <comment><USER2> Wow, after reading this, I'd be surprised if anyone could come away with the conclusion "Yeah, that's better than JSX."

I think the general distaste for JMX is that it "feels" backwards initially: it mixes in HTML snippets within code, while many people are used to template files, which are mainly markup with small bits of "presentational" code injected.

But once you realize and really understand that JSX is just shorthand for javascript calls (and the article does a good job of explaining this), you hopefully eventually reach an "Aha!" moment of thinking of JSX in terms of underlying component creation. That's what happened to me, anyway,.

<comment><USER3> I've always thought the "HTML in JS" was in fact a strawman argument set up to deviate the attention from the fact that it is indeed a different syntax for function calls (and class instantiation). And it is actually that the thing that I dislike about JSX. I think it's a _bad syntax_ for function calls/class instantiation.

I do like hyperscript better than JSX... precisely because it's _not_ a syntax for function calls. Because it's just a function.

<comment><USER4> It's not entirely a strawman, because there are legitimate concerns about separation of concerns that the "HTML in JS" argument worries about. Especially in the web world which still knows the legacy against fights of business logic in templates going back to "bad old PHP days", etc.

There are good reasons to be skeptical about JSX simply because of the worry about how much business logic may accidentally be embedded directly into views. For JSX, the answer is typically to solve that in other areas of workflow and patterns of habit. But the war between "as dumb as possible a templating language" and "just let me use my real language for templates" will probably wage on in the web space forever.

<comment><USER5> Maybe it's best not to think of React as a View but a Component... You can create Components that are simple Views and render what they are given, you can also create smarter Components that are more in line with Controllers.

As a loop: Store -> State -> Reducer -> Component -> Action -> Dispatch -> Store ...

Or if you want something closer to MVC, you could use MobX or similar.

<comment><USER4> I've been sold on JSX for a while, personally, and pretty much have that architecture in my apps I'm working on.

I just also remember being an idealistic Django-loving youth that wanted the dumbest possible template engine to avoid teenage PHP drama, so I definitely sympathize with folks whose gut reaction is upset with JSX for crossing the streams (again), and thought to make sure it was clear that it isn't a straw man argument to many. (Even if it is also, as in my case, an argument that can be won in favor of JSX. Though also in my case one of the big factors winning that argument was TSX [Typescript type checking of JSX views] versus many of the alternatives and their [lack of] static checking/analysis.)

</comment></comment></comment></comment></comment><comment><USER6> Why JSXBelPack when you can

      import { html, render } from 'https://unpkg.com/lit-html';

      const benefitTpl = ({name, desc}) => html`

${name}

${desc}

      `;

      render(html`
        <lit-rocks>

${benefits.map(benefitTpl)}

        </lit-rocks>`, document.body)

And updates are fast without any VDOM overhead.

<comment><USER5> Is this doing a full re-render on each change? Having not seen the state management piece... but could be nice for progressive enhancement modules in a server-rendered app. I've done similar in JS.

<comment><USER7> Nope! It doesn't visit each node like vdom. VDOM visits every virtual node. lit-html looks at only the expressions. That's where a lot of the speed/performance comes from

</comment></comment></comment><comment><USER8> I used to be really sceptical about JSX, 1 extra transp. step, anorthodox use of xml in JS, etc.

Having been using it for the past 3-4 years I think its an above agerage elegant solution when it comes to templating solutions.

</comment><comment><USER9> Pug is a worthy mention. [https://github.com/pugjs/babel-plugin-transform- react-pug/bl...](https://github.com/pugjs/babel-plugin-transform-react- pug/blob/master/README.md) wasn't mentioned

</comment><comment><USER10> What really bugs me about JSX is the complexity it introduces to the build pipeline - which might be fine for senior developers, but I regularly see junior developers struggle with configuration and errors.

<comment><USER11> You get a ton of other benefits from buying into a webpack-style build system though:

\- Modules \- TypeScript \- Newer JavaScript syntax \- SASS compilation \- Code splitting

etc.

For me, it's hard to imagine a medium/large sized JS project without using some kind of module system. And once you've setup the build system for that, you might as well use all of the other features that it enables.

<comment><USER12> You can get modules now in many browsers, as well as the latest JS syntax, without needing any build step.

Code splitting/vendoring has changed with HTTP2, and will continue to change as HTTP3 comes along.

SASS compilation, and if you choose to use TypeScript, will require a build step, but at least the SASS side of that is very easy and straight forward by itself.

<comment><USER5> You're still missing a few of the finer points of stage 0-3 optiosn for babel. Also, that bloats out to a lot of requests with full round-trip time, and no real good server solutions for bundling via HTTP2/3 push yet.

</comment></comment></comment></comment><comment><USER13> The fact that front end has to deal with 3 different languages (JS + HTML + CSS) is a problem nobody has completely solved.

These days the solution usually falls into 3 camps:

1) Write everything in JS like React.createElement or Mithril. No build setup but a pain to use.

2) JSX. Requires a build setup which might become complex as the project grows.

3) Templates. Probably the less elegant of all 3 but the most pragmatic and easy to use.

Someone attempted to solve this and created a new language called Imba. It's like a mutant Ruby with HTML that compiles to JS.

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

It has a lot of productivity benefits compared to previous attempts at solving the same problem, but goddammit it's ugly.

<comment><USER14> The project "create-react-app" is a good mixture of #2 and #3 that I have been using for almost a year with almost no issues, it's just a generally great way to use React. The only issue I had is that, even though all your configuration is "for free", you don't really get new features right when they come out. But you get them after their configuration has been polished up, so that you don't have to shave all the yaks yourself.

<comment><USER13> Personally I'd rather have my own configuration than use a CLI like create- react-app or Vue CLI.

It's easy enough to create a template/starter kit the way you want it and tweak it to your taste. Also when (not if) you get a problem you know what's going on instead of a black box.

</comment></comment></comment><comment><USER15> We use virtual jade at work. It works with most virtual doms that use some form of h(name, attrs, children) calls.

We have webpack hot reloading so we can work on UI without any page refreshes.

It's been very productive. I love the brevity of jade/pug. Jsx feels like a lot of boilerplate braces and ending tags.

[https://github.com/tdumitrescu/virtual- jade](https://github.com/tdumitrescu/virtual-jade)

<comment><USER16> I've been using pug with the babel plugin for a React project, and I really like it. I'm a fan of Haml for server-side rendered Rails views, too. I'm surprised pug isn't more widely used in front-end dev, since it is so popular in Node apps.

Also: projects are still using the "jade" name? I thought they were forced to change?

<comment> lf-non pug is really nice (as is haml).

The only reason I bear with the superfluous verbosity of JSX is because it plays well with typescript. The moment you switch to text based templates typesafety goes out of the window.

I really wish javascript/typescript had a good builder syntax like Ruby. Hyperstack [1] (previously Hyperloop) is a great project that uses ruby blocks for component composition. I wish this was possible in javascript.

[1] [https://hyperstack.org/](https://hyperstack.org/)

</comment></comment></comment><comment><USER17> I would advice against using JSX alternatives. I come from a Clojure background and I like the ijk solution to just use an array to represent the virtual dom.

But still I would recommend using JSX because it the "standard". Every documentation and problem solution you find on the internet is written with JSX. Using a JSX alternative will make debugging much harder for you.

</comment><comment><USER18> HTM actually looks pretty intriguing to me.

One thing I like about JSX is that it looks and feels like HTML.

For me, that has two huge benefits:

1\. It narrows the dissonance between the code I'm writing and the actual structure that will be rendering into the DOM. I find it much easier to write and debug when I don't have translate between some JS factory function and the actual DOM implementation.

2\. It's almost pure HTML. Sure I'll have to change class to className and update some other tags. Generally, though, if something works in HTML, it's little fuss to do in JSX. With tools like JSX, I can write in a single templating language across all of my software.

<comment><USER19> One thing the author missed about htm is that you don't necessarily need to parse it at runtime— there's a Babel plug-in to compile it to plain js function calls. This way you can develop without a transpiler and add one later when (if) the extra performance becomes necessary.

</comment></comment><comment><USER20> i'm surprised hiccup was never mentioned. ofc it's not for pure JS but there's this thing - [https://github.com/lantiga/react.hiccup](https://github.com/lantiga/react.hiccup) though i never tried and don't know how well it works. still interesting.

<comment><USER21> Hiccup is awesome for ClojureScript since we get to use plain Clojure data structures rather than a DSL that must be parsed in a separate step, but I think this advantage disappears when using it outside the context of Clojure/ClojureScript.

</comment></comment><comment><USER22> There's also kotlin-react which let's you write React in Kotlin in a Kotlin DSL which looks exactly like your first imagination probably suggests: [https://github.com/JetBrains/kotlin- wrappers/tree/master/kot...](https://github.com/JetBrains/kotlin- wrappers/tree/master/kotlin-react)

It's also a pretty impressive demonstration of the typesafe flexibility of Kotlin's DSL support, but that's another conversation.

</comment><comment><USER23> ClojureScript + Reagent

<comment><USER24> This combo is insanely beautiful. Not only does it solve the JSX issue, it does it without any new syntax and adds persistent, immutable data structures, something React is just begging for. My only problem is that I'd have to switch jobs for any chance of using it at work.

</comment></comment><comment><USER25> A point to the discussion of whether JSX is preferable or not to a programmer, most React projects with JSX I've worked on has had the awesome bonus of a designer who knows markup/css to be able to add layouts to our web and React Native projects. Just wanted to throw that out there as a plus to JSX. I don't think the designer could follow hyperscript very well.

</comment><comment><USER26> There's also HDOM, part of the larger Umbrella collection of libraries: [https://github.com/thi- ng/umbrella/tree/master/packages/hdom](https://github.com/thi- ng/umbrella/tree/master/packages/hdom)

Purported benefits from the readme:

\- Use the full expressiveness of ES6 / TypeScript to define user interfaces

\- No enforced opinion about state handling, very flexible

\- Clean, functional component composition & reuse, optionally w/ lazy evaluation

\- No source pre-processing, transpiling or string interpolation

\- Less verbose than HTML / JSX, resulting in smaller file sizes

\- Supports arbitrary elements (incl. SVG), attributes and events in uniform, S-expression based syntax

\- Supports branch-local custom update behaviors & arbitrary (e.g. non-DOM) target data structures to which tree diffs are applied to

\- Component life cycle methods & behavior control attributes

\- Suitable for server-side rendering and then "hydrating" listeners and components with life cycle methods on the client side

\- Can use JSON for static components (or component templates)

\- Optional dynamic user context injection (an arbitrary object/value passed to all component functions embedded in the tree)

\- Default implementation supports CSS conversion from JS objects for style attribs (also see: @thi.ng/hiccup-css)

\- Auto-expansion of embedded values / types which implement the IToHiccup or IDeref interfaces (e.g. atoms, cursors, derived views, streams etc.)

\- Fast (see benchmark examples)

\- Only ~6.2KB gzipped

</comment><comment><USER27> Awesome article. I appreciate the lack of bias. Thanks for writing this, OP. It's good to keep an eye on the horizon for potential alternatives to tech we use day in day out, but it looks like we're still on solid ground with JSX so no need to switch :)

</comment><comment><USER28> There is also a babel-transform for pug[1]. It works quite well as JSX replacement. Not having any endig tags can be quite beneficial when reformatting stuff.

Paired with Tachyons (best atomic CSS lib) you get superpowers and can write code like

      const someComponent = ()
        => pug`
          ul.p2.f3 Some list
            li.red Some text
            li.pink Some more`

[1] [https://github.com/pugjs/babel-plugin-transform-react- pug](https://github.com/pugjs/babel-plugin-transform-react-pug)

</comment><comment><USER29> I think a lot of readablity issues with jsx are caused by the amount of logic react devs will put in their markup. It's painfully reminiscent of old-school PHP templating

</comment><comment><USER30> My problem with JSX is that if you introduce a DSL, why would you limit it to basic function calls/expressions?

I created a small language to demonstrate what I mean [https://github.com/batiste/blop-language](https://github.com/batiste/blop- language)

<comment><USER31> Easier to reason about.

JSX is a simple wrapper around a JS call, it is trivial to mentally convert from JSX to what the real JS is.

JSX is also super copy-pastable. Less logic and all that.

If you want complex logic around what JSX to render, it get factored out into a function call (or its own component), which returns the appropriate JSX after evaluating any required logic. This means you are back to plain JS with all the existing tooling and language features around it.

JSX being simple also makes the learning curve simple.

<comment><USER30> > JSX is a simple wrapper around a JS call, it is trivial to mentally convert > from JSX to what the real JS is.

Then maybe it is an indication is not worth very much. Why not using something like hyperscript instead if it is just some javascript.

> JSX is also super copy-pastable. Less logic and all that.

In my experience the copy-paste-reuse in FE is a red herring. And React is no exception. And a logic less templating is not necessarily helping with a flexible/reusable piece of code.

> JSX being simple also makes the learning curve simple.

Not so sure about that. I think I would have personally preferred not having to learn a new DSL if some basic function call in Javascript can do the same job.

I guess I have been scared by colleagues using ugly ternary operator expressions with React.

I also used so many template languages in the past: PHP, Django, Pug, Rails, etc, etc. That I try to reproduce similar features/mistakes.

</comment></comment></comment><comment><USER32> I was a bit apprehensive about JSX before quickly getting used to it. Now I love it.

The only decision I dislike is renaming class to className. Why not klass, cls, cs... anything shorter.

ClassName is simple to understand but adds a lot of clutter to component files.

<comment><USER33> Because it matches the field name for DOM nodes:

[https://developer.mozilla.org/en- US/docs/Web/API/Element/cla...](https://developer.mozilla.org/en- US/docs/Web/API/Element/className)

</comment></comment><comment><USER34> lit-html surely does a good job..

\- ES6 string literals

\- partial template rendering

are few cool features with it.

<comment><USER35> I haven't looked much into lit-html but is it possible to type check your templates like you can do with JSX? That is one big advantage I found for JSX compared to template-based frameworks.

<comment><USER36> All components, expressions, etc are in template curlies `${}` so type checking works out of the box. If you mean type checking on HTML properties, no it does not.

Lit HTML seems very extensible, so it should be possible to add support for thus.

</comment></comment></comment><comment><USER37> If you read this article and thought Hyperscript might be something you wanted to try, please check out Mithril[0].

It's an excellent project, pretty decently fast (checkout the js-framework- benchmark[1] code, or more specifically the results of round 8[2]) -- but is currently suffering from a lack of recognition. It's the kind of project that absolutely doesn't care about that kind of metric (as in, the team seems to be more focused on slow, steady improvement of the library rather than chasing stars on github), but I figured I should say something.

Shameless plug: I recently really wanted to contribute something (and kick the tires more) so I wrote an article that goes through replicating a simple mail design I saw[3] -- it might be a decent overview of what mithril is like to write (though I'm certainly not a mithril expert).

This brings me back to the point at hand -- as others have noted, in my opinion one of the best things about hyperscript is the straight-forwardness with which you construct the render function. I'm not convinced it's necessary to segregate stateless/stateful components -- and mithril is simpler in that it doesn't introduce this dichotomy -- in the end there's the render function, and that's it. If you want to use state, go ahead -- if you don't, then don't. It's the simplicity I've wanted from component frameworks (and mostly get with Vue) without any of the posturing/looming complexity.

Also there's the fact that you could write a completely vanilla es5 application with hyperscript (arguments whether you should or not aside) -- JSX is/was revolutionary, but is basically required in practice, which often makes people jump into bed with webpack without thinking, and makes frontend development harder than it has to be.

[EDIT] - Another point for mithril is that it's _self contained_ \-- routing and ajax calls some with the framework. When people these days talk about "react" or "vue" what they're really talking about is react/vue + react- router/vue-router + flux/vuex and some other odds and ends. Mithril is by far the simplest and most feature-complete of these frameworks despite being smaller (both conceptually and on-the-wire).

One of my only current gripes with Mithril is the lack of controllable subtree rendering (it isn't as much of a problem in practice, but more me wanting to optimize early).

[0]: [https://mithril.js.org](https://mithril.js.org)

[1]: [https://github.com/krausest/js-framework- benchmark](https://github.com/krausest/js-framework-benchmark)

[2]: [https://www.stefankrause.net/wp/?p=504](https://www.stefankrause.net/wp/?p=504)

[3]: [https://vadosware.io/post/mithril-systemjs-and-rollup- gettin...](https://vadosware.io/post/mithril-systemjs-and-rollup-getting- started-guide/)

<comment><USER38> I enjoyed your article very much. I'm a huge fan and proponent of this framework. Since I come across Mithril I have used it exclusively on all internal projects at our agency and haven't looked back.

Adopting Mithril also opened me up to a whole list of lesser known but vigorously thought through projects like BSS, Patchinko and the beautiful Meiosis pattern which changed the way I went about developing resulting in far better productivity.

<comment><USER37> Thank you very much! I really wanted to see more writing on the internet around Mithril -- it seems it's like lisp in the way that most people who are using it productively are just doing heads down working on stuff.

> Since I come across Mithril I have used it exclusively on all internal > projects at our agency and haven't looked back.

I'd love to see some writing on some of the patterns you've developed with it! Also, it might be cool for mithril to have a "trusted by" section on their main page to showcase some companies that use mithril to increase trust for people who wander in (though I'm also OK with mithril not having this section -- it's a bit overly-prodcuty and distracting).

> Adopting Mithril also opened me up to a whole list of lesser known but > vigorously thought through projects like BSS, Patchinko and the beautiful > Meiosis pattern which changed the way I went about developing resulting in > far better productivity.

> Adopting Mithril also opened me up to a whole list of lesser known but > vigorously thought through projects like BSS, Patchinko and the beautiful > Meiosis pattern which changed the way I went about developing resulting in > far better productivity.

Thanks a ton for the references, looking up all those things right now, looks like more pieces of the Mithril ecosystem that I've never heard of. Patchinko looks super useful (I'm surprised I've never needed something like this in the past...), and Meiosis looks like a simpler version of the reactive/flux pattern, and looks interesting to me since it's cross-framework!

<comment><USER38> So most of these projects are all maintained by members of the Mithril team or heavy contributors of Mithril, so you can trust they are created with care and have been thoroughly thought through.

You should definitely join the Gitter chat for Mithril. It's a very active channel and a little lesser known part of the internet where you will get a constant flow of engaged developers of all levels discussing Mithril and also where some of the core team discuss concepts, roadmaps, ideas and drop knowledge.

</comment></comment></comment></comment><comment><USER39> I am getting a 404.

<comment><USER40> Works for me.</comment></comment>


Rescuing my tiny videos from Vine - <AUTHOR> https://martymcgui.re/2016/12/05/224243/ <comment><USER2> youtube-dl supports vine: [https://rg3.github.io/youtube- dl/supportedsites.html](https://rg3.github.io/youtube-dl/supportedsites.html)

<comment><USER3> And if you need an online tool while away from your computer, [http://getvideo.at/](http://getvideo.at/) is running on youtube-dl. It will parse the given webpage and list out direct download links.

</comment></comment><comment><USER4> Is there a service yet which lets you enter your vine username and receive a zip of your videos? (edit: looks like twitter is planning on building one)

<comment><USER5> I don't know if there is a service out there yet, but here is a script in python to download all your posted vines and liked vines. You just need to download some dependencies and replace the placeholders with your email and password.

[https://gist.github.com/davoclavo/1567b3da0f6aa19019c0deb574...](https://gist.github.com/davoclavo/1567b3da0f6aa19019c0deb574fa783e)

</comment></comment><comment><AUTHOR> An awesome and detailed post with code to liberate all of one's data from the dying social silo known as Vine.</comment>


Quashing the Self-Improvement Urge - <AUTHOR> http://zenhabits.net/improve/

<comment><USER2> This is wise advice. I have found my satisfaction with life greatly improve once I became content with about 90% of my life and just focused on improvement in one or two specific areas.

I wouldn't say universal contentment is the goal, but I wouldn't endorse universal striving.

It all comes down to prioritizing under life's unfortunate constraints (money, time, genetics, etc).</comment>


One Week with Facebook Ads: My Experience  - <AUTHOR> http://erikdungan.bigfolioblog.com/weblog/post/80235

<comment><USER2> 0.25% CTR is pretty bad.

My experience with Facebook Ads is that you should target the ads as closely as possible or you are wasting your money. Facebook has a ridiculous amount of inventory and a user base who don't like clicking on ads, especially irrelevant ones.

</comment><comment><USER3> > _One strange thing I noticed was that Google Analytics showed less traffic > from facebook.com than Facebook reported in clicks. The difference was about > 10 clicks per day._

Seriously? That sounds rather suspicious. Anyone inside facebook here that can comment as to why this is so?

<comment><USER4> I wouldn't be surprised if 10 out of 543 people had JavaScript off, or Google Analytics failed to load in time.

<comment><USER3> Aha! That's no doubt the answer I'm sure.</comment></comment></comment>