Aging Japan Wants Automation, Not Immigration - <AUTHOR> https://www.bloomberg.com/view/articles/2017-08-22/aging-japan-wants-automation-not-immigration <comment><USER2> Japan is at the forefront of a post-industrial society. Much of the rest of the west would be in a similar position, if not for imported labor or outsourcing labor.

China will be in a similar spot soon. Eventually all of the world will be where they are.

The things and lessons they learn and discover will be useful to other mature economies soon enough.

The headway will make them leaders in innovating in this area of the economy. Automation will only keep on advancing and displacing jobs --Japan's workforce and jobs are in sync in this regard and if they thread it right, the reduction in human jobs will diminish with the number of able workers.

<comment><USER3> There seem to be two contradictory narratives: one, that rich Western societies are aging and need to make up for a big shortage of workers; and two, that automation has killed and will kill millions of jobs. Probably both trends are true, but each one pulls in the opposite direction for the demand for labor.

Maybe things aren't as bad as people fear on either side.

<comment><USER4> Because the goal of mass immigration of unskilled workers isn't what's best for the country, its to bring in people who will be reliant on the government and thus always vote for more government, thus further consolidating power. Also has the benefit of driving wages down resulting in more natives being reliant on government.

If we really needed more workers why wouldn't we incentivize our own citizens to have kids instead of spending that money on refugees and immigrants?

<comment><USER5> > why wouldn't we incentivize our own citizens to have kids

I am assuming by "incentivize" you meaning tax payer funded policies so are you ready to pay more taxes?

If you are ready to pay more taxes but what about people who dont want kids.

<comment><USER2> Singapore, a multicultural society, has a pretty progressive baby bonus[1], among other countries. They think that's what works best for their society. They could import labor, but they prefer do it their way. It seems to work for them.

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

<comment><USER6> No it's bad for society. Kids cost money, immigrants earn money. Penalize breeding, encourage immigration.

<comment><USER4> Will those uneducated immigrants earn money when they are no longer needed due to automation? If you have to pay to educate them anyway why not just have your population have kids instead of importing?

<comment><USER6> The uneducated ones we need to fill the jobs that educated locals won't do and won't be automated in their lifetimes. But a lot of them are educated and we need them too.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> This is an opinion piece backed up with practically no information whatsoever.

If you want to know about immigration policy in Japan, you need look no further Japan's ministry of foreign affairs website. For example, here are the categories where you can get a long term visa [0]

You will notice there is a points system [1]. You need 70 points to get in. A degree gives you 10 points. A salary of ~$100K gives you 40 points. Being under 30 gives you 15 points. Having 5 years of experience gives you 10 points. N1 on JLTP gives you 15 points.

I mean, it's _ridiculous_. And this is a 5 year visa with relaxed permanent residence requirements, ability to sponsor your parents, ability to work in _any_ field (even jobs that aren't related to your skill set!!!). The list goes on!

And if by some incredibly unfortunate circumstance you can't qualify for that, there are still over 10 categories where you basically only need a relevant university degree and a job offer for a 3 year visa.

And if that isn't enough, you can start a company in Japan with about ~$50K and sponsor a business visa for yourself.

My wife is Japanese and I'm here on a spousal visa. The application process took 1 week and was free. I am also eligible for relaxed permanent residence status.

Seriously, compare this to your home country and then come back and tell me that Japan doesn't want immigration.

Now if you want to know why Japan doesn't have a lot of immigration, it's because it is difficult for foreigners to live here if they can't speak Japanese and/or they can't accept Japanese culture. But as far as the government is concerned, the red carpet has been rolled out for a _long_ time. If you have an established company in many foreign countries and wish to open a branch office in Japan (so that you can transfer people here), the government will even give you free assistance!

[0] - [http://www.mofa.go.jp/j_info/visit/visa/long/index.html](http://www.mofa.go.jp/j_info/visit/visa/long/index.html) [1] - [http://www.immi- moj.go.jp/newimmiact_3/en/pdf/point_calculat...](http://www.immi- moj.go.jp/newimmiact_3/en/pdf/point_calculation_forms.pdf)

<comment><USER8> I just got a (admittedly: limited to 2 years for now, bound to the corporate sponsor) working visa for Singapore. Looking at your description:

\- I don't have a recognized degree (I do, but .. it's complicated)

\- I never had, nor will for the foreseeable future, reach 100k USD (DE doesn't pay like that, neither will SG in the future based on sources like Glassdoor etc.)

\- I'm over 30

I guess what I'm trying to say is: For me the list you provided is merely a curiosity and doesn't feel like I would have a good way to migrate to Japan if I'd like to. It was trivial for Singapore. "Incredibly unfortunate circumstances" seem to imply that you believe that nearly anyone can check all the boxes. Which for the salary requirement alone seems rather insane from my European point of view.

That said: I have no clue about immigration requirements for Germany, so I cannot compare Japan to my home country. DE might be worse.

<comment><USER9> Indeed, the kind of visa discussed is actually one of the more difficult ones to get. Most people come in on category based visas which have more restrictions, but more lax requirements. Usually a university degree (for young folks) or a bunch of industry experience (for folks like yourself) is enough. No big salary or young age required.

</comment></comment></comment><comment><USER10> Here's a more in-depth look at the issue of immigration vs automation as it relates to Japan, from 2 Japanese economists: [http://www.japanpolicyforum.jp/archives/economy/pt2014103018...](http://www.japanpolicyforum.jp/archives/economy/pt20141030182705.html)

My commentary with support from that article follows:

A country with the population of Japan has no chance of maintaining a higher absolute GDP than countries with multiples of their population and more land to expand population. A policy to try to maintain their status in the world in terms of GDP is just silly.

If, however, Japan is more interested in the well-being of their population than some sort of international power-play, then this is the route to go. Population growth has no correlation to GDP per capita, so what's the point of increasing immigration of low-skilled workers? The upside is minimal, and the potential downside is unknown and unbounded.

I've been living in Japan for a little over 2 years now, and haven't talked to anyone who is worried about the long-term prospects of Japan's economy. There are structural changes that can and probably should be made, as outlined in the link above, but the country is not on some death-spiral like a lot of Western media would have you believe.

Is Japan a magical land of far-advanced technology, delicious food, safe and clean cities, beautiful countrysides, and amazing public transportation? Actually, yes; the "far-advanced technology" part just doesn't extend to mass- market consumer electronics in the same way any more.

<comment><USER11> > Is Japan a magical land of far-advanced technology

Is the technology really that far advanced. I understand it was in the 80s maybe? None of the devices I have are made by Japanese companies. None of the software I use is developed in Japan primarily. My car is but that's about it, but I picked it because of reliability not because of high tech features.

<comment><USER12> Software development is still viewed as being a 'lesser' or 'menial' career in Japan by larger corporations. That's why you see so little software come out of Japan these days and also why so many Japanese websites are disasters of design.

Granted this has been slowly changing because of startups spinning up as well as foreign company HQs. Still, wages for developers in Japan are terribly low in most scenarios.

<comment><USER13> Something to keep in mind is that "software" (usually meaning system integration) is distinct from "web services companies" in Japan.

They've made significant headway in the latter at least for consumer services.

</comment></comment></comment></comment><comment><USER14> Automation has changed from when Japan was on top. The focus is now on software and open collaboration in a globalized society, not hardware built by factory workers with proprietary standards (looking at you, FeliCa)

China may surpass Japan in the automation/AI sphere. Lots of young, English- speaking, western-educated workers, plus the PRC has already innovated so much in manufacturing, shipbuilding, etc., and an ecosystem willing to splash cash on daring startups (albeit a lot of that is state funding, and you need CCP connections to come up in the Chinese startup world) in ways that leave Japan in the dust. Look at how Nvidia is working in China, look at the rise of Aliyun, Baidu Cloud and Tencent Cloud.

The only Japanese companies I know that are geared for automation for the new economy are companies like Mujin, LeapMind and Preferred Networks.

As a side note, the fact that Japan has managed zero-growth despite a rapidly shrinking, aging population; almost zero immigration; and roughly the same economic policy as from the 1980, is nothing short of a Herculean endeavor. I wonder what Japan is going to do when the population decline really gets in gear around 2040.

<comment><USER15> Why is total GDP the correct metric, if per capita GDP is on the rise?

<comment><USER14> The provincial government in my home province of British Columbia, Canada, is developing a genuine progress indicator (GPI) to replace the GDP metric, which was the idea of the BC Green Party. The point made here is that GDP is a very imperfect solution. Christy Clark may have boasted about BC's booming economy by pointing to GDP numbers, but do they explain the whole story?

I know that's neither here nor there, however.

</comment></comment></comment><comment> temp-dude-87844 Japan has never been one to shy away from high-tech industries, and as the article notes, aesthetic sensibilities towards kawaii robots make this a natural progression for a high-tech, ethnically homogeneous, aging nation.

Although Japan was once an imperial power, its reconciliation with its past has not included a transition to a multicultural post-colonial state promoted by intellectuals and practiced by widespread (and largely economic) migration from former colonies to the home country at the seat of power, as it has occurred in the case of most other imperial powers. The difference being, the places where this transition _did_ take place had been colonial empires for longer, and had for centuries notions of nationhood derived from shared values more so than shared ethnicity.

<comment><USER16> Germany comes to mind as a counterexample: a homogenous nation until the late 1950s, with no colonies to speak of, and jus sanguinis. Yet it transition to a functioning, diverse society today.

And Japan is arguably paying a steep price for keeping their blood oh-so-pure: it's a society frozen in tradition and fear, with an economy in what is essentially a 20-year recession.

Making robots care for the elderly will just be another step in the dehumanisation of that society, indeed. It's the coup the grace for a generation that replaced social life with "being in the office" and love life with blow-up dolls and pornography.

<comment><USER2> I think you're projecting western values on Japan.

While we may see "dehumanization" they don't. Where you see a pornography fetish, they see it as an extension of their sexuality. For them it's progress. They have valued tradition and will continue to do so. It's not an ephemeral value they hold.

Germany found a different path. It does not necessarily mean it's the one true path.

And, long term, all societies will face the same issues. Some sooner, some much later --but face it they will.

<comment><USER16> I'm pretty sure the need for social interactions with other people is somewhat central to being human, and not a trait of culture. That's why humans are often called "social animals".

The suicide rate in japan being 3x European levels also seems to point at something being amiss, although that may indeed be an artefact of culture.

</comment></comment></comment></comment><comment><USER17> Hasn't this been the case since the 1980's?

[http://sloanreview.mit.edu/article/manufacturing- innovation-...](http://sloanreview.mit.edu/article/manufacturing-innovation- lessons-from-the-japanese-auto-industry/)

</comment><comment><USER18> An idea: Some blue-collar workers displaced by factory automation could be retrained to maintain and repair robots used in healthcare and home assistance.

As developed nations age, there will be increasing needs for healthcare workers including those for home assistance. Since the supply of people wanting the jobs might be limited and many blue-collar workers tend to balk at taking pink-collar jobs, robots could be the intermediary that satisfies both the supply for services and demand for jobs.

<comment><USER19> The notion of retaining workers to maintain the robots that replaced them reminds me of a quip from the sci-fi book series The Expanse. One of the characters, a space vessel's engineer, remarks that hundreds of years ago on Earth (today) he'd be a nuclear physicist, but in his time he's just a mechanic.

</comment></comment><comment><USER20> I think this is a brilliant solution for them because of the way their country is setup. (Strong culture with extremely homogeneous population and low birth rate) I really do think a lot of what makes japan special would go away with too much immigration. That being said, America is the opposite and automation would hurt us and so would restricting immigration.

<comment><USER21> Why would automation hurt us?

<comment><USER22> Heck, how does restricting immigration hurt us?

</comment></comment></comment><comment><USER23> This explains a lot of recent moves by SoftBank.

</comment><comment><USER6> "One small manufacturer insisted that immigration would dilute Japan's homogeneous society. " Good, that's exactly what Japan needs.

</comment><comment><USER24> Common sense. A large population is going to be a big liability going forward. The Anglosphere hasn't figured this out yet.

</comment><comment><USER25> Makes a lot of sense. Why risk their cultural homogeneity - something clearly valued by the majority of Japan - if there are technological solutions to increasing productivity?

Edit - why the downvotes?

<comment><USER2> I think people tend to project their western cultural framework onto Japan and see it not fitting well.

Much of east Asia is very internal-looking (China was the middle kingdom for a reason). They tend to keep to themselves as a society and value their values from their perspective --not as self-critical as other societies, in some ways. It's something anathema to a number of westerners.

So of course to some people it looks like Japan (or east Asia in general) is not "sharing" in their wealth with others as your implicit agreement is kind of a non-sequitur for some people.

Going on a tangent here, but for example, in India, Dalits will at times use English but primarily western philosophy to argue their position vis a vis the dominant castes because they lend themselves better to examine these questions.

</comment></comment><comment><USER26> At least it's better than paying for immigrants that forced their way into your country as the Germans are doing now.

<comment><USER6> Go away racist. Refugees need a safe place and germany needs fresh foreign blood to keep its society running. It's a win win. German children are going to take a long time before they start contributing and even then they will end up on Hartz IV before they accept a normal job.

<comment><USER27> > _Go away racist_

Please don't respond to a bad comment by violating the HN guidelines yourself. Indeed, please don't respond to bad comments at all. Flag them instead:

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

</comment></comment></comment><comment><USER28> Automation is no cure for Japan. Their influence is waning rapidly, in many sectors. I would say that, with an aging population, Japan is turning into a stale country, culture wise and economy wise alike.

<comment><USER29> I think the average Japanese person doesn't care about how stale outsiders think they are, and they certainly don't feel like they need a "cure." If anything, society here is reverting more to a norm after being in a massive economic bubble.

Really, it's honestly kind of freaky how often I see western media articles about how Japan needs to act now, or they're doomed to fail and their population will vanish. Yet I see nothing about Bulgaria losing 25% of its population in 25 years or Belgium needing to reevaluate its global image for fear of irrelevancy.

<comment><USER16> > If anything, society here is reverting more to a norm after being in a > massive economic bubble.

So, you're agreeing that Japan is on a long downward slope to economic and technological irrelevance, but you believe the average Japanese would rather accept this than immigration?

<comment><USER29> Japan is reverting to a state of being as technologically and economically irrelevant as Western European countries.

The most common thing I see on the news and hear people worry about is the violence going on in America and in the increasingly common European terror attacks. The attitude to immigration is only being solidified here, and none of the "but what about your GDP???" stuff matters to anyone but degree mill economists. The country is safe and stable, and population is coming down to a number that's more sustainable for a small, mountainous, mostly non-arable country. That's all that people really care about.

<comment><USER16> Here are a few things correlated with GDP. Note that we don't know the direction of causation, so either Japan's GDP is going sideways because corruption is on the rise–or they can expect corruption to rise because the economy is stagnating.

low levels of GDP and high levels of corruptions are correlated

poverty reduction and per capita income growth performances are correlated

economic freedom is correlated with income

Rule of law is correlated to GDP per person

There is only a partial correlation between democracy and economic growth but stronger correlation between democracy and level of GDP

As per capita income increases to around US$5,000 per annum, environmental quality falls, but then from around $8,000 per capita onwards, the environmental quality rises again

GDP and happiness is correlated

GDP per capita is correlated to percentage of population who donate to charity

GDP is correlated to individualism in a country

Wealthier countries tend to have less income inequality</comment></comment></comment></comment></comment>


Your Company Is Screwing Itself by Not Supporting Open Source Software - <AUTHOR> https://medium.com/@codebyjeff/your-company-is-screwing-itself-by-not-supporting-open-source-software-c0e58ff04629 <comment><USER2> The title should be changed to "OSS developers are being screwed over by companies". It's a fundamental clash of OSS principles and capitalism. At my company we don't use that much OSS, because we're in embedded, but I'm not aware of a slush fund, there's no way for a normal employee to make this happen. It's fundamental to capitalism that companies maximize profits. Individually it's always better to use OSS, but not pay for it. They'll pay only if they get something in return, which they wouldn't get otherwise.

OSS developers need to have split licenses between corporate and private use. Corporate use has licensing costs. Otherwise they don't get paid.

BTW the pre-fab wall makers also don't hand out the walls for free and ask for donations later. Because they'd get 0. Business is business.

<comment><USER3> No it shouldn't. The article is about businesses who waste time reinventing the wheel and writing their own string handling software. It's from a PoV os company self-interest, not OSS developer interest (which is fine).

<comment><USER2> Most of the article is about asking companies to donate to OSS because they profit from it.

<comment><AUTHOR> Thank you. Yes, that's what it's about.

However, it's not so important to get _companies_ to directly donate if the developers who _use_ it push for the donations.

Contrary to Supreme Court rulings, _companies_ aren't decision makers, people are.</comment></comment></comment></comment>


Wine 5.7 Released - <AUTHOR> https://www.winehq.org/announce/5.7 <comment><USER2> It's really impressive the amount of progress on Wine, specifically in the past 3-5 years. I mostly thank Valve and the gaming community for much of this. Not sure if any of this came out of Google's Stadia. But these efforts really make gaming on Linux more possible. Proton in particular far easier for most than anything that came before.

Not everything runs, but Linux on the desktop is definitely a real option for many more people today than even a couple years ago.

<comment><USER3> Stadia doesn't use Wine-- it's Vulkan on Linux directly.

<comment><USER2> Thanks... I just know quite a few developments came out of Google's efforts.. and wasn't sure if any of the game studios were using wine to package their games on Stadia, which would still be Linux and Vulkan.

<comment><USER4> The only relation of Google and Wine I can find is them paying CodeWeavers to bring Picasa and Photoshop CS2 to Linux, that was 12 years ago.

</comment></comment></comment></comment><comment><USER5> "Beginnings of a USB device driver."

I would love to be able to run the manufacturer's program for a data logger and a pulse oximeter under wine. Hopefully this is what they are aiming for (maybe I should try it already?). I'm guessing there are a bunch of devices like this.

</comment><comment><USER6> preface - I am directing my displeasure at Apple, not the fantastic team at wine for creating this as an open source project.

I love wine and it runs fantastically well on both my personal mac and on my fedora workstation. I run a lot of old school engineering apps (think like MIPS simulators) that doesn't run on any other platform so wine makes it easy for me to both be productive at work since I am much more efficient on a command line and allows me to WFH occasionally so that I can spend time with my family.

Now my rant - since upgrading to Catalina last week, I've been completely unable to run wine at any way shape and form due to Apple's mandate that all 32bit programs be barred from running on Catalina. Guess what runs exclusively on 32 bit?

I tried everything including compiling my own wine64 wrapper but it doesn't work at all since the underlying app is still win32. I know there is a crossover product that works but unfortunately that's not on the cards due to budget issues.

Honest question: why is it so hard to get wine32 working on Catalina and why doesn't Catalina have an option to run 32bit apps? Its been out since October 2019 so one will have thought a solution will have surfaced.

<comment><USER7> The last released Macs that were not 64-bit use Intel Core Solo or Intel Core Duo processors, and those haven't been able to upgrade past Mac OS X 10.6 Snow Leopard, released over a decade ago in 2009. According to Apple's definitions of "vintage" and "obsolete", this puts these Macs well into the "obsolete" category.

The upside to removing 32-bit is shrinking the size of the system, removing complexity, shrinking the testing matrix when modifying system frameworks, etc.

The writing has been on the wall for 32-bit apps for a long time, including warning users when launching a 32-bit app that it would cease working, and showing users a list of incompatible software when upgrading to Catalina. App developers were incentivized to release updates to their apps (using 64-bit toolchains that have been available since 2007 and before), and users were given warnings about upgrading if they need 32-bit compatibility.

Meanwhile, over the past decade there has been significant improvement in virtualization technologies, which allow you to run 32-bit operating systems with great performance. You can run Windows XP in a VM or WINE in a Docker container (which runs inside a Linux VM on macOS).

<comment><USER8> If only we could have had this conversation for all the software we use over a lifetime and get used to or very productive with...

<< Hello, Mr/Ms Shoestring Budget software developer in 2003... Could you write your (MIPS simulator, CAD app, VLSI Design System) in 64 bit code so when Goobuntu, Crapple and Microslop remove support for 32 bit apps I'll still be able to use your software? Pretty please? >>

<comment><USER9> A conversation requires not just a request but also a response. Here it is:

<< No thanks, we're not interested in investing effort in making sure you can use our software on operating systems newly released 17 years from now. Please fund our efforts by purchasing a new version once every 10 years. >>

<comment><USER8> That doesn't help if the company went out of business in the meantime.

<comment><USER9> What does it matter? Companies don't build software to last forever and they especially do not care about what happens after they go out of business.

Things don't last forever. Software vendors won't support everything forever. Middleware and operating system vendors won't keep the albatross of supporting old things around forever.

If you want, you can keep running an old version of Mac OS X as long as you want. Just don't expect Apple to support it.

</comment></comment></comment></comment></comment></comment><comment><USER10> Can someone give a few characteristic, uniformed-user-oriented examples of what can be done with Wine 5.7 that was not achievable before? Or of important apps that will now work with Wine?

</comment><comment><USER11> When should we expect a release for Ubuntu 20.04?</comment>


Unioncy – All your things in one place - <AUTHOR> https://unioncy.com/ <comment><USER2> Nikunj, thanks for sharing Unioncy. Would be great to hear what you think about it.</comment>


Name to a number - <AUTHOR> https://correspondent.afp.com/name-number <comment><USER2> This is probably vaguely off-topic. But I feel that the design of the newspaper's website helped somewhat with the article connecting with me. I don't think I would have paid as much attention if the website was as saturated with adverts as, say, the Washington Post or the New Yorker, or any other of the many websites with banners, popups, text-obscuring dialogues with crap like "click here to read more", "I see you're using an ad-blocker!", etc. (I actually turned off my ad-blocker to see if it was just me, but no, my ad- blocker only found one thing to block, and I still can't figure out what it was).

Not only the lack of adverts, but the framing of the photographs, the way that it centers the article (access to the rest of the site has been put in the background (You know, where it belongs)). All of this I feel helped me to focus on the article, which allowed me to connect better with it and remember it better.

I wonder if websites will eventually get better at this and become as classy as this one, or if things will just deteriorate further into a horrible mess.

Just my 2 pennies.

<comment><USER3> If only you could give those two pennies directly and literally to the site, as otherwise classy has apparent no chance at profit.

<comment><USER2> According to another hackernews they're actually nationalised, so they don't need funding for profit whatsoever.</comment></comment></comment>


State of JavaScript 2019 - <AUTHOR> https://2019.stateofjs.com/ <comment><USER2> Wow, 39.9% of respondents mark themselves as "Expert" at CSS. I've been doing front-end in various guises for 12 years and I would only rank myself maybe 5 or 6 out of 10.

As I've gotten more experienced in my career I've become more aware of what I don't know as opposed to what I do know.

It's funny that "Advanced" is mastering animations and transitions whereas "Expert" is being able to develop a full-front end consistently. I know many people that can build a front end, myself included but are nowhere near mastering anything, especially animations and css transitions.

I write this in jest of course. As we all know, self-assessment is about as reliable as...

<comment><USER3> Half of my income is from training people in JS and Python. I have 50% of those missions that are requested to be "advanced" courses.

The vast majority of the participants are not up to the task. They are paid professionnals, but they consistently overestimate they level, skills and needs. They often are not very good, and of course, they don't know what they don't know.

So I always check for that first, and rewrite my course on the fly to include the untold pre-requisites I identify. I don't tell them I do this to avoid making them feel bad. Nobody wants to hear "dude, you wanna learn react and you never used an arrow function, wtf ?" even if being comfy with JS is a listed requirement on the site.

Bottom line: most devs are not experts, and don't have the ability to assess that. But more importantly, it's enough for them to be productive and most industries don't need more.

<comment><USER4> > you wanna learn react and you never used an arrow function, wtf

At least in the early days, using React was the first time most people would be exposed to webpack/babel, so it was also their first exposure to the newer JS features.

<comment><USER3> But you didn't need arrow functions at the time because createClass autobind this and you used methods. Now with extends and hooks, it would be a pain.

Besides, it's alright to learn es6 and 7 with react if you have time, but if your company pays a $10k react training in a 3 days session, you better have the pre-requisites right.

And at the very least, don't pretend to be "an expert" in 2019 if you don't know es6. Every tutorials for beginers include them now. Every docs of every libs use them.

You don't have to be an expert. It's legitimate. I don't advertise myself as a JS expert despite being pretty good at it.

But it looks better on the resume, and once you are hired on that assumption, you can't go back. Next time the company asks, you say expert again.

</comment></comment></comment></comment><comment><USER5> So sad to see Meteor solidly in the avoid quadrant, but it seems deserved. Meteor is what I learned how to do web development with back in 2015, and it was _fun_. It didn't take much to make stuff happen, and the baked-in live sync was like magic. I'm still eager to whip Meteor out for proof of concept prototyping because of how convenient it is to have a schemaless database and a framework that abstracts away HTTP, but for one thing I feel Meteor's big bet on Mongo hasn't paid off.

Also surprised to see ClojureScript's satisfaction rate at 60%. In the past year or two it's become much easier to use NPM packages, which was IMO the last remaining huge missing piece. It's now a great language for web development, providing what JS couldn't: a rich standard library with, _ahem_ , _consistent_ API's, a strong FP flair with excellent immutable data structures built in, and maybe most critically of all, a somewhat constrained macro system that allows users to write and distribute third-party libraries for syntax that in other languages would have required an extension of the language standard.

All of that is (I think) desirable by anyone unless you're hardcore anti-FP (with the one exception, I guess, that macros can be and are abused, though I haven't seen it very often in the CLJS ecosystem). So why hasn't ClojureScript seen more adoption? It's the age-old curse of Lisp, I guess: those dang old parentheses which decades of CS curricula taught in ALGOL descendents have rendered foreign and horrifying.

<comment><USER6> Where did you see a ClojureScript satisfaction rating? All I'm seeing is the have you used it before/heard of it question.

<comment><USER7> [https://2019.stateofjs.com/overview/](https://2019.stateofjs.com/overview/)

On the 60% line

<comment><USER6> I see it now, thanks!

</comment></comment></comment></comment><comment><USER8> The data visualization is often awful and misleading. For instance, consider [https://2019.stateofjs.com/javascript- flavors/](https://2019.stateofjs.com/javascript-flavors/)

1\. The first graph shows "Rankings". I strongly doubt rankings are more importants than values. When Clojurescript goes from 67% to 72%, this increase is shown as a ranking decrease because Reason was introduced at a higher ranking.

2\. The meaning of the data is unclear, since the exact questions and proposed answers are not shown.

3\. Some measures have varying populations, so ranking them is absurd. Supposing that 2% of people use A and 80% use B, what does ranking satisfaction with A above satisfaction with B mean? Since the uncertainty is huge on the A measure, the "real" ranking is not known.

4\. Having to click in order to switch the measure shown is strange. The three measures should be display on three consecutive graphs.

5\. The Categories graph is unreadable for a slightly color-blind like me.

6\. The Categories segments aggregate data over 2 levels which makes them unreadable. First levels: Used, Heard, Unheard. Second levels should be computed relatively to their containers. Who cares if 1.8 % of users would not use Elm again? What is important is that ~28% (1.8/(4.7+1.8)) of those who used Elm would prefer not to do so again.

<comment><USER9> I think the best visualization overall is the first one on [https://2019.stateofjs.com/overview/](https://2019.stateofjs.com/overview/).

Seeing the trajectory of each piece of tech gives a lot of insight on overall trends. For example, I was thinking of learning a bit of the more recent Angular (last time I used it was Angular 1.x, before React was a thing), but now I think I'll look more into Vue.js, as its trajectory looks much better.

</comment></comment><comment><USER10> Wow, just learned of Svelte from this. After reading their explanatory blog post and coming upon this blurb:

      That all changed with the advent of hooks [React and Vue],
      which handle state in a very different fashion. Many
      frameworks started experimenting with their own
      implementations of hooks, but we quickly concluded it
      wasn't a direction we wanted to go in
      ...
      We can just use the language. Updating some count value — and
      all the things that depend on it — should be as simple as
      this:

        count += 1;

That's _super_ exciting to me, as it puts the emphasis back on solving the task at hand and instead of framework nuances around state management. Will definitely be keeping my eyes on it.

[https://svelte.dev/blog/svelte-3-rethinking- reactivity](https://svelte.dev/blog/svelte-3-rethinking-reactivity)

<comment><USER11> Svelte seems promising. I think it's a natural evolution from what I think is an over focus on FP and purity in React, to a more natural and intuitive DX without significant drawbacks.

Svelte does have an irritating wart IMO, citing their tutorial:

         Because Svelte's reactivity is triggered by assignments, using array
         methods like push and splice won't automatically cause updates.

So for reference types that are mutated in place you need to do something like:

         numbers.push(numbers.length + 1);
         numbers = numbers;

Or:

         numbers = [...numbers, numbers.length + 1];

This looks like a leaky abstraction to me since it forces the developer to work according to the implementation details. Don't know how easy it would be to fix this.

<comment><USER12> To be fair, React has the same "wart". React is not guaranteed to work properly if you do:

      numbers = this.state.numbers;
      numbers.push(numbers.length + 1);
      this.setState({ numbers: numbers });

React docs here: [https://reactjs.org/tutorial/tutorial.html#why- immutability-...](https://reactjs.org/tutorial/tutorial.html#why-immutability- is-important)

Similar docs for redux: [https://redux.js.org/recipes/structuring- reducers/immutable-...](https://redux.js.org/recipes/structuring- reducers/immutable-update-patterns)

There's no good way around it without doing deep equality checks everywhere which is not reasonable.

<comment><USER11> Since Svelte is a compiler I was thinking they could wrap the exported variables in an observable of some sort and make any method call on the reference variable trigger a value update behind the scenes. I have now idea how costly/complex that would be though.

Also, maybe it's a conscious choice and they want to make any data update explicit with reassignment.

</comment></comment></comment></comment><comment><USER13> I'm surprised to see Angular drop in ratings and rank so poorly compared to React. I personally prefer Angular myself because it's (a) opiniated and (b) has everything included (HTTP REST calls, Material UI, etc). Just curious why so many people prefer React and mark it so positively.

<comment><USER14> Angular ng-is ng-very ng-opinionated and requires a ton of boilerplate knowledge. It requires typescript knowledge, and I've noticed that (finally!) a lot of developers are realising that typescript actually doesn't make life easier at all.

React, on the other hand, is a very intuitive library instead of an all- encompassing framework. You can easily setup a React application in a few seconds and get started, adding whatever you want as you go.

The JSX syntax is infinitely more intuitive compared to the Angular way of doing things. Which also gets me to the point of Angular having a specific way of doing things, "the Angular way".

With React there's less thinking required to get things done. The learning curve is steep (as in: you pick up the knowledge quicker) because the amount of information to take in is relatively low.

Angular takes months to master. It's very opinionated. And it requires typescript.

I for one hate typescript with the passion of a thousand suns. I know it very well because I have to if I want to keep my job, but it's so freaking unnecessary...

<comment><USER15> Typescript doesn't make things easier, and react is intuitive? You know April fool's is still a few months away right?

<comment><USER14> TypeScript slows down a project. Nobody seems to ever point out what benefits it supposedly offers.

My claim: TypeScript offers no benefit. Ever. That's 2 years of fulltime TS experience talking and 18 years of fulltime JavaScript experience, on top of a whole bunch of full stack (Java and .Net with C#) experience.

I think the popularity of TS is going to decline. And I think it's only popular because of the influx of backend developers coming into the frontend. Additionally, because "everybody does it so it must be professional so I should like it".

As for React, well, great argument, I guess?

<comment><USER15> Slows down what?

Compile times? By a small amount sure, but with the incremental compilation we're talking maybe a few tens of seconds max. Any longer and you need to look at improving your build dependencies for better parallelism, and upgrading your hardware.

Development time? Types reduce mental overhead and abstraction for the developer, speeding up development.

Run time? Variables with types that stay static execute faster in JS engines.

Types keep code maintainable, and protect against any accidentally implicit conversions (rife in JS). Types still exist whether you define them or not, so being explicit gives the maintainer of your code much less mental overhead when working with your code. Knowing the contract that a function follows allows them to skip over any assumptions and know exactly what the code is meant to do. Break the contract, get a compile time error.

Anyone can write code, writing maintainable code is the real challenge. In my own 20 years experience this is always what separates the wheat from the chaff.

<comment><USER16> > writing maintainable code is the real challenge

If you think these same developers can't do it without TS, then you really haven't seen the sort of mess lesser developers make when they try with TS.

Unless the JavaScript developer has a strong background in C/C++/Java, they are going to truly fuck up a code base with TypeScript. I'm not making a static/dynamic typing argument here. I'm making an observation that thousands of developers that haven't seen what the hell a type even _is_ are now somehow expected to operate on the level of creating coherent abstractions throughout the code. Good luck with that, once your team starts allowing "any" and "ts- ignore" everywhere.

9 out of 10 JS developers I have worked with do not know how equality and object memory references work in JavaScript. They do not understand deep vs. shallow equality. They are barely aware of type coercion. When faced with a TypeScript error, their primary concern is shutting up the compiler. By any means necessary.

Getting typing correct is more nuanced than the pro-TypeScript group will ever admit, and TypeScript provides so many ways to dodge actual typing responsibility that it renders the whole exercise a colossal waste of time.

tl;dr: Good developers don't need TypeScript and bad developers pull good developers down with TypeScript.

<comment><USER15> I think I'm going to have make this my last comment as this is going in circles. I mean what is even your argument? Types exist whether you like it or not, implicitly or explicitly. You cannot get around this, it is simply a fact. When you have input parameters, or a return type, they follow a structure. That structure is a type. This is not nuance, this is just how things work.

'Good' developers is a subjective term, what is a good developer to you? Someone who can work without types? Wtf?

Anyway, I'll keep being productive with typed languages. You do you I guess.

</comment></comment></comment></comment></comment></comment></comment><comment><USER17> State of JS is always a fun and interesting survey, but I am wary about drawing conclusions from its results because of the self-selecting nature of the participants means they are probably not a representative sample of JS developers in general. They're inevitably going to trend towards English- speaking developers who read coding news sites, participate in social media.

<comment><USER18> Every year I glance at it, thinking maybe I will learn something about the state of JavaScript. Then I remember that it's a popularity contest and I get bored pretty quick.

I'm not sure why I should care what everyone else wants to learn. I guess it's worth finding out if there is a new popular framework this year. Sigh.

</comment></comment><comment><USER19> Interesting. React is the thing. But some trends are weird:

People ditch Cordova heavily, but also React Native and native apps. Electron rises to the top, although you can't build mobile apps with it that are distributed through the various stores.

So, what's filling the void for app development, if everything just went down?

<comment><USER20> Maybe Ionic with Capacitor?

<comment><USER19> Nah, Ionic goes down as well for whatever reason. I'm still all in on Stencil + Ionic/Core + Capacitor.

Maybe people use NativeScript, I don't know. Just found it interesting that the trend seems to go down for ALL mobile development tools.

</comment></comment></comment><comment><USER21> I dream of an alternate timeline in which today we would release "State of ClojureScript 2019" with Javascript being listed as a ClojureScript flavor :)

<comment><USER22> I expect we will still be talking about JavaScript in another twenty years.

</comment></comment><comment><USER23> Sad to see Ionic in the avoid category. Their latest release I thought was quite polished, and I've enjoyed using Capacitor rather than Cordova. I think the key to further success is breaking away from Cordova entirely, and expanding the native features supported in Capacitor. Right now I find myself having to use both due to some things not being implemented in Capacitor yet.

<comment><USER24> At this point with React Native (or even Flutter if we're considering things apart from JS) there really isn't a compelling reason to build anything in a Webview as far as I know. Also in my personal experience their support team members have been pretty impatient and passive aggressive in the Github issues tickets so I'm not entirely surprised that they're building something that the community has moved away from.

<comment><USER25> There are a ton of compelling reasons to build apps targeting mobile web views, and despite Ionic's poor showing on this survey, we are seeing a lot of serious apps and brands doing so and picking it explicitly because of those benefits.

Perhaps the biggest is the overlap with web dev tech, team skill makeup, and the hiring market for web devs being incredibly vibrant. Vast majority of teams have struggled to go native and build/hire those teams, and are instead excited about using the web devs they already have or taking advantage of that hiring market.

One trend that is really interesting is that many teams have decided they need to be prepared for a PWA future and can't afford to have two separate efforts to accomplish that (i.e. app store apps and PWA). They see Ionic as a way to do both and be ready for the expansion of PWA adoption which is early but happening fairly organically, and has some key enterprise benefits that make it attractive for those teams.

Sorry you had a bad experience on our github issues. We're a small team relative to the size of the community and have had to resort to automation and tooling to figure out signal from noise. It's been a constant process of iteration on that front.

</comment></comment></comment><comment><USER26> EmberJS should not be in the "avoid' section.. it is one of the most well thought-out framework which just gets the job done.. and it is a bit contra- indicatory that Ember guys are the highest paid.

<comment><USER14> Just the fact it uses Handlebars templates disqualifies it as a viable option for me. Handlebars is terrible to work with, especially once you're used to JSX type of options.

HBS = restrictive for nonsense reasons. The separations of Model, View, and Control really don't make sense anymore. It's outdated.

I've worked with it for years and I consider myself familiar with it up until 3 years ago, but I would never go back to EmberJS. And that's why the salaries are higher for Ember developers: they're rare.

<comment><USER27> > The separations of Model, View, and Control really don't make sense anymore. > It's outdated.

What ? why ? care to elaborate please ? and what do you use instead ? MVVM ?

<comment><USER28> Ember uses MVVM

<comment><USER27> Fair enough, but I still think its a stretch to call MVC "outdated". And "outdated" kind of has a hint of "bad" and "should not be used", hence the question.

<comment><USER28> Oh yeah I also don't agree with OP. Separation of concerns is good. JSX isn't perfect either.

This yearly js poll always brings out the fanboys. The amount of "heard of it but would never try it" responses demonstrates that it's just a popularity contest

</comment></comment></comment></comment></comment></comment><comment><USER29> The most interesting data in my opinion are the conflicting opinions on the overall state of the ecosystem:: [https://2019.stateofjs.com/opinions/](https://2019.stateofjs.com/opinions/)

While there is a sharp downtick of people who think that JavaScript is moving in the right directin, most agree that the overall situation in terms of complexity and velocity is getting better.

I don't have any explanation for this, but would agree: Developing in JavaScript feels easier to me than just a few years ago.

<comment><USER30> Generally have to agree there, but I do feel like there is a reason. ES6 modules (or typescript modules) and the simple fact that the variability is finally dropping:

It seems like there was one specific winner of all of the UI frameworks. React.

There is now pretty much one specific winner to package managers. Yarn.

There is one specific winner for language front-end: Typescript.

There are basically two front-end build tools left: Webpack and CRA (of which is basically a Webpack wrapper with babel and a million other things)

All of the latest npm packages are either coming with ES6 modules or, more interestingly either are completely written in Typescript or at least have @types now. And all that stuff helps people writing JS too.

<comment><USER31> Disagree on yarn - npm is still trying to keep up and the latest releases are doing well

Seems like within React, Redux/Apollo/plain is splitting the data layer again too

But the yarn/npm is a tiny difference and data layer is much more application specific

<comment><USER30> Redux is quickly being relegated to pile of don't use. I suspect 2020's survey result will show hooks to have completely destroyed redux.

<comment><USER32> Absolutely not the case. My own estimates are that around 50% of all React apps still use Redux, and the overall download numbers are continuing to increase consistently. I covered this in my Reactathon 2019 talk on "The State of Redux" [0], and my post "Redux - Not Dead Yet!" [1].

In addition, our new Redux Toolkit package [2] and React-Redux hooks API [3] are making it easier than ever to use Redux, and we've gotten a ton of very positive feedback from users who have adopted those APIs.

[0] [https://blog.isquaredsoftware.com/2019/03/presentation- state...](https://blog.isquaredsoftware.com/2019/03/presentation-state-of- redux/)

[1] [https://blog.isquaredsoftware.com/2018/03/redux-not-dead- yet...](https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet/)

[2] [https://redux-toolkit.js.org](https://redux-toolkit.js.org)

[3] [https://react-redux.js.org/api/hooks](https://react- redux.js.org/api/hooks)

</comment></comment></comment></comment></comment><comment><USER33> I find it kinda strange that Flow has been relegated to the write-in "Other Flavours" section so soon. I know that it has been trending downwards for a while (as TypeScript trends upwards), but it feels like that story's not quite over just yet even if the conclusion is foregone.

<comment><USER34> I think the name Facebook being attached to just about anything is a disadvantage, if there are other alternatives.

<comment><USER35> 3 out of 4 most liked technologies are actually from Facebook, so the name certainly doesn't seem to prevent success here..

<comment><USER34> I said if there are no alternatives. There was no alternative to React for a long time, and it gained much popularity and momentum.

But there are many alternatives to Flow.

<comment><USER35> > There was no alternative to React for a long time

Angular is 4 years older than React, and generally speaking front-end frameworks have been probably the single most competed/overcrowded area...

<comment><USER34> There was absolutely nothing like react at the time it came out, angular had none of its key features.

Today we have Vue and others are forming in other languages, but still today angular takes a very different approach to the front end. But react's breakthrough in the virtual dom management was totally new and really changed a lot of things in our industry.

</comment></comment></comment></comment></comment></comment><comment><USER35> Redux has the largest shift towards "negative opinion" out of all technologies. Did people just get fed up with the boilerplate or is there something else going on?

<comment><USER36> I started to realize that it just doesn't make a lot of sense. It doesn't actually have a real concept of how to deal with asynchronous things (like, http requests). You have to use weird things like redux-thunk, or god forbid redux-saga.

The event system is basically synchronous, and just changes data which will be displayed in the UI. Why use the event abstraction and all the boilerplate that entails for synchronous code which doesn't really benefit from events? It feels like a cargo cult.

What it boils down to is any function which will at some point change the UI needs to be written weird, so that it takes the "dispatch" function and calls "dispatch(nextFunctionEvent)" instead of "nextFunction()".

Lots of developers always implemented their own half-ass systems to eliminate some boilerplate by automatically defining events from handlers and state or vice versa or some other combination of the above.

React hooks have basically eliminated it's niche, and none to soon!

<comment><USER14> Oh, please. The projects I've recently worked on used only Hooks instead of Redux. It was a nightmare to deal with. Files with endless amounts of `useSomething`, you'd need to dive through 4 levels of files to get to something useful.

Redux offers a ton of tooling and developer comfort if you get it right. And getting it right means having proper pull request reviews.

There's a lot of developer tooling (debugging tools), too, and a lot of middleware available to plug and play and GO.

If you're just using Hooks and the Reducer and Context APIs you're setting yourself up for a lot of headaches down the road.

Redux already makes use of those technologies, but wraps it in something easy to consume with a LARGE community for support.

Not using Redux is setting yourself up for failure, in my opinion. I've seen it happen too many times in the past year...

</comment></comment></comment><comment><USER37> Glad to see lots of satisfied developers of Svelte as I am one. TBH though didn't expect to see it up there this quick.

</comment><comment><USER38> All the content aside, I just want to say that the presentation in State of JavaScript is magnificent. Some of these charts are superbly designed.

<comment> ing-norante Do you know what charting library has been used? These charts are indeed magnificent!

<comment><AUTHOR> D3. Incidentally, the creator of the overview chart [1] is also the author of an excellent book on D3 [2].

[1] [https://2019.stateofjs.com/overview/](https://2019.stateofjs.com/overview/)

[2] [https://www.newline.co/fullstack-d3](https://www.newline.co/fullstack-d3)

</comment></comment></comment><comment><USER39> It looks like more people need to learn about PureScript. I was happy to see it included this year though.

<comment><USER14> I really don't see the point of strong typed programming. JavaScript is fine without it. I've been working with TypeScript for a while now and I never think "this solves a problem I had!"

On the contrary, I constantly think "why..."

I feel strong typing JS is just a result of backend developers not questioning their upbringings and failing to use proper naming conventions, progressive enhancement in the form of JSDOC comments, proper unit tests, and proper peer reviewing processes.

Honestly, I don't get it. In all my 20 years as a professional web developer (full stack and specialising in the frontend for the past 12 years) I have never needed it...

I really don't understand the charm of it.

<comment><USER40> Aren't you describing exactly the problems types help with? Must be a reason why typed backend developers allegedly don't pay so much mind to:

\- "proper" naming conventions

\- JSDOC comments

\- unit tests

\- peer review

<comment><USER14> So, I've worked with JavaScript since 2001. Up until two years ago I never used a strong typed flavour on top of JS.

And I have never needed it. Not in big teams and not in small teams.

At work we recently did a timed programming problem solving competition. 20 Teams got 1 hour each to solve multiple levels of the same problems. Some teams used TypeScript.

None of the TypeScript teams got past level 5. All of the rest got past level 15.

I've been taking job applications where applicants get a limited amount of time to make their project. Let's say 20 hours, and it's a paid job. Everyone gets the same instructions.

Those who use TS are NEVER feature complete.

Coincidentally, those who use TS are also the ones who deliver one big DIV- soup and barely seem to understand CSS to begin with.

Strong typed JavaScript doesn't solve anything, in my opinion. And nobody has been able to convince me otherwise. TypeScript seems to be a reason for many developers to completely avoid documenting their code...

I mean, TSDOC or JSDOC allows you to write human-readable comments AND strong type your code _where it matters_. But they don't.

In any case, this article was a fun one to read:

[https://medium.com/javascript-scene/the-typescript- tax-132ff...](https://medium.com/javascript-scene/the-typescript- tax-132ff4cb175b)

<comment><USER41> > At work we recently did a timed programming problem solving competition.

Thankfully, real world software development is not done under arbitrary time constraints with teams competing on who can be first to complete a prototype. High quality software is very difficult to produce, and taking the time to adopt sane development practices that reduce cognitive load and detect bugs early on in the process often leads to maintainable codebases far beyond their prototype phase.

> In any case, this article was a fun one to read:

> [https://medium.com/javascript-scene/the-typescript- > tax-132ff...](https://medium.com/javascript-scene/the-typescript- > tax-132ff4cb175b)

It might be fun, but it reads like a movie review where the author gives arbitrary scores and somehow determines TypeScript's ROI based on that(?). The rest of the article mostly appeals to authority, as the author pushes his books, expertise and vast experience as proof, something you seem to be doing as well.

I feel like the mentioned "To Type or Not to Type" paper[1] is a more realistic study of the benefits of static typing, despite TS detecting "only" 15% of possible bugs. That's still 15% of bugs detected _during development_ that the programmer doesn't have to think about, and doesn't have to write thousands of very trivial tests to _maybe_ catch them locally or worse yet, in CI. This in practice never actually happens, let alone in code reviews!

Yes, static typing is not a panacea. But it's a tool that has high chances of producing higher quality software, something that is sorely needed in JS land.

[1]: [http://earlbarr.com/publications/typestudy.pdf](http://earlbarr.com/publications/typestudy.pdf)

<comment><USER42> Also, if you are using a statically typed language there are tools for property based testing like QuickCheck which eliminates the need to write those thousands of very trivial tests. I've seen one advertised for JavaScript but you can't guarantee it'll find everything thanks to typecasting.

</comment></comment></comment></comment></comment></comment><comment><USER43> How do 3.6% of respondents have more than 20 years of experience in TypeScript? And 21.7% have more than 10 years?

EDIT - They don't. They have 10+ years using JavaScript

TypeScript was released in 2012, sure there are early adopters and beta users, but I seriously doubt that nearly 22% of the people using TypeScript prior to it being released.

<comment><USER44> I believe the question you are referring to is asking what general level of experience TypeScript developers have. I too was a bit taken aback when I saw that. I had to reread the question. They should have done a better job making that clear in the chart for people just skimming the data. [https://2019.stateofjs.com/javascript- flavors/#javascript_fl...](https://2019.stateofjs.com/javascript- flavors/#javascript_flavors_experience_heatmap)

<comment><USER43> I completely missed that last sentence I guess.

<comment><USER45> Don't worry I added it later on to clarify.

</comment></comment></comment></comment><comment><USER46> Interesting that GraphQL is slowly gaining interest - I kind of thought the hype would fizzle out.

Good to also see Typescript making a foothold - it's a great alternative to pure JS.

<comment><USER47> I've rarely seen a technology so eagerly embraced by both bleeding edge tech enthusiasts and also enterprise behemoths (granted, tech behemoths, but still)

Having API documentation that is guaranteed not to go out of date with your code. Having a shared standard for describing your endpoints in a machine- consumable way. Being able to automatically generate typescript types from any schema (correct me if I'm wrong but I don't think there's any tooling that would do the same for arbitrary REST APIs). Being able to get autocompletion when writing queries for free ^ Those were all things I didn't know I needed until I started using them, and like Typescript, it feels painful to go back to not having them

<comment><USER48> You can write Swagger definitions to serve as contracts for your REST API. Swagger files are machine consumable and can be used to generate client SDK.

</comment></comment></comment><comment><USER49> Sad to see Atom take such a sharp decline. I've finally accepted the writing on the wall and began migrating to VS Code last week.

Thanks for all the memories, Atom! <3

</comment><comment><USER50> Charts in this report are very misleading. In some cases 6% difference is 2 times bigger on chart than 5% difference.

I'm aware they have no scale, are simplified etc, but chart format has very specific meaning and I believe that visualisations could be chosen in a better way.

<comment><USER51> I also noticed that on the Front End Frameworks awareness chart where react and angular flipped places from second to first even though they are both at 100% and then I saw that the vuejs was in 3rd place although it was also at 100%

</comment></comment><comment><USER52> Some of the data visualizations seem... strange. For example, on this page: [https://2019.stateofjs.com/front-end- frameworks/](https://2019.stateofjs.com/front-end-frameworks/)

We see React go 93/93/91/89, but the 89 circle is higher than 91 and at the same level as 93?

We see Vue go 87/91/91/87, but the second 91 is at a higher level than the first and the 87 is way below the first 87.

It seems like the React line should be straight, then dip down a little bit, then dip down a little bit more.

The vue line should go up a bit, then be straight, then dip back down to the original position.

</comment><comment><USER53> Something that jumps out to me in the demographics is how few respondents are from Japan (0.6% vs e.g. 5.1% from Germany). Does anyone have a good explanation?

<comment><USER54> I would be more interested as to why there is so little response from different demographics in the first place, even in Europe there's little response, except for a few countries.

It seems to me they mostly targeted English speaking countries, which would explain why Japan (and Asia in general) has such low response.

<comment><USER34> Except they excluded the country with the highest English language proficiency on the continent of Europe, the Netherlands. I suspect there's another reason.

<comment><USER45> (Survey author) The Netherlands doesn't have a large population, so it's never going to show up as a large part of the results. For next time it would be interesting to also let you toggle a relative view of participation vs population though.

<comment><USER34> It's a small country but with nearly half the population of Spain, and the most densely populated country in the world outside of Taiwan. Not to mention a massive development community (and one of the largest internet infrastructures in the world). So, more relevant than you'd think :)

<comment><USER54> Taiwan and The Netherlands are not even close to being the most densely populated countries in the world. Taiwan is 652/km² and Netherlands is 418/km². Compare that to Macau 20,286/km² or Singapore at 7,804/km².

But I agree that The Netherlands has a pretty big development community, and generally their English is fairly close to being native.

<comment><USER34> That's interesting, I've never done the math myself but I've seen it mentioned in many places that those are the two most densely populated countries in the world. Maybe they are only looking at the density in urban areas and excluding agricultural areas?

<comment><USER34> Oh, I see now that the stats I frequently hear cited exclude small city- states, and have a smallish threshold of somewhere in the 10 to 20,000,000 range for the country population.

<comment><USER54> That's still kinda surprising, compared to Singapore or Hong Kong, I never found Taipei or Amsterdam densely populated. But stats don't lie.

<comment><USER34> Dutch homes are pretty small and packed tightly together.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER55> What a holy mess is the landscape of the testing frameworks, even worse than that of the front end frameworks itself.

<comment><USER56> This is incredibly true. Testing libraries have not kept up with changes to JavaScript and web dev in general.

I long for a test runner that does as little magic as possible, doesn't try to be a build system and module loader, doesn't inject random libraries into the environment, it just loads URLs and reports back test results.

Test runners and assert libraries can massively slim down too if they because simple importable modules and don't modify the global environment or create plug-in systems or complex test lifecycles. Tests are async functions that resolve or reject, that's it.

<comment><USER57> I've used TAP and nodeTAP and always ran in to some problems. Then I gave AVA a try. Makes a pretty decent impression, though I have never used it in production.

It's simple enough, fast, and I have yet to run head-first in to some problem.

</comment></comment></comment><comment><USER58> Do other languages do these types of surveys? e.g. is there a "State of Python 2019"?

<comment><USER59> • Go 2019 — [https://blog.golang.org/survey2019](https://blog.golang.org/survey2019) _(survey only)_

• Go 2018 — [https://blog.golang.org/survey2018-results](https://blog.golang.org/survey2018-results)

• Go 2017 — [https://blog.golang.org/survey2017-results](https://blog.golang.org/survey2017-results)

• Go 2016 — [https://blog.golang.org/survey2016-results](https://blog.golang.org/survey2016-results)

• Rust 2018 — [https://blog.rust-lang.org/2018/11/27/Rust- survey-2018.html](https://blog.rust-lang.org/2018/11/27/Rust-survey-2018.html)

• Rust 2017 — [https://blog.rust-lang.org/2017/09/05/Rust-2017-Survey- Resul...](https://blog.rust-lang.org/2017/09/05/Rust-2017-Survey-Results.html)

• C++ Global Insights 2019 — [https://isocpp.org/files/papers/CppDevSurvey-2019-04-summary...](https://isocpp.org/files/papers/CppDevSurvey-2019-04-summary.pdf)

• C++ Global Insights 2018 — [https://isocpp.org/files/papers/CppDevSurvey-2018-02-summary...](https://isocpp.org/files/papers/CppDevSurvey-2018-02-summary.pdf)

• StackOverflow Insights 2019 — [https://insights.stackoverflow.com/survey/2019](https://insights.stackoverflow.com/survey/2019)

• StackOverflow Insights 2018 — [https://insights.stackoverflow.com/survey/2018](https://insights.stackoverflow.com/survey/2018)

• StackOverflow Insights 2017 — [https://insights.stackoverflow.com/survey/2017](https://insights.stackoverflow.com/survey/2017)

• StackOverflow Insights 2016 — [https://insights.stackoverflow.com/survey/2016](https://insights.stackoverflow.com/survey/2016)

• StackOverflow Insights 2015 — [https://insights.stackoverflow.com/survey/2015](https://insights.stackoverflow.com/survey/2015)

• IntelliJ, Dev Ecosystem (All) — [https://www.jetbrains.com/lp/devecosystem-2019/](https://www.jetbrains.com/lp/devecosystem-2019/)

• IntelliJ, Dev Ecosystem (Java) — [https://www.jetbrains.com/lp/devecosystem-2019/java/](https://www.jetbrains.com/lp/devecosystem-2019/java/)

• IntelliJ, Dev Ecosystem (C) — [https://www.jetbrains.com/lp/devecosystem-2019/c/](https://www.jetbrains.com/lp/devecosystem-2019/c/)

• IntelliJ, Dev Ecosystem (C++) — [https://www.jetbrains.com/lp/devecosystem-2019/cpp/](https://www.jetbrains.com/lp/devecosystem-2019/cpp/)

• IntelliJ, Dev Ecosystem (C#) — [https://www.jetbrains.com/lp/devecosystem-2019/csharp/](https://www.jetbrains.com/lp/devecosystem-2019/csharp/)

• IntelliJ, Dev Ecosystem (Go) — [https://www.jetbrains.com/lp/devecosystem-2019/go/](https://www.jetbrains.com/lp/devecosystem-2019/go/)

• IntelliJ, Dev Ecosystem (Javascript) — [https://www.jetbrains.com/lp/devecosystem-2019/javascript/](https://www.jetbrains.com/lp/devecosystem-2019/javascript/)

• IntelliJ, Dev Ecosystem (Kotlin) — [https://www.jetbrains.com/lp/devecosystem-2019/kotlin/](https://www.jetbrains.com/lp/devecosystem-2019/kotlin/)

• IntelliJ, Dev Ecosystem (PHP) — [https://www.jetbrains.com/lp/devecosystem-2019/php/](https://www.jetbrains.com/lp/devecosystem-2019/php/)

• IntelliJ, Dev Ecosystem (Python) — [https://www.jetbrains.com/lp/devecosystem-2019/python/](https://www.jetbrains.com/lp/devecosystem-2019/python/)

• IntelliJ, Dev Ecosystem (Ruby) — [https://www.jetbrains.com/lp/devecosystem-2019/ruby/](https://www.jetbrains.com/lp/devecosystem-2019/ruby/)

• IntelliJ, Dev Ecosystem (Rust) — [https://www.jetbrains.com/lp/devecosystem-2019/rust/](https://www.jetbrains.com/lp/devecosystem-2019/rust/)

• IntelliJ, Dev Ecosystem (Scala) — [https://www.jetbrains.com/lp/devecosystem-2019/scala/](https://www.jetbrains.com/lp/devecosystem-2019/scala/)

• IntelliJ, Dev Ecosystem (Swift & Objective-C) — [https://www.jetbrains.com/lp/devecosystem-2019/swift- objc/](https://www.jetbrains.com/lp/devecosystem-2019/swift-objc/)

<comment><USER60> > What do you use Python for? 37% programming web parsers / scrapers / > crawlers

I had no idea that much people were scraping the web. What are the most common applications? Users data collection, prices comparison, news aggregation...?

</comment></comment></comment><comment><USER61> I wonder why [https://markojs.com/](https://markojs.com/) never gets any traction. It wasn't listed in the front-end frameworks section, even in the free-form part.

</comment><comment><USER62> I didn't see a section on CSS-in-JS libraries (or did I miss it?). That seems to be one of the more divided areas as far as opinion is concerned.

<comment><USER63> Check out the State of CSS survey.

</comment></comment><comment><USER64> Seems like these "usage by" charts are probably not properly normalised(or how you call it?). Seems like these are showing for example how many users (earn 200k+ and use typescript) from all developers instead of percentage of TS users from 200K+ subgroup (which is much more interesting IMO), similar with experience and others.

</comment><comment><USER65> The "Changes Over Time" graph is awesome. It does an excellent job of conveying current status and change.

</comment><comment><USER66> They could have been more careful when designing the T-shirt: Both Elm and Ember are depicted as 'Em'.

</comment><comment><USER67> The heatmaps somehow look all wrong to me...? Almost every percentage has the 40+% color.

</comment><comment><USER68> i'm conflicted about this, but happy to see typescript overtaking the space. looking forward to the day we can all forget javascript the language as a bad dream and move on with javascript the vm.

</comment><comment><USER69> To me it seems like the winners of 2019 are:

\- GraphQL

\- Jest

</comment><comment><USER70> I wish "salary" wasn't the way people were asked about pay. Everyone I know who's over 200k only has 1xxk salary and like 100% of that in stock compensation. It'd give a different picture of what more people are making.

<comment><USER71> True. I wasn't sure how to interpret that section either. Compensation (or Total Compensation) might be a more interesting measure

</comment></comment><comment><USER72> "State of Javascript trends", yes.

Not much useful there for someone who just, you know, plods along with mere vanilla javascript.

And when I flipped to 'inverse' (because of the blinding white) ... there went the color scheme.

</comment><comment><USER73> Sad to see that CoffeeScript is not even listed.

</comment><comment><USER74> Opinions: "JavaScript is over-used online"

Strongly agree: 7.3%

Agree: 16.9%

How?

<comment><USER54> I think that for a lot of people, SPA + API is just the default, even though most of the time you can get away with a traditional MVC.

<comment><USER75> Even then MVC is almost always far more than needed to get the job done well... as are most frameworks.

I have noticed in the big corporate space many people writing this code are formally educated to write code in a very specific way that isn't quite JS- friendly and they need the extra boilerplate to make JS behave.

<comment><USER54> I see some of my colleagues (mostly front-end devs) don't even know how to write code that's not SPA + API, it's pretty sad. It over complicates every project, and like you said, MVC in most cases is enough.

</comment></comment></comment></comment><comment><USER76> 18.1% of respondents are working with TypeScript (released in 2013) for more than 10 years... Eh, sure

</comment><comment><USER77> The state of Javascript in 2019 is that it should be deprecated. I have never had more problems, undefined behavior, mysterious errors and malfunctions, dependency hell and generally shitty syntax as when dealing with Javascript. God, please, just destroy this language. The web needs something different, something not broken and flawed.

<comment><USER78> Tell me about it. I have tried my darndest to use types and tests to make things predictable. But there is always something that comes up.

It might be Javascript itself. It could also be the endless permutations of environments(browsers, resolutions, devices, etc) that we have to cater to.

Front End Web Development is hard.

<comment><USER77> It would be much easier without the moving target of new Javascript features that browsers have to keep up with. With a real, mature, nonbroken language there would be no need to add new features every year. Someone said that Python is badly suited for the web because not event-oriented, whatever that means. Well, JS didn't have async/await until recently, and there's still lots of code that uses promises, yet even promises aren't supported by ancient browsers. It would have been so much easier to use a language that had ironed its sophomore mistakes somewhere on the desktop, before the web limelight. Instead, they created an all-new "web language" to ensure decades of volatility and reinventing the wheel for all the world wide web...</comment></comment></comment>


Cocoon – A New Social Network - <AUTHOR> https://cocoon.com/ <comment><USER2> Not a single word about encryption on the front page. If this wants to be your most private social network for your close ones, it better step up. I/we chose Signal.

<comment><USER3> I started work on an open-source equivalent for the same motivation: [https://github.com/nileshtrivedi/family](https://github.com/nileshtrivedi/family)

Signal and Matrix are good but there is value in UX optimized for closed, intimate groups. Signal also requires phone numbers which, in certain nations, are becoming problematic.

</comment></comment><comment><USER4> Clicks -> sees app store link -> hits back button.

If your social media app isn't browser based first and foremost.. then I don't trust your judgement.

</comment><comment><USER5> Can you please explain how this differs from a WhatsApp or telegram group? Also why would most of my family use iPhone? I don't see the android version

<comment><USER6> That was my first thought as well. It's just a group on any of these messaging apps, apparently - as it is not even mentioned "anywhere", without encryption or any kind of strong privacy measures. Feels like an app hoping for enough traction followed by an acquisition or getting into data selling business.

</comment></comment><comment><USER7> Well congrats on the small videos, they are well done and show some highlights. For me it looks like a standard chat group in one of {Whatsapp,Signal,Telegram,Threema,Facebook,whatever-social-network-on-mobile- phones-look-like}, but with a few more lovely details. It's the details which make the difference, in the end.

Nevertheless, it looks that even kind-of-industry-standards such as end-to- end-encryption are not implemented. And I would like to see something without a central server. Something which makes matrix.org and friends more user- friendly, for instance.

<comment><USER3> I'm building an open-source equivalent with those exact goals (also using this as an excuse to learn Flutter): [https://github.com/nileshtrivedi/family](https://github.com/nileshtrivedi/family)

Just pushed a chat-screen UI and FireStore integration (all content will be encrypted and keys will only stay on device). Could explore making it as just a Matrix.org client (to get voice/video calls): [https://twitter.com/nileshtrivedi/status/1200480301480169472](https://twitter.com/nileshtrivedi/status/1200480301480169472)

Eventually, I think someone like FSF or EFF should own it.

</comment></comment><comment><USER8> no thanks, no social network is private. Once its online it will be sold. Or can be subpoenaed. just like your dna!

</comment><comment><USER9> Congrats on that name deeply related to bugs reproductive cycle (oh, and homepage downloads almost 20MB)</comment>


Hacking The NY Times Best Seller List - <AUTHOR> http://www.manyniches.com/fun-stuff/hacking-the-ny-times-best-seller-list/

<comment><USER2> I am a New York Times best-seller and I would be happy to answer questions about how I went from blog --> book --> products, especially about the challenges of getting people to pay online.

My book: <http://www.amazon.com/Will-Teach-You-Be-Rich/dp/0761147489>

My blog: <http://www.iwillteachyoutoberich.com>

Let me know if you guys have questions about monetizing content, book sales, or the psychology of getting people online to pay. There is so much interesting stuff I've learned over the last few years.

<comment><AUTHOR> I bought your book months ago...great content. It was easier to have you translate the content to family than for me to do it - I'm not a published author, so I am much less believable. :)

I would love to email you some questions about my book project and where to take it from where it is. I am blwatson at gmail

<comment><USER2> Thanks!

Let's do it here so others can benefit from the back-and-forth conversation. You can email me your super-private questions separately.

<comment><AUTHOR> Great idea on leaving the content for others to share.

I had put together an outline a year ago for a book. The working title is The Failing Point. I started writing, and built up a good head of steam. I knew that getting a publishing deal as an unknown was almost impossible. Since the content is in essay form, I started posting them online in blog format at the url www.TheFailingPoint.com.

I got into a 2x per week posting rhythm, and the strategy was to do this for the first 2 chapters, over the course of 2 months, and then stop. I had planned on taking the "success" of building traffic to a publisher. I didn't want to keep posting all of the content that would eventually be in the book at the risk of putting off any potential authors.

In the second of 2 months, I generated 20K uniques without spending any money. Links were posted here and Digg. I also tried to incorporate TweetMeme (great) and Yahoo Buzz (useless).

Well, the few publishers I was able to get the proposal to have either passed or taken their time in getting back to me (which is the same as a pass). So now what to do?

Based on the feedback I saw in the comments here at Hacker News, and emails I got, people appreciated the content. My "why" for doing this is not to say that I am a published author. I'd love to make some extra money, sure, but mostly because I feel like I have a unique set of experiences and am a decent enough story teller that the content is useful to those who would come after me. It's the content I would have liked to have seen before I embarked on my startups.

This project is well outside of my comfort zone, and perhaps I relied too much on a "if you post it, they will come" strategy. Now that the first two chapters are out there, and I have no traction with the few publishers I have approached, what would you suggest?

<comment><USER2> (Uh oh...I just realized the threading on these back-and-forth conversations may become a little crazy.)

Anyway, here's the deal.

You have clearly thought a LOT about this and have all the elements in place. I'll just suggest a few different ways of thinking about what you wrote above.

1\. Publishers don't care about your posting rhythm or how many Twitter clickthrough rates. In fact, many don't even care about your book topic.

They care about your platform and how well other books in this vein have done.

I noticed that you yourself indicated that there are few books on failure, while many books on success. Why do you think that is? What would make your book different?

2\. A series of musings is usually a very bad book. Who is the market? Do you already have a presence there? For example, publishers started approaching me once they noticed that iwillteachyoutoberich.com was popping up in the personal-finance space.

3\. On a tactical note, typically authors find an agent, who then finds the publishers. If you really want to publish a book, go find agents who have written books similar to yours and send them a pitch letter.

4\. Also on a tactical note, driving 20k uniques in 2 months is very good. However, from looking at your site, you haven't captured those people. In other words, they came once and left, never to return. Think carefully about how to capture these people so you can continue sending them material that they want, love, and expect.

I can get into outbound marketing if people care, but suffice it to say that many, many startups overvalue social media and ignore channels that actually convert. Hint: Twitter. (Test it and see for yourself.)

4\. MOST IMPORTANT. What is your goal? You indicated you don't care about the ego boost of being an author. So carefully consider whether a book is really what you want to do. There are many, many other channels (ebook, blog, etc) that don't require the back-breaking work of writing a book. Mine took 2 years to complete. A book is specifically useful for building your brand and spreading your ideas. But in most cases, there are other channels that work better.

(Incidentally, we should come up with a name for areas where people who work tell others NOT to do it. Examples: Authors, musicians, lawyers...)

Hope that helps. Let me know if you have other questions.

</comment></comment></comment></comment></comment><comment><USER3> I worked for a media company a few years back and we would hack the NYT by selling "limited edition" autographed copies of books.

We paid authors $5/signature and sold the book for $10 over MSRP. The author pre-signed thousands of books that we bought from major retailers at a discount (orders in the 10s of thousands). Then we organized speaking events and book tours the week the book released. On the book tour, when the stores ran out of stock they would buy our autographed copies because the publisher couldn't ship them fast enough. Any books that we didn't sell back to the retailers, we would sell on our online store at markup.

The key to hacking the system was negotiating with the retailer to report (on Nielsen BookScan) X number of books on release day, X number the day after, and so on...

<comment><USER4> Seems like an extremely risky strategy, even established authors happen to write books that sell badly. If you hit on a book, which you couldn't sell, what then?

Probably a good idea to filter only the "good" books, but how?

<comment><USER3> I don't think so, we only handled authors that had radio and/or television shows. Radio is great for driving local traffic to book stores.

We were 4/4 for #1 NY Times Bestsellers.

</comment></comment></comment><comment><USER5> Pre-ordering isn't really gaming the system, it's been understood that having a following pretty much ensures you're going to hit onto a list. The real question here is whether or not these two can turn their online-audience into an offline-audience.

With authors I've frequently decided to become an online fan after being an offline fan for up to years. However I've rarely done it the other way, and never for a book.

<comment><AUTHOR> Keith does a once a year comedy show on his birthday (Apr 15) in NYC and they get fans coming in from all over the world to see it. He's not headlining Madison Square Garden yet, but it's impressive regardless.

<comment><USER5> It's the loyal fans that will pay your bills, but the loyal fans aren't likely to get you on the NYT best sellers list (unless you're Stephen King).

I would be interested on what percentage of his online readership purchases his book on pre-order/first week vs how many of his readers are buying it in 6 months to a year.

</comment></comment></comment><comment><USER6> I'm always tempted to pick up Naked Came the Stranger whenever I'm at the bookstore, but I know I'll never read it. THAT book is truly the result of hacking the best seller list.

</comment><comment><USER7> Hey Ramit, can you talk a little but more about your comment on "many startups overvalue social media and ignore channels that actually convert. Hint: Twitter. (Test it and see for yourself.)"

Which channels are better than others for securing conversions? Which outlets SHOULD startups be focusing on?</comment>


According to Google Infinity = 171! - <AUTHOR>

Go to google calculator and then put 170! and you will get 7.257416e^(306). then put 171! and  you will get infinity. As a astrophysicist I do issues with this :D <comment><USER2> That is a pretty common overflow. 171! overflows a 32 bit float.

</comment><comment><USER3> I am not an astrophysicist, but I suggest that you, as an astrophysicist, use a mathematics engine that is a bit more robust. Might I suggest Wolfram Alpha:

[http://www.wolframalpha.com/input/?i=171%21](http://www.wolframalpha.com/input/?i=171%21)</comment>