Ross, Gilbert teaming on $300m UM innovation center at jail site in Detroit - <AUTHOR> https://www.crainsdetroit.com/real-estate/ross-gilbert-teaming-300-million-um-innovation-center-former-jail-site-detroit <comment><AUTHOR> One of the hardest things is getting university students to spend any time in downtown Detroit. But if they do, there's a good chance they'll consider building their careers there.

The University of Michigan is taking their best and brightest, most entrepreneurial kids and placing them downtown in the D. My message to my friends in Silicon Valley is that Detroit's not playing at this entrepreneur thing.</comment>


The retreat from religion is accelerating - <AUTHOR> http://allendowney.blogspot.com/2017/10/the-retreat-from-religion-is.html <comment><USER2> Good to see the US is catching up. It has huge cultural influence, particularly here on politics in Australia, so in spite of so many worrying trends, this is a relief.</comment>


Uber is stopping self-driving car tests in all cities after fatal accident - <AUTHOR> https://www.cnbc.com/2018/03/19/uber-self-driving-car-fatality-halts-testing-in-all-cities-report-says.html <comment><USER2> [https://news.ycombinator.com/item?id=16619917](https://news.ycombinator.com/item?id=16619917)

1400+ points</comment>


"Some German bombers landed at UK bases, believing they were back in Germany." - <AUTHOR> http://en.wikipedia.org/wiki/Battle_of_the_Beams

<comment><USER2> I dimly recall from my youth in Cornwall that it was a particular problem if the aircraft ended up too far west - they would leave the South Wales coast, cross the Bristol Channel - confuse that with the English Channel, and then land, lost, at the first airbase they found in Cornwall -thinking they were at least in France.

</comment><comment><USER3> Interesting! You always hear about the battles won with guns and bombs, but very rarely do you get to learn about battles between engineers.

<comment><USER4> Interesting indeed. If you think all the new tech in WW2 (missile, radar, atom bomb, Enigma, u-boat), calling the WW2 "the first war of engineering" isn't far from the truth.

<comment><USER5> U-boats were a major factor in WW1 - the United States probably wouldn't have entered the war if it hadn't been for German attacks on transatlantic shipping.

<comment><USER6> And even encryption was important in WW1. The Germans did a pretty good job at listening to the Russian communications.

</comment></comment></comment></comment><comment><USER7> There is a spectacular book about the Battle Of the Beams written by R. V. Jones, who was the British scientist in charge of countering the German technical advances.

I can't recommend it enough, although it is a very in-depth read: [http://www.amazon.co.uk/Most-Secret-Penguin-World- Collection...](http://www.amazon.co.uk/Most-Secret-Penguin-World- Collection/dp/0141042826/ref=sr_1_1?ie=UTF8&s=books&qid=1281960791&sr=8-1)

<comment><USER8> Here's an US Amazon.com entry: [http://www.amazon.com/Most-Secret-Penguin- World-Collection/d...](http://www.amazon.com/Most-Secret-Penguin-World- Collection/dp/0141042826/) Based on a review comment and the page count it looks like it's a version of _The Wizard War_ I cited in another posting in this topic.

Lots of inexpensive used paperback editions available.

</comment></comment><comment><USER9> Hallicrafters S-27 ftw!

As one of my EE professors stated, "In RADAR, the odds are stacked in favor of the jammer". While this isn't radar similar principles apply.

</comment><comment><USER10> The article actually says 'RAF bases', not 'UK bases', so I presume the error wasn't necessarily as large as the distance between Germany and the UK.

<comment><USER11> It mentions however that the system was used after the campaign has switched to night bombing, which was months after the evacuation from France. The error was at least as large as the channel.

<comment><USER10> ... but not as large as Germany to UK, which is what the title says. The title does not say 'occupied territory', but 'Germany'.

</comment></comment></comment><comment><USER12> Like! :-)

<comment><USER12> Truly a leaf from the Art of War. Confound before Conflict.</comment></comment>


Pandora Shares Down Sharply; Threatened By Songza? - <AUTHOR> http://www.forbes.com/sites/ericsavitz/2012/06/12/pandora-shares-down-sharply-threatened-by-songza/

<comment><USER2> I really enjoyed using Songza between it's intermittent outages. The concept is well executed, the UX is polished, but performance-wise it just doesn't seem ready for prime-time. In fact I got to this page by googling 'Songza down'. :-(

</comment><comment><USER3> a bit of perspective for those thinking Songza came out of nowhere and stole Pandora's thunder.

Songza was created in 2007 by Aza Raskin and Scott Robbin. It was a music search service back when that was a popular meme. It was bought by Amie Street in '08.

for more <http://www.crunchbase.com/company/songza></comment>


How do we crush this dismal stat? 7% investor money goes to women-led startups - <AUTHOR> https://medium.com/medium-writing-prompts/how-do-we-crush-this-dismal-stat-only-7-of-investor-money-goes-to-women-led-startups-3f4330d6e10d

<comment><USER2> I would like to know which ones were turned down and which ones were funded. This will give us a better idea on whether these stats are purely based on gender or the idea of the startup.

It doesn't really make any sense as to why a VC would turn down a women-led startup just because of gender. They are in it to get an ROI.

<comment><AUTHOR> _" It doesn't really make any sense as to why a VC would turn down a women-led startup just because of gender."_

Agree on knowing the split of accepted startups.

As for selection, do you really think selection is made 100% logically? No gut level decision making or insider/outside dynamics at work here? Within the decision making process, bias is at work.

</comment></comment><comment><USER3> Id like to know the percentage of start ups are women led? This stat may be a reflection of the low volume of women in the tech industry as a whole...

<comment><USER4> While your second sentence here is true, the statistic you request doesn't do as much to answer it as we might hope. Start-ups designed to take VC money that can't get VC money don't remain start-ups designed to take VC money for very long.</comment></comment>


GitHub Alternatives - <AUTHOR> https://tutswiki.com/github-alternatives/ <comment><USER2> I looked at lot of these alternatives, not many are eating their own dog food. Does not inspire me with confidence.

* [https://gitea.io/en-US/](https://gitea.io/en-US/) The code for gitea is on Github. [https://github.com/go-gitea/](https://github.com/go-gitea/) * [http://gitprep.yukikimoto.com/](http://gitprep.yukikimoto.com/) The code for gitprep is on Github [https://github.com/yuki-kimoto/gitprep](https://github.com/yuki-kimoto/gitprep) * [https://gogs.io/](https://gogs.io/) Guess what ..... [https://github.com/gogs/gogs](https://github.com/gogs/gogs)

<comment><USER3> I guess Gogs have an excuse, as they had to host the project _somewhere_ , and perhaps they haven't started dog fooding because of migration difficulties, e.g. the issue tracker.

But I wonder what's the excuse for Gitea as they're a pretty recent Gogs fork?

They're both pretty amazing though: Self-contained binaries and less than 5 minutes setup time, so totally suitable for ad-hoc deployment.

<comment><USER4> Github also does not cost time and money to use for open source projects.

I've used a few GoGS servers, but none of them were public. Hosting a public competitor to Github is a different set of skills to developing a self-hosted VCS server.

</comment></comment></comment><comment><USER5> "A couple of years ago Microsoft was anti-open-source." The quote is from 2001 as is Ballmer's quote. Closing the article due to its lack of objectivity.

<comment><USER6> Fixing an imago set by a guy calling open-source and Linux 'a cancer' is really hard. The last few years of changes doesn't magically wipe away that bitter taste, and the last 10-20 years doesn't magically make you forget the past.

<comment><USER7> It's an interesting debate though. If the CEO and most of the major execs of a company have left, is it really worthwhile to factor statements made 17 years ago into your decision making process?

Don't get me wrong, many will avoid MS-anything to punish them for their past conduct, which is a fair personal decision. But if you're trying to evaluate what MS _will_ do in the future, I'm not sure how relevant 2001 is.

<comment><USER6> Indeed it is. Same goes for other prominent figures, like Steve Jobs. People were/are convinced that the whole identity, all products and every choice was Jobs-bound and therefore without Jobs, what Apple does can't be just as good as it was when he was alive and running things.

So past CEOs can make a lasting impact, and in many ways it works out badly because the negative comments get the most attention.

Where Apple, according to some louder fans is not as good as it was under Jobs, for Microsoft under Nadella the inverse is true: according to the haters, just because it looks better now doesn't mean the (to them) bad years are gone.

Generalising, no matter what direction a transition takes (good to bad or bad to good), it's always the loud messages pointing out the bad past or bad future that gets the most attention and influences choices the most.

It's almost like trust between people: doing things right 99% of the time but doing one thing wrong once always makes that 99% of 'good' disappear and only the bad is taken as the 'true' value. In the extreme: lie once, and you are a liar. Even if you are 99 years old and have never lied before. That one time, once, will be what defines you as 'bad', and the rest does not outweigh it. Of course in reality that extreme example is not super likely, but nevertheless, it should carry the point I'm attempting to make ;-)

It's not the sum, aggregate or balance that seems to count, only how 'bad' your 'badness' is.

</comment></comment></comment></comment><comment><USER8> I've never used Github for personal, closed-source projects, but if you have and want to switch to something that provides absolutely no features except git hosting, here are 3 I've used:

\- Keybase git: [https://keybase.io/blog/encrypted-git-for- everyone](https://keybase.io/blog/encrypted-git-for-everyone) (my preferred solution these days).

\- AWS CodeCommit: [https://aws.amazon.com/codecommit/](https://aws.amazon.com/codecommit/) ("encrypted", but I don't know if AWS employees can access it).

\- Dropbox git remote: [https://github.com/anishathalye/git-remote- dropbox](https://github.com/anishathalye/git-remote-dropbox) (it's slow and unencrypted, but uses Dropbox).

<comment><USER9> All the major clouds offer repos, Google Cloud has free private ones with decent limits: [https://cloud.google.com/source- repositories/](https://cloud.google.com/source-repositories/)

</comment></comment><comment><USER10> Here's a good comparison page of the three big ones.

[https://stackshare.io/stackups/gitlab-vs-github-vs- bitbucket](https://stackshare.io/stackups/gitlab-vs-github-vs-bitbucket)

Gitlab seems to be picking up the pace and gaining mindshare among developers.

Freelancers I'm curious, would you switch and lose your repos' stars, PRs, fork counts? Those are actually a good marketing tool for potential customers since they see you are legitimate.

</comment><comment><USER11> There is also Gitea: [https://gitea.io](https://gitea.io)

<comment><USER12> Thanks! gogs looked great until I was horrified it has no oauth plugin support?! gitea does. why the fork? seems awkward.

<comment><USER13> The fork happened years ago because Gogs was (not entirely sure of current status) managed by a single person who would disappear on the regular, leaving fixes and other things not merged for weeks. So it got forked by people who were contributing to Gogs, and I think that ended up pushing Gogs into more active development. Now the two projects are still very similar but diverged enough to have some important differences like the OAuth support in gitea and such.

<comment><USER12> oauth is a total no-brainer feature add. Years ago I abandoned Trac because I couldn't deal w/ the spam user accounts and oauth integration w/ github wasn't really a thing back then. gogs should really add this though already gitea seems like that's where this particular community has gone.

<comment><USER13> gitea somewhat recently also added support for some 2fa stuff too. I haven't played with it yet but it seems like auth is being taken seriously there.

</comment></comment></comment></comment></comment><comment><USER14> I'm only half joking when I say VSTS is a pretty strong contender in the code+issues space, especially if you need more complex features for CI/CD.

For obvious reasons it's not a good option if you are switching from Github out of fear of Microsoft (which is presumably the reason it's not listed in the article).

<comment><USER15> The site is so fucking slow though.

</comment></comment><comment><USER16> Enough with this.

Does anyone have any hard evidence that SV Angel, or IVP, or Thrive Capital, or Sequoia Capital, or Andreessen Horowitz (the main investors in GitHub), had more noble intentions, or management style than Microsoft of Nadella?

Github was not a non-profit company. But you were willing to upload your private repo there. And somehow now it is problematic.

<comment><USER17> > And somehow now it is problematic.

As far as I know, Github hasn't delivered a surveillance, keylogging Operating System. They haven't used deceptive practices in getting users to upgrade to Windows 10 (leading to class-action suits).

Too many people are stating as _fact_ that Microsoft is not the same company they were 5 years ago. They are right... I think they are worse.

<comment><USER16> And yet the good GitHub sold your private repos to the highest (and according to you the most evil) bidder.

<comment><USER17> It's a bit of a stretch to call GitHub _good_ from the statement I made or to call Microsoft the _most_ evil bidder when _evil_ will suffice. I'll have to chalk that up to unnecessary sarcasm on your part.

To get back on track... I find it astounding that there are people actually defending any worldwide multi-billion dollar corporation whose actions are so incredibly user-hostile. Ideally, I would love to see this turn into a historical crossroads of sorts...

A point where end-users, who have the real power here to actually say "enough already" and make this purchase absolutely worthless. Instead of continuing to give the powerful more power and complain about it, to take that power back. In essence, to send a statement that an Open Internet can still exist.

That it doesn't have to be the cesspool of surveillance, backdoors, keyloggers, data-sharing and hording run by a few Tech Giants with zero accountability. A GitHub exodus (ie, The Great GitHub Exodus) can represent that with Microsoft (and others like them) choking on their dirty billions.

</comment></comment></comment></comment><comment><USER18> Also Kallithea.

[https://kallithea-scm.org/](https://kallithea-scm.org/)

I guess it's a wiki so I could add it myself, but apparently you need a github account to edit this wiki?

</comment><comment><USER19> I am a happy gitlab.com user. However, with all of this week's news I decided to see what it would take to run my own GitLab instance. I was surprised to find that on Digital Ocean and AWS Lightsail the one-click GitLab installs required an instance that costs ~$40 per month just for me, one user. Any cheaper/smaller instances were to anemic to run GitLab at all. Seems like there are some performance issues to deal with there.

<comment><USER20> GitLab is a Rails app, what did you expect? /s We use gitea (written in Go), it runs well on more modest hardware.

<comment><USER21> Why the sarcasm? Rails is a pig.

<comment><USER22> I wonder if there's a chance GitLab will be rewritten in a more efficient language.

<comment><USER23> GitLab VPE here. We are starting to re-write performance intensive part of our application in Golang. E.g. our Gitaly project: [https://gitlab.com/gitlab- org/gitaly](https://gitlab.com/gitlab-org/gitaly)

<comment><USER21> That's awesome. Great choice of a language. We just moved to Gitlab internally (we were actually starting to do so before the MSFT news). Very happy so far. Looking forward to speed improvements.

</comment></comment></comment></comment></comment></comment><comment><USER9> For all the complaints about Microsoft, I've yet to hear what they could do that would be so bad? Change the homepage to actually be useful? Improve the search? Give away free private repos?

<comment><USER14> Kill Atom was the most reasonable fear I heard. And I can't see how that wouldn't be a well founded fear. If I was Microsoft I wouldn't want to keep paying devs to make two so similar products (atom, code). They are much more similar than e.g code/vs or github/vsts.

But even so: I agree the fear that the _product_ will be worse in a few feels completely irrational.

What I can agree with is that it's unfortunate that it's no longer seen as a neutral ground for development. It felt almost like a standard or like a piece of infrastructure, rather than a for-profit. But that was of course never the case. But now it becomes obvious, which might fracture the community (it was very nice to have everything in one place - e.g package managers literally started drawing stuff from github links). The appearance of neutrality and trust was the #1 feature of GitHub. Everything else is polish. Microsoft will have to work hard to keep the #1 feature working.

<comment><USER24> Kill Electron would be the bigger fear. I know a lot of people don't like it, but it has enabled so many more applications for Linux that killing it would be a major blow.

<comment><USER25> They could be pretty interested in shifting it away from Chromium an V8-based Node to something that uses platform webviews (Edge on Windows) and a platform-specific JS engine backing Node (ChakraCore on Windows). I believe they have posted open-source experimental forks in that direction in the past.

That's very different from killing it, but it could make developing or supporting Electron apps more difficult - plus the fear that it could then start sliding down the slope of the Windows version getting more investment, eventually leading to the classic "it's best on Windows" embrace/extend platform lockin. I'm not betting on that being their play, but I could see how people would worry...

<comment><USER9> The whole point of Electron is equal cross-platform abilities from a single code-base. Making it run "best on windows" is the complete opposite goal and rather silly considering they already have several native UI and app frameworks made for Windows.

</comment></comment></comment></comment></comment><comment><USER26> These are no alternatives. GitHub is a specialized social network with git hosting included.

<comment><USER9> But there's no real stickiness there. Developers are not mainstream users who want a dumb UX like Facebook, they're perfectly capable of creating an account (if they don't already have one) and interacting with a project wherever it is.

Most discussions are limited in scope to a project anyway so it's not like you need the whole site. What difference does it make to go visit issues on GitLab vs Github?

<comment><USER26> There is stickiness. Low entry burden for contributer is the key point why huge projects use GitHub instead of other platforms.

And me registering at dozen of platforms, reading the legal stuff, learning the platform,... And when I finally successful submit a one line patch (how: no idea) the maintainer has a fair 50% chance of dropping it. That is not what I will do. And I will not be alone :).

<comment><USER9> What? You can do the exact same thing in GitLab or Bitbucket in the same exact few clicks. Fork, edit, submit PR, done. Have you used these other platforms?

<comment><USER26> Yes I have. But like always with social networks it's about the critical mass (GitHub dwarves everything else) and public acceptance (like a company accepting this strange "Bitbucket"... :)).

</comment></comment></comment></comment></comment><comment><USER27> There's also BitBucket's Paid Self-Hosted option, for 10 users, and a one-time payment of 10$. It even has a docker image.

[https://bitbucket.org/product/pricing?tab=self- hosted](https://bitbucket.org/product/pricing?tab=self-hosted)

[https://hub.docker.com/r/atlassian/bitbucket- server/](https://hub.docker.com/r/atlassian/bitbucket-server/)

<comment><USER4> For those looking into this option, it is important to note that Bitbucket's self-hosted option is a separate codebase that started with no link to the cloud product.

Previously it was called Stash but was later rebranded to Bitbucket to _reduce_ confusion.

<comment><USER28> Was not aware of this, thanks for the info.

Do you know if their enterprise edition is based on cloud or server?

<comment><USER4> If you mean the Data-Centre edition, it's based on Stash. Otherwise I'm not sure I've heard of that.

Here's the FAQ from when the change was made:

[https://confluence.atlassian.com/bitbucketserver/bitbucket-r...](https://confluence.atlassian.com/bitbucketserver/bitbucket- rebrand-faq-779298912.html)

</comment></comment></comment></comment><comment><USER29> Honest question: Besides more traction among the open source community, where do you feel GitHub is stronger than GitLab?

I'm not affiliated with GitLab, however a little biased because we're using GitLab instead of GitHub at our company.

Feature-wise, It seems to me that GitLab is running circles around GitHub. Curious about other opinions.

<comment><USER30> GitLab's UI is in every way a travesty compared to GitHub's.

GitLab feels like using GitHub's UI from about 3 years ago. Here's a list of things missing, just to name a few:

        > consolidated reviews
        > multiple assigned people
        > reasonable diffs when merging complicated changes, ability to review code since it was last reviewed
        > easy to create merge requests, and plenty of context sensitive stuff
        > can generate comparisons of code online without creating a merge request

There's so many small UI/UX pain points

Take [https://gitlab.com/coldnight/ci-test](https://gitlab.com/coldnight/ci- test) (which was the trending repo when I visited....):

        > The navigation is spread across:
          > The very top
          > The left hand side
          > An inline breadcrumbs below that
          > A bar in the middle of the screen
          > A bar below that
        > History button duplicates Commits button.
        > About 30% of the top of the UI is just useless filler - so the content on the page (the tree and the README - which is probably want I want when I visit a project) also consists of a small box in the bottom of the scren.

Compare [https://github.com/fivethirtyeight/data](https://github.com/fivethirtyeight/data) (which is the top trending repo on Explore on GitHub!):

        > Much more consistent navigation - series of contextual bars which move down - so each page is more consistent

        > Much more of the screen is available for the tree / README

<comment><USER31> Hi richardwhiuk, GitLab team member here.

We appreciate open feedback, thank you for these UI details. We are very aware of the lack of polishing of our current project home page and missed opportunities. There is a specific issue on that we are working on for a July release right now, see [https://gitlab.com/gitlab-org/gitlab- ce/issues/44704](https://gitlab.com/gitlab-org/gitlab-ce/issues/44704). This is a first step of the larger effort we are tackling to improve the overall experience via [https://gitlab.com/groups/gitlab- org/-/epics/62](https://gitlab.com/groups/gitlab-org/-/epics/62). Please feel free to check these out and comment in the issue.

Regarding our navigation, we feel confident that the experience has been greatly improved with the new 10.0 UI. See [https://about.gitlab.com/2017/09/13/unveiling-gitlabs-new- na...](https://about.gitlab.com/2017/09/13/unveiling-gitlabs-new-navigation/) for some context. I'd like to encourage you to get involved and let us know what you think! You can always create an issue to contribute improving the GitLab experience.

Andreas Product Manager

</comment></comment></comment><comment><USER32> Why are people jumping ship to lower quality services ? And I'm talking about unrecognizable brand names, because at least migrating to Gitlab or Bitbucket may be understandable in a way, but still an exageration in my opinion.

<comment><USER33> I was alive when Microsoft was evil and I don't want my stuff to stay in a Microsoft service. I moved my pulic repositories to GitLab today. It's slower and it doesn't looks as nice but it's ok.

I self host my private repositories, no need of a third party service for that.

By the way, Bitbucket looks a little better than GitLab but its usability is abysmal. I always have troubles finding the things I want in there.

<comment><USER34> GitLab runs on Microsoft Azure. :)

<comment><USER33> I don't mind, as I don't mind that (another famous example) StackOverflow runs on Windows. They use what's best for them. I don't use MicroSoft directly but with all the stuff that they sold it's impossible to stay strictly clear from them. Examples: Windows powered ATMs and supermarket cash counters.

</comment></comment></comment></comment><comment><USER35> An alternative way of solving this:

[https://news.ycombinator.com/item?id=17242015](https://news.ycombinator.com/item?id=17242015)

Pair that an open spec for something like Jira or a Kanban board and the concept of GitHub or GitLab or Bitbucket+Jira could be commodity.

Fossil isn't a bad idea as a general replacement for all of this too.

</comment><comment><USER36> Raspberry Pi running your own git server.

[https://blog.meinside.pe.kr/Gogs-on-Raspberry- Pi/](https://blog.meinside.pe.kr/Gogs-on-Raspberry-Pi/)

[https://hackernoon.com/create-your-own-git-server-using- rasp...](https://hackernoon.com/create-your-own-git-server-using-raspberry-pi- and-gitlab-f64475901a66)

[https://pimylifeup.com/raspberry-pi-git- server/](https://pimylifeup.com/raspberry-pi-git-server/)

</comment><comment><USER37> There's also (Fedora) Pagure, available hosted at [https://pagure.io/](https://pagure.io/), and it can be self-hosted. Though it's not quite as painless as gitea/gogs. Example of a more active project: [https://pagure.io/mlocate](https://pagure.io/mlocate)

<comment><USER38> Didn't know about that one, thanks! This further increases my appreciation of Fedora. Between this and the COPR hosting, you can really do some serious development for Fedora without paying a dime for hosting or distribution. That's awesome.

</comment></comment><comment><USER39> Thumbs up to Phabricator, a software imo very underrated. Absolutely recommend if you are not very fond of Gitlab (furthermore, Phabricator's performance has been really good in my experience)

<comment><USER40> I am definately going to look at this. Now if there were a self host cloud storage (nextcloud) that also did soure repository...

</comment></comment><comment><USER41> I'll leave GitHub when I have some issues that I can't resolve. By then everyone will have blazed the trail for me, maybe a coupe times. ;)

Much like the United States.... all my stuff is there...

</comment><comment><USER42> The list doesn't mention it, but i'd also put [https://rhodecode.com/features](https://rhodecode.com/features) into there.

</comment><comment><USER43> Launchpad is not only for Bazaar. It supports Git, too:

[https://help.launchpad.net/Code/Git](https://help.launchpad.net/Code/Git)

</comment><comment><USER44> Assembla's version control has been working well for me since 2011

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

<comment><USER45> +1 for Assembla. Reliable service, and free private repos too.

</comment></comment><comment><USER46> Redmine is also missing from the list. [https://www.redmine.org/](https://www.redmine.org/)

</comment><comment><USER47> This is equivalent to a knee-jerk reaction clearly following the MS purchase of Github. The Microsoft of today is vastly different. Example: I'm using VSCode on my Mac right now and it clearly is a better alternative to something like Atom and its open source. My best friend is the head of the bash initiative at MS as well and I pretty much hated MS before. Now its pretty cool so doesn't seem like a rational view anymore to be MS negative.

</comment><comment><USER48> git-ssb, open source and decentralized: [https://git.scuttlebot.io/%25RPKzL382v2fAia5HuDNHD5kkFdlP7bG...](https://git.scuttlebot.io/%25RPKzL382v2fAia5HuDNHD5kkFdlP7bGvXQApSXqOBwc%3D.sha256)

</comment><comment><USER49> Codegiant.io is also a great alternative to Github with unlimited private repositories for free.

It also includes issue tracker, continuous integration and documentation. Overall great tool.

</comment><comment><USER50> Lets be honest.... people just like to shit on microsoft. i was against open source most a decade ago.

Now they understand that they need open source alternatives to keep alive.

Azure has suport to various popular open source techs, they keep a lot of repositories in github, and even open sourced .net.

And, you complain about microsoft buying Github? Imagine if Oracle had done the same.

</comment><comment><USER51> "A couple of years ago Microsoft was anti-open-source."

Then quotes stuff from 18 years ago.... ok

<comment><USER52> Some people still don't trust MS, even after the recent changes. Can't blame them

</comment></comment><comment><USER53> I want also add [https://github.com/cjb/GitTorrent](https://github.com/cjb/GitTorrent) Cool concept.

</comment><comment><USER54> If it is an alternative then it is probably not the best option.

You and I use Github not because we don't know the alternatives, but because Github is better

<comment><USER55> That isn't true. As with most online services, people use Github over alternatives because of the network effect. It's where everyone goes because it's where everyone is.

</comment></comment><comment><USER56> In the big wave of alternatives, we also should mention Tuleap [1] that is now open to all opensource projects. Can also be self-hosted of course !

[1] [https://blog.tuleap.org/github-alternative-tuleap-open- sourc...](https://blog.tuleap.org/github-alternative-tuleap-open-source-agile- tool)

</comment><comment><USER57> So much drama, I am really looking forward to what will happen if Microsoft ever gets hold of one of the major Linux distributions.

</comment><comment><USER58> I never imagined in my lifetime Apple would become Microsoft and Microsoft would become Apple. Yet here we are.

</comment><comment><USER59> I wonder why gerrit wasn't listed?

</comment><comment><USER60> Is everyone really leaving GitHub, or is this just like 2013 when everyone "left" Google for DuckDuckGo. This is pretty bad personally, I'm writing a webcrawler for the site. I plan on making it cross-website anyway, but it kinda sucks hearing this.

<comment><USER61> It does not appear to be the case that a ton of people are leaving GitHub. Gitlab is mentioned far and away more than all other alternatives combined and their GitHub importing I think is like ~100K repos imported since the Sunday rumors. A lot but nothing compared to the tens of millions of repos GitHub has overall.

</comment></comment><comment><USER62> git init --bare

</comment><comment> johnx123-up Probably a better comparison page [https://docs.gitea.io/en- us/comparison/](https://docs.gitea.io/en-us/comparison/)

</comment><comment><USER63> I wonder why does Kallithea not get much more love, it is a very decent project: [https://kallithea-scm.org](https://kallithea-scm.org)

</comment><comment><USER64> There's also ChiselApp which is Free, and able to be Self-Hosted (Flint is the upstream repository -- ChiselApp is a styled Flint, without the rights to redistribute the theme).

</comment><comment><USER65> Gitlab it is then!

Not sure what to do with all my Github tshirts now :)

<comment><USER66> I was going to point out that GitHub pages are so great for hosting static content that that alone keeps me in GitHub. But looks like GitLab already implements their equivalent.

Too bad it looks like they don't handle enabling TLS/SSL for custom domains as conveniently as GitHub does (e.g. one click to enable and they will then get the cert through LetsEncrypt or something without me having to bother with getting it from a CA, renewals etc.) [1].

Already commented about this elsewhere, but if anyone from GitLab is reading, this thing would make any potential transition much more convenient for me.

[1] [https://docs.gitlab.com/ee/user/project/pages/getting_starte...](https://docs.gitlab.com/ee/user/project/pages/getting_started_part_three.html#ssl- tls-certificates)

<comment><USER67> For what it's worth, I started using Netlify ([https://www.netlify.com/](https://www.netlify.com/)) for my static sites a while ago, and it's been great. Automatic LE support is definitely one of my favorite features.

</comment></comment></comment><comment><USER68> I like the content but the website's scroll is somehow delayed and I'm unable to pinch zoom on my mobile device.

</comment><comment><USER69> the deep integration go has with github in particular seems more ridiculous then ever.

</comment><comment><USER70> I'm surprised by the lack of choices that are free non-self hosted

<comment><USER71> Why non-self hosted is supposed to be free for non open source projects?

<comment><USER70> It doesn't have to be but I'm a little shocked no one is taking that end of the business.

</comment></comment></comment><comment><USER72> > A couple of years ago Microsoft was anti-open-source.

Both quotes are from 2001.

So rather than a "couple of years ago", it was _seventeen_ years ago.

Toddlers walking the earth at that time, are now college graduates and developers working at Microsoft. Let's not think its the exact same group of people who said both statements, even if the company name is unchanged.

<comment><USER73> > Toddlers walking the earth at that time, are now college graduates and > developers working at Microsoft

This is extremely true and people need to understand how important this point exactly is. I think we all agree that Microsoft will continue to exist even 50-60 years from now with the same exact name. They will have generations of programmers passed through their corporate structure with varying goals and opinions.

 _Tu quoque_ stops making sense at such timescales.

</comment></comment><comment><USER74> Microsoft has cancer*

* source microsoft</comment>


The State of JavaScript – Survey results - <AUTHOR> http://stateofjs.com/ <comment><USER2> It's really unfortunate that so many people aren't interested in learning Ember. I just started an internal IT tool in Rails and Ember and I'm _really_ enjoying the simplicity of it. I want something that is easy to understand, easy to setup, and won't change for a while. I became more interested in Ember when I read something online about how they are focusing on stability in the long term instead of a bunch of features. There are also a couple of tools for "just get it hooked up to rails, stupid" that helped me move quickly. As a simple, simple guy - I really prize the "hey stupid I set it up for you" command line tools that give me a starting point. Then I can figure things out as I go along by making small, simple, controlled changes.

This is in strong contrast to something like Elm. I have played around with Elm a bit but it's hard to wrap my head around some of the concepts and setting it up with the back-end frameworks that I'm familiar with has been meh. It's also changing rapidly so trying to figure out the concepts by looking at real world examples doesn't help because of a changing language specification. Going from changing the state of a counter to building out a larger application has been somewhat difficult for me and I feel overwhelmed every time I try to start a small project with it. I'm chipping away at that with an Elixir/Elm project, however. But the overall point is that progress is slow because it's such a different way of doing things and I get this gut feeling that I'm drifting away from KISS principles.

I'm not a front end developer at all. I'm a systems engineer who dabbles in web application development because it's fun and allows me to build some nice internal tooling for other teams. However, because I don't have that deep web experience I tend to gravitate towards the "old but still good" concepts and frameworks. I'm much more likely to reach for jQuery and server side rendered templates than I am for React or whatever amalgamation of libraries that require an overcomplicated build tool.

<comment><USER3> I suspect that we didn't get enough Ember responders, because I do think they have a reasonable sized community. 9k responses is likely not enough to draw a reasonable conclusion that it isn't popular. I wish we could have paired up npm downloads or some other stat besides some of this data...

<comment><USER4> Ember has a pretty large community—the framework has a few conferences every year that are filled up. Most Ember devs don't seem to participate in a lot of JS community things and are very quiet compared to say, the React community.

</comment></comment></comment><comment><USER5> It's nice to see some love for Apollo here. It's leagues better than Relay and has definitely been the biggest boon to my development stack in a while. That being said, the article should make it clearer that Apollo is perfectly usable just as a frontend client—you don't have to adopt the backend at all.

The Meteor team really deserves commendations for learning from some of the mistakes in building Meteor. Apollo specifically emphasizes incremental adoptability: you can drop it into an existing project and see benefits almost immediately, without having to refactor/rewrite any of your existing code.

I'd also like to provide a counterpoint to the inevitable complaints about the complexity and low-productivity of a JavaScript. In my experience, once you've paid the initial cost of learning these tools you can become extremely productive. As a freelance developer who is paid a flat rate for projects, I'm directly incentivized to find an efficient stack and the modern JavaScript stack is definitely it.

Specifically, my stack these days is Django + Graphene + React + Redux + Apollo. It's insanely high productivity: I can usually have the basics of an app built within a few hours of starting.

<comment><USER6> (Disclaimer: I work on Apollo)

Yes, it was a bit surprising to see "Apollo" separate from "GraphQL" here, since our primary focus is to enable people to take advantage of GraphQL no matter their frontend and backend architecture.

It makes the most sense to make a direct comparison between "Apollo" and "Relay", but they should both be considered a subset of "GraphQL", which is really the core technology that everyone is building on.

However, excited that people like it, and we're excited to collaborate with everyone to make it the best way to use GraphQL in an application!

<comment><USER7> Do you guys know something loke Apollo but on top of RxJS?

I'm not a big fan of Redux anymore since I discovered observable streams.

<comment><USER6> Apollo returns the data in observable form. You never have to deal with Redux directly if you don't want to. Check out the Angular docs for more details.

<comment><USER7> It's also written in TypeScript, nice!

A few days ago I was thinking about using GraphQL in future projects and didn't even find out about Apollo.

So it combines data retrieval via GraphQL with client side state management via Redux?

<comment><USER6> That's exactly right. We're working on refactoring it as well so that it can be used outside of Redux, here is one of the resulting projects: [https://github.com/apollostack/graphql- anywhere](https://github.com/apollostack/graphql-anywhere)

<comment><USER7> you just stole my heart :)

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> I appreciate that for the next year when there is a framework war I will have a link to shut it down.

Typically a newbie will ask about which framework they should learn. There will be a bunch of "it depends" and "try them out" responses, and then someone will take pity and pick a clear direction based on their experience.

Well and good.

But this way the newbie can learn from the actual experience of lots of other people. Data, for short.

<comment> at-fates-hands >> Typically a newbie will ask about which framework they should learn..

Honestly the easiest way to learn this is to contact your local recruiters and ask them to send you some openings for FED positions.

In nearly every one, you will see which JS framework is the main one they use. In my recent experiences (the last two or three years) most corporate environments are using AngularJS, while the smaller startups are using React and some mix of various other libraries for their apps and sites.

There are still a few agencies I know using BackboneJS, since it was in that first wave of JS frameworks and there's apps and sites out there which still need supporting.

<comment><USER8> Interesting approach, but I will note that even you have recommended three (Angular, React and Backbone).

People generally put forward one of the following: Knockout (easy to learn), Ember, Backbone, Angular, React.

Someone will invariably say no, use nothing but plain Javascript at first. This will lead to a little subthread about whether it is fair to include jquery.

Every now and then someone will come up with meteor or vue as an alternative.

</comment></comment></comment><comment><USER9> I'd love to hear more from people that expressed certain viewpoints - specifically those who used a library but wouldn't use it again... Specifically mobx :)

I've played with most popular js libs now and I've found that for my use case I wasn't totally happy for one reason or another. I've been dabbling in mobx for that last few weeks and the ease with which it has allowed me resolve issues in my codebase is really promising.

If anyone here is in the 58 people who wouldn't use it again, care to share what you ran in to?

<comment><USER10> After using Mobx for a few weeks, I've come to question why anybody would use anything else. It is the _only_ software I've ever used that was created for a dynamic language that has me trying to re-implement in my favored strong/static typed languages. Now I just point and laugh at anybody trying to make sense of their Redux global state atom with a bajillion reducers.

So far, I've only found one common objection to it: that it embraces mutable state. Well duh... _UIs are state machines_. They need mutable state because their entire existence depends on it. Sure, you might be able to model the mutable state of UIs using immutable data _structures_ , but you can't get rid of the mutable state. And because of this, my opinion of this objection is that it is of a religious nature. You can ignore this particular objection with no risk at all.

<comment><USER11> I'm really interested in what you're saying about UIs as state machines. Do you have any articles/references to back this up? Genuine curiousity here.

<comment><USER12> The person you're replying to didn't specify whether UIs are represented as state machines which are finite or infinite, but I'll assume finite since infinite automata are more powerful than Turing machines so they presumably can represent something which is made by a computer.

UIs in general can not be represented by finite state machines. An example is a page with a button which when pressed adds something to the page. Since there are an infinite number of things that could potentially be added, this can't be represented by a finite number of states.

On the other hand, I think many UIs could be represented by finite state machines, although perhaps sometimes only roughly. You can start by trying to specify that each instance of a specific page a user can see is presented by a state, and any interaction with the user that leads to a different rendering of the same or a new page is a transition. However, this fails to account for things where a user can do something which doesn't change the current page but might change a later page. You can account for this by having multiple states which show the same exact UI but have different transitions to future pages. Of course, it isn't just the user who can interact with your system to produce a different UI for other people, so you'd have to model those transitions and states too..

I'm not a front end developer so I don't know how many UIs can actually be modeled this way, but I can see how it might be a useful way to think about things, even if it isn't necessarily always correct.

<comment><USER13> I didn't specify finite or infinite, and you're right that FSMs alone aren't sufficient to describe all UIs. But they are sufficient to describe nearly all interactive UIs.

Your infinite button example still has a finite state, but it's not modeled explicitly, and would probably be a good idea, for very practical reasons, to do so. If it really goes on forever, you'll eventually run out of memory, whether that memory is managed by the rendering engine (appending dom elements?) or by the language runtime.

> However, this fails to account for things where a user can do something > which doesn't change the current page but might change a later page.

A Hierarchical State Machine model covers this scenario quite nicely...which is exactly what React is.

<comment><USER12> Interesting. I hadn't heard of hierarchical state machines. Thanks for the reply.

If you don't consider the infinite button example, then what other kind of UI can not be described by a FSM?

<comment><USER13> I've certainly never found a common UI pattern that isn't describable with FSMs, but you could probably think of a few toy examples of non-terminating state. Anything involving recursion, exponential, or asymptotic behavior for example could theoretically involve infinite states. Again, likely of no practical use.

<comment><USER14> Read any real-world user interface specification like Apple's classic Macintosh Human Interface Guidelines [1]. It specifies all kinds of complex behaviors, like how pull-down submenus don't pop up immediately as you move the cursor over them, and how dragging and dropping text handles the white space at the beginning and end of the selection, or how adjusting the end of the selection in mixed right-to-left and left-to-right text works, which is much too complex and nuanced and ad-hoc hacky to describe with finite state machines, and require a Turing complete machine to implement.

Even if it were technically possible to restrict yourself to a FSM, you would end up going insane and producing exponentially explosive unmaintainable finite state spaghetti machines.

There's a huge uncanny gap between what you can elegantly describe with a clean mathematical abstraction like finite state machines, and what real human beings expect and perceive to be easy to use in a real world user interface.

The polish of a good user interface is the result of millions of tiny little scratches, and in practice that requires the power and flexibility of a Turing machine (and not one stuck in the Turing tarpit like Brainfuck) to make all of those tiny little scratches and cover all the edge cases and special circumstances, because finite state machines are just too clumsy and not powerful enough to conveniently cover that much ad-hoc messy fractal detail.

[1] [http://interface.free.fr/Archives/Apple_HIGuidelines.pdf](http://interface.free.fr/Archives/Apple_HIGuidelines.pdf)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> As someone who doesn't work incredibly often with Javascript but has dabbled with MEAN and extensions of MEAN, I found one of the last questions a bit biased in its results:

"I would like JavaScript to be my main programming language" (Rate 1 to 5)

49% (5) 35% (4-3) 16% - (2-1)

If you've taken this survey, it means that you have done at least a decent amount of work with Javascript. Chances are, you have at least enjoyed something about it so far, or are absolutely required to use it for some reason.

Of course many current Javascript users want it to be their main programming language.

I love this survey for so many reasons, and this is an incredibly small point. Personally, I think that a good Javascript tool, framework, flavor, whatever, should be able to easily integrate with other technologies. I really enjoyed Angular for that reason (yet to dive into React). I think the idea of "JAVASCRIPT EVERYWHERE" is just really unneeded. Yes, we are stuck with Javascript as a language. Yes, it should be more than a simple afterthought on top of other tech. Making Javascript better and safer doesn't mean you have to do it everywhere, because ubiquitous Javascript doesn't matter if the different dependencies are completely different anyways.

The last part is only my opinion, but I wanted to add it because I think the survey's nature is going to exclude many people with it.

<comment><USER14> It would be interesting if they'd also asked "How many other programming languages do you know besides JavaScript?"

And compared how many people want JavaScript to be their main programming language because they only know one programming language and don't want to learn another, with how many people know multiple programming languages and would rather program in JavaScript as their main language because they like JavaScript better.

</comment></comment><comment><USER16> >Overall, developers are not happy about JavaScript testing.

This is because of the low percentage of devs in the survey who have used Jest. I can't begin to describe the joy of finally finding a JS test utility that just works and doesn't require a giant configuration file.

If you aren't using Jest, make the switch now! It's likely a lot of your existing tests will work with Jest.

<comment><USER17> I used Jest early on, it was nice, but I quickly started to encounter problems related to how new it was. It's way better now, so maybe I will switch back to Jest from enzyme.

<comment><USER18> You can use Jest together with enzyme! We posted a big community update together with Jest 16 which should highlight a bunch of ways that you can test with Jest.

[https://facebook.github.io/jest/blog/2016/10/03/jest-16.html](https://facebook.github.io/jest/blog/2016/10/03/jest-16.html)

</comment></comment></comment><comment><USER19> I wish to register my complaint with the term "ES6" which has always been unofficial and refers to the official standard "EMCAScript2015".

<comment><USER20> Same. ECMA changed to using dates a while ago and people are still saying "ES6" and "ES7". I've also seen people refer to _all new syntax and features_ as "ES6" including things that in ECMAScript2017.

Honestly though I think ECMA has some of the blame for this. I don't think they do a very good job communicating changes and versioning.

<comment><USER21> Yeah I think there is just a lot of friction when moving from the concise "ES6" to the lengthy, and somewhat awkward "ECMAScript2015". The fact that so many people still use the terms ES6 and ES7 gives others even less incentive to use the official naming scheme. Hopefully, it will iron itself out in the future.

<comment><USER22> I think its not just the length but the concept: Every other language has a normal looking version (Rust 1.12 announced! Java 8, etc). They had that with ES3, ES5, ES6, then decided (perhaps for very good reasons) to change to a unique (?) version scheme.

<comment><USER23> C and C++ also use years. For example, C99 was standardized in 1999. C++11 was standardized in 2011.

</comment></comment></comment></comment></comment><comment><USER24> Super interesting. Lots of data there.

Two things that stood out from a quick once-over:

Vue is doing better than I expected.

PostCSS is less adopted than I expected.

<comment><USER25> I just tried Vue 2.0 for the first time last week and I really really liked it.

<comment><USER26> I had a similar experience with Vue about six months ago. I read the documentation and then gave myself an hour with it. By the end of the same day, I had re-factored a very complex dashboard and enjoyed every minute of it.

My biggest complaint is that I love React/MobX and Vue which makes choosing one over the other really painful. What a great problem to have!

</comment></comment></comment><comment><USER27> For the life of me I can't understand why webpack has become the de facto build tool. It's so much more complex than anything else I've tried. I understand it's supposed to be faster, but still, I wouldn't bother with it until your build times actually start to become a nuisance.

<comment><USER28> What else have you tried? All of the alternatives have left me compromising on the way I build my front ends. The docs for Webpack aren't great, and configuring it might be a bit painful, but if there's a better option I would love to know what it is so I can start using it.

Things I want:

* es2015 transpiling * jsx support * css/less/sass support * module loading * uglification for production builds * hot module replacement * source maps * multiple bundles/entry points * hashed file names

Brunch fulfills a lot of these requirements, and I use it when I need to spin up an application really quick. But it misses on just enough items to make me reach for Webpack when I build anything serious.

<comment><USER29> parched-tasks-webapp has all but one of those things (hashed file names), and it's just built on browserify. And you don't have to do weird things to get your CSS out of your JS on the server.

<comment><USER30> Why not just use css modules with the extract text plugin to put everything in a single stylesheet to solve that problem? For Dev it supports hot reload, and other environments get an extracted stylesheet that works with sever rendering and avoids fouc's. Plus you can autoprefix the output, and because of the css modules design you get encapsulated component css for free. The annoyance is working with a css framework or its js library, i.e.: bootstrap or material as each one seems to have a different approach to css dependencies. But I think those frameworks are becoming less relevant or can have their limitations worked around usually depending on which one you choose.

<comment><USER29> When using browser-sync, which parched-tasks-webapps does, CSS is already hot- reloaded, and there's no worry of configuring different "loaders" for the case of a javascript file on the server trying to require a CSS file.

In both cases, the page is loading an external stylesheet, so both are as susceptible to FOUCs as the other.

This is only my opinion, but using CSS loaders backs you into a corner where your javascript file is suddenly less portable, since the environment it will be running on needs to be aware of it.

</comment></comment></comment></comment></comment><comment><USER31> One thing I have noticed over the years is that the front end community is becoming more and more a "let me google how to do it" kind of community. The tooling ecosystem is so burdensome. Just to get a hello world app with React, Redux, Webpack, esLint, and ES6 takes forever. Sure there are starter boiler plates but they all don't seem to do quite what you need. Before it felt more like a solidly engineered app, now it feels a lot more like glueing various snippets from StackOverflow together.

I'm also finding the overhead from React / Redux very noisy. I have to do so much typing and define the same thing over and over across a bunch of different files just to do something simple.

I really like how Elm basically implements all of this with much cleaner syntax and works out of the box. It's too bad it doesn't have as much community behind it. I'd like to use it more but find it doesn't have enough community for me to consider using it for anything outside of home projects.

<comment><USER32> I would only use React/Redux for a complex app that's going to be touched by a lot of people. That's where it really shines. Elm is a non-starter in these situations -- I can't seriously propose it for a project because the learning curve is astronomical.

Also, I think simple Hello Worlds are a dangerous thing. They convince you that a tool solves all your problems until three months later when you notice your foot's been blown off.

<comment><USER33> The learning curve is a weekend of reading.

Elm is much SIMPLER than js, but not as EASY for you because it is new.

If you are at all familiar with compilers, types, and functional programming it should all be review anyways.

If not then you are missing a big part of your education and I would question your capabilities as a programmer.

</comment></comment></comment><comment><USER34> Gives me hope for Elm, there are a lot of potential converts out there.

</comment><comment><USER35> I apologize if the predictability of this comment, but I just want to say, I recently started a new gig at a company that has undergone a full on embrace of Javascript for tooling and server side projects and it boggles my mind how much productivity is wasted on this ecosystem. There is an interesting amount of energy put into making asynchronous code read synchronously in situations where asynchronous code provides no benefit. The dependency tree of any one project tends to be incomprehensibly sprawling. Runtime version numbering is... weird. Don't even get me started on the interplay of Gulp, Grunt, Webpack and NPM. ES6 is bizarrely noisy. ESLint fascism is a necessity given the history of legal anti-patterns the language must shoulder. Scoping can occasionally lead to absurdist solutions [1].

I know this is the future and I'm trying to embrace it, but boy does it feel icky doing it.

[http://stackoverflow.com/questions/33629343/what-is-the- best...](http://stackoverflow.com/questions/33629343/what-is-the-best-way-in- es6-to-assign-a-constant-conditionally)

<comment><USER36> Could it be that you are still just new to it (in the grand scheme of things)?

Because all of those things sound very similar to the complaints I hear from web developers on their first foray into desktop development.

There are so many tools it's impossible to know them all (or to even know which one is best to use in which situation), so much legacy code out there it's tough to learn what the "right" way to do things is, it often feels like you are fighting the OS or the language to get what you want how you want it, and dependencies are hard.

Application development is hard, and is still far from "solved". And while the "web stack" is far from perfect, I'm personally significantly more productive in it than I ever was in anything else. And in my experience that extra productivity makes better applications because I spend less time just trying to get it working, and more time getting it working well.

<comment><USER37> See, I'm not sure that's the case.

When I started writing apps using Cocoa, for example, I had a pretty good experience. Yeah, I fought some of the tooling that I wasn't really used to, but given that it was quite different from my backgrounds in web and embedded development, I was overall quite pleased with how easy and more importantly how _obvious_ everything was. I found this to be the same when I wrote applications in Qt, and also when starting to work with newer languages (like Go).

This contrasts very much with the Javascript ecosystem. Despite having been a nominal web developer for approaching a decade, I am still consistently baffled by how difficult it is to get to grips with how everything is put together. There seem to be dozens of different workflows, none of which are entirely compatible with one another. There are bad configuration formats all over. Every tool seems to be broken into 200 different parts that subsequently have to be reassembled in order to implement a working pipeline. Documentation is erratic at best, and so on.

I used to feel pretty productive with Javascript, back when the web was a bit more 'Wild West'. But as it has developed as an application platform, it feels more and more like I am _fighting the tools_ , rather than having them help me. That's not a nice feeling.

<comment><USER38> My experience is the opposite. I've been working on the web for over a decade now and only until a couple years ago have I really been happy with my stack.

My usual stack looks something like: Express / React / Redux / Webpack / Enzyme / CSS Modules

I do SSR / Universal JS whenever possible and it works great. The only problem on my stack nowadays is the CSS. Still haven't figured out a good flow. I currently use CSS Modules, but without dead code elimination, it just doesn't do exactly what I would like to (feed in the whole CSS library I use and let it pick and choose the classes that are used in my components, throwing the rest away)

Getting up to speed on all these tools hasn't been easy, but at this point, most of my projects are a breeze. No worrying about browser JS support. No worrying about CSS support. No more choosing between server side and client side rendering. Linting that works great and keeps the projects looking clean. Testing that doesn't make me wanna blow my brains out. Combining and minifying projects is a piece of cake. HMR + Autorefresh is like magic.

I'm really enjoying working on the web now.

</comment></comment></comment></comment><comment><USER39> This year's "Used it before, would use again" is next year's "Used it before, would not use again".

</comment><comment><USER8> So interesting I am still looking at it.

Suggestion: Add an optional section on _how the developer learned the technology_

I think you could do a really interesting meta-analysis where you could see a relationship between the way things were learned and the popularity of the tool.

It would also be a great resource for people looking to learn a technology and want pointers on where to start.

</comment><comment><USER40> Great job on the interactive presentation.

<comment><USER41> Author here, thanks!

<comment><USER42> I agree; it looks really nice!

Minor nit: would you be open to using colorblind friendly color choices in the future? The current colors are pretty hard for me to differentiate between.

<comment><USER41> Really sorry about that! I'll keep it in mind next time.

</comment></comment></comment></comment><comment><USER43> Some interesting things on the "Front End Frameworks" page:

* 53% of the respondents used React, and would do so again.

* 47% use "No framework", and would do so again.

(hmm. that doesn't leave much room, unless you can use more than one tool depending on the situation)

* 43% had "no interest" in Angular 2.

One other thing to consider, of the "had used X, would/would-not use again" responses: there is of course a lot of selection bias of whether or not to even try X in the first place.

...

My only experience with these so far is Angular 1. It's easy to get started with, but does get messy when you have a very large form (think "government work"). I don't have a "React" axe to grind, I'm just looking at the numbers.

However, by the time I have to haul in Typescript transpiling, much of the appeal of Angular 1 is lost :-(

(it feels like GWT, all over again, at least to some extent)

<comment><USER5> The way I read it is that each question is independent.

So I can say I've used Angular and would never use it again while also saying I've used React and _would_ use it again.

This is really a pretty decisively positive stat for React. Very few of its users would never use it again, while a lot of people have tried Angular and abandoned it. (This certainly matches my experience and anecdotes I've heard in the community.)

<comment><USER22> > The way I read it is that each question is independent.

Mine as well. I have two active work projects -- one is React, and one is plain Javascript. The latter is to keep the project extremely lean (mobile form single time use type thing) and I've enjoyed using no libraries in it (yet). So I would have responded positively to both of those questions.

</comment></comment></comment><comment><USER44> What is meant by "Real-Time Operations"([http://stateofjs.com/2016/features/](http://stateofjs.com/2016/features/))? The description could not be more vague and Google does not know either.

<comment><USER45> I assumed they meant something like websockets or server sent events when I took the survey.

</comment></comment><comment><USER46> I like the stats on the home page. A 53% response rate seems really good.

<comment><USER47> Is it me, or is 89 questions a lot of questions? I wonder if the number of questions cuts down on the response rate.

edit: I assume it does, but what is the tipping point?

<comment><USER48> I would think that next year, maybe staging into 3-4 different surveys may be a better idea... a month apart even... that way there isn't the drop off on a single survey.

I really do appreciate the format though.

</comment></comment></comment><comment><USER49> 213 people put "never heard of it" for plain javascript

<comment><USER50> Thats a surveyor because it sounds like an actual javascript flavor. CoffeScript, Plain Javascript, TypeScript are all flavors.

</comment></comment><comment><USER51> According to the survey, 213 people that took it have never head of plain javascript.

<comment><USER52> To be fair, a side effect of JS Fatigue is the inability to tell whether "Plain JavaScript" is the newest kid on the block or if it really means "good old JavaScript (ES3)".

Especially when the headline is "JavaScript Flavors".

<comment><USER53> Exactly, I've seen discussions about vanilla-js.com suggesting that people thought it was a real framework.

<comment><USER54> Poe's Law, maybe?

</comment></comment></comment></comment><comment><USER55> I love Meteor and hope that it continues to grow!

I've been using it since well before v1.0 and can understand peoples frustration around it. A lot of patterns and core themes have come and gone. Allow/deny, blaze, and now it is sounding more and more like mini-mongo might go the way of Blaze in lieu of Apollo.

Like I said though, I really do hope that the core values of Meteor stick around in the framework and it continues to grow. I love it :)

</comment><comment><USER56> "It would also be a great resource for people looking to learn a technology and want pointers on where to start."

Second that comment.

It strikes me as a brilliant that open-source programming languages should have these sorts of statistics. I wish I could see every OSS language reported like this...hmmm. I would replace the stock market ticker in my phone with that!

</comment><comment><USER57> Noticed that under build tools, JSPM wasn't mentioned. Is it no longer popular? I've had a ok experience using it and systemjs been pretty good so far to get es6 module support and typescript working. I guess JSPM wouldn't fit quite in the build tool category but I see no dependency management section.

<comment><USER58> JSPM never picked up. Its call to fame was that it was more "future proof" using standards that were not actually standard, and had a pretty bad take on pre-building vs building in the browser and stuff. It was slow (and the ways to make it fast were very clunky) and generally, tools focusing on node/NPM entirely ended up winning out.

</comment></comment><comment><USER11> Anyone feel like piping in why Aurelia? It pops out in the data, but unknown is satisfaction, etc.

<comment><USER59> I also wrote my first SPA in Aurelia this year. As an introduction to the Javascript world, it has been pretty good (though I would never use JSPM again). Bugs are fixed in a timely fashion, the developers are responsive, and overall my developer experience has been positive.

<comment><USER60> I hear you, but now they're starting to make it possible to get away from JSPM. I recently ported my "old" Aurelia app to the new Aurelia CLI version and it's great!

</comment></comment></comment><comment><USER61> For me, the beauty of JS was in its simplicity - there were wacky edge cases for sure, but here was a C-like language that you could use to build a project that almost anyone could understand. When Node first came out I was over the moon - wow, I can run processes on the machine from JavaScript?! Unreal.

It seems like I'm constantly keeping up with the complexity of the ecosystem, which is taking a toll on my productivity. This is probably my problem more than any specific failing of the evolution of the language, but, I like to ship.

Just my 2 cents to the discussion.

<comment><USER62> A "C-like language" is a very dubious compliment. Fortunately, JS is built around a different core. Unfortunately, it's built as haphazardly as C has been.

<comment><USER61> What I mean is that its syntax is classical. Its constructs will be very familiar to those who have taken basic education in modern programming.

As far as your 'different core' argument I'm not too sure what you mean. If you're a Node dev, then JS is just your means of calling OS routines and giving work to threads (in C under the hood, to be sure). If you're a front end person, then JS is a very high level layer again, making calls various OS services, probably in C++ or C.

<comment><USER43> I'm pretty sure the "core" reference refers to the "FP with OOP" core based on Scheme and Self, which is one of the best things about the (JS) language.

Alas, "The Management" demanded that it be dressed up to look like Java (and thus like C++). This led to a bunch of people that were unhappy that Javascript was in fact _NOT_ like Java when they tried to use it like Java.

It's a very nice dynamic FP language, but people keep wanting to do static OOP with it :-(

</comment></comment></comment></comment><comment><USER63> After trying out Vue.js, I am pretty sure I will never go back to React.

<comment><USER64> Never say never. Thats what I thought when I first used Backbone

</comment></comment><comment><USER65> This makes Firebase look wildly popular. But can you even use Firebase for an app where you don't trust every user to maintain your denormalized indexes properly?

I asked this question on Stack Overflow to not much response: [http://stackoverflow.com/questions/39800531/collaborating- wi...](http://stackoverflow.com/questions/39800531/collaborating-with- malicious-users-in-firebase-is-denormalization-up-to-the-cl/39805623)

</comment><comment><USER66> I really liked the "features" section. I've seen some weird things done in the wild to obtain some of these features. Like building a multi-SPA to obtain code-splitting where a site is split up into multiple pages each acting as their own SPA. But it does seem like things are settling down. Envious of all the people starting now. As someone who started web dev in 2010, anything I learned that was framework-specific then, is almost completely obsolete now lol.

</comment><comment><USER67> I am going to mention our framework, since I think it's relevant, but it's not just a JS framework. It's a fully integrated platform:

[http://qbix.com/platform](http://qbix.com/platform)

[http://qbix.com/platform/features](http://qbix.com/platform/features)

Would like to get some feedback on it, from anyone who looks through the features.

</comment><comment><USER68> Its a great and useful survey. But would have liked to see a question(if not a complete section) on search engine optimization(SEO). Most important thing for internet apps.

For enterprise apps it doesn't matter and for that you can safely use a framework like React. But its very crucial for Internet apps. Surprisingly, Google neglected building tools in that area, apart from guidelines via its webmaster blogs.

</comment><comment><USER69> "the thing that stands out right away is how the React row just lights up compared to the other front-end frameworks. In other words, React users are more likely than average to have experimented with multiple other technologies."

I believe the data wrongly indicates this because React, Redux and Webpack are used together to achieve things that both Angular 2 and Ember solve similarly internally.

<comment><USER70> true, but i think even a lot of the other non-coupled technologies have higher numbers, but it's hard to say if that's higher percentages

</comment></comment><comment><USER71> Nice article. I started a new hobby Rails project a couple of months ago and was a little surprised to see that even Rails 5 still defaults to Coffeescript. Googled around a bit and decided to drop it, as it seems to be more or less abandoned these days, which this survey seems to confirm. I wonder if/when Rails will switch to ES6 or something?

<comment><USER72> CoffeeScript was designed by and for Rubyists, so it makes sense that they'd be the last to drop it.

</comment></comment><comment><USER73> I don't have time to go into details at the moment, but I'm using, loving and recommending Mithril.

</comment><comment><USER74> Why are ES6 and JavaScript treated separately in this survey?

I thought ES6 is just a new version of JavaScript (the ECMAScript standard)? I thought both are written using the same HTML <script> tag. Why is it necessary to consider ES6 different from JavaScript in this survey?

Could you please throw some light on this?

<comment><USER52> Why shouldn't it? You still need to transpile ES6 to ES5

<comment><USER74> Thanks for the answer. I was not doubting the survey methodology or results. My question was simply out of curiosity.

I would like to request more details on your answer.

1\. What kind of ES6 requires transpiling to ES5. I mean, I once tried using Promise and something like Promise.resolve("foo") works just fine. Are there any ES6 constructs that would require transpiling, to work fine on, say, Chrome or Firefox?

2\. Is ES6 not completely backward compatible with ES5? If yes, I would consider ES6 as the same (although upgraded version of) language as ES5. If no (e.g. Python 2 vs. Python 3), then it would be justified to consider ES6 to be different from ES5. What's your opinion?

Disclaimer: I am not a JavaScript developer. I am a system programmer. But I do a little bit of web-designing once in a while, for example, to maintain my blog etc. That's why I would like to understand why ES6 is considered a different language than ES5.

<comment><USER75> Here's a little bit for you. Most people prefer the semantics of `let` to `var` for variable declarations in JavaScript. It's how JavaScript should have been designed from the start. It has been officially standard for a year or two and became available in some browsers even earlier.

I want to use `let` (and `const`) for everything and never use `var` again, but I couldn't even do that on my own PRIVATE website (for me alone) until today, because I didn't upgrade my iPhone to iOS 10 until last night, and iOS Safari never supported `let` (or arrow functions or so many other things) before v10 (and Apple won't allow anyone to break their browser monopoly on their platform).

I could just use Android, but I can't switch everyone else to Android, and LOTS of Android and Windows (and even Mac) users are stuck with even older browsers, because they don't know how to (or can't) upgrade.

 _Are there any ES6 constructs that would require transpiling, to work fine on, say, Chrome or Firefox?_

Not on the latest Chrome or Firefox, but that hardly matters in a world where so many people aren't using the latest Chrome or Firefox. The question for a developer is not whether some in their market can run their software but whether some CAN'T.

 _Is ES6 not completely backward compatible with ES5?_

It is (in practice) completely backward compatible, but I suspect you are a little confused about what that means. It doesn't mean "forward compatible". Backward compatible means that a new ES6 browser is still compatible with old ES5 code, which it is. Old ES5 code will keep working. It does NOT mean that my new ES6 code, full of `let` and arrow functions will run in an old ES5-only browser, and there are still plenty of them out there.

As long as you choose to target a market that includes ES5-only browsers (and you may or may not, but if you do), the things that are new in ES6 (Google "what's new in ES6") have to be transpiled to ES5 to run in ES5-only browsers.

<comment><USER43> I get "const", but is "let" really that big a deal? Are your functions so deeply nested that you need block scope inside of if statements and for loops? (vs forEach callbacks or IIFE blocks or simply splitting complicated stuff into smaller functions)

There is some cool stuff in ES6, but "let" is kind of a yawn, and "class" most definitely is _NOT_ something I really needed.

But I'm still running ES5 on IE11 at work, so it's academic :-(

<comment><USER52> Sometimes you just need to do something the old way:

      let element = document.getElementById('some-element');
      while (element) {
        // do something
        element = element.parentElement;
      }

let doesn't get in the way with behavior such as hoisting, and the code will break if you redeclare a variable.

<comment><USER43> How does var/hoisting get in the way of that, or at least, that particular, construct?

FWIW, that would also be a nice "for" loop :-)

        var el
        for (
            el = document.getElement... ;
            el ;
            el = el.parentElement
        ) {
            // do something
        }

</comment></comment></comment></comment></comment></comment></comment><comment><USER76> Why no section on server-side frameworks? I for one picked Hapi over Express a couple years ago and have been very happy with the switch. I'd love to know what has changed since then!

</comment><comment><USER77> I would respect the JavaScript so much more if there wasn't so much faddishness - somehow JS devs have decided switch statements are bad, indenting with 2 spaces is the only way to go, semi-colons should be banished and "boilerplate" code should be hidden in libraries the magically wipe it away so your code looks "clean," if barely understandable without reading through a bunch of libs.

Edit: forgot to add that these are my initial impressions after diving into front end development with node and browserify. I ended up avoiding a lot of pain by just using TypeScript and a make file. Who has time to wade through umpteen million build systems?

<comment><USER20> > somehow JS devs have decided switch statements are bad

Nonsense. Though sometimes using an object can look cleaner depending on your use case.

> indenting with 2 spaces is the only way to go

I love 4 spaces and I use 4 in my JavaScript projects. Just because you've seen some subset of people use 2 doesn't mean it's the majority, what you have to use, etc.

> semi-colons should be banished

Absolutely, positively NO. Semi-colons are a requirement of the language. Some people elide them, incorrectly, because the JavaScript engines are good enough to still handle it. In my experience being playing a limited part in open source JavaScript eliding the semi colon seems to be a rarely done practice.

Regardless it's incorrect no matter how you slice it.

> "boilerplate" code should be hidden in libraries the magically wipe it away > so your code looks "clean,"

This sounds more like a rails-ism than a JavaScript-ism. Though you'd be hard pressed to find libraries without implicit behaviors in every language. Some people take DRY way too far.

This point just seems more anecdotal than anything else.

> a make file. Who has time to wade through umpteen million build systems?

A lot of JavaScript devs use make. Nothing wrong with that.

<comment><USER43> I think the semicolon requirement is more for broken minifiers than actually making the unpacked code clear/correct. But that's just me, I guess, as I have worked with many line oriented languages, and have no reverence for C syntax.

</comment></comment></comment><comment><USER78> Nice design.

</comment><comment><USER79> When I finally ended on the IDE page, I realized how the vast majority of these "5-10"\+ year veterans were very primitive developers. If you're using Sublime or Atom for Javascript development, I would say that you've spent too long working in and around these ever-changing tools without a useful IDE.

<comment><USER80> I'm happy coding in WordPad, GEdit, etc, and use Sublime today.

My view is that if you need an IDE to maintain your code effectively; if your volume of edits is such that macros and navigation tricks make a meaningful impact on your pace of development, then your code probably has serious architectural problems¹.

You see all impediments to action as debilitating, but I think impediments, carefully curated, can provide useful constraints on my development process. Friction helps me see where my interfaces are getting strained.

¹ I feel bad writing this because I know, if I step back from my own preferences, that your approach to development probably works great too. But your claim was so insulting, I'll leave this as is to match your tenor.

</comment></comment><comment><USER81> More info about the participants would be nice. How where they chosen ?

</comment><comment><USER82> Side note: The web design reminds me of the late 1990s... funny how it comes around.

</comment><comment><USER83> _ES6, CoffeeScript, and TypeScript all have near-perfect awareness, which surprised me since TypeScript isn't quite as popular as the other two yet._

I take issue with that statement. Just anecdotal, but I think these days Typescript is much more "popular" than CoffeeScript

<comment><USER84> Anecdotally, CS appears to have lost quite a bit of popularity while TS gained some.

RedMonk seems to confirm these trends. TS grows while CS stagnates:

Q1 2016: [http://sogrady- media.redmonk.com/sogrady/files/2016/02/lang-...](http://sogrady- media.redmonk.com/sogrady/files/2016/02/lang-rank-944px-wm.png)

Q3 2016: [http://sogrady- media.redmonk.com/sogrady/files/2016/07/lang....](http://sogrady- media.redmonk.com/sogrady/files/2016/07/lang.rank_.Q316.plot-WM.png)

<comment><USER30> Ts seems awesome but it looked like kind of a pain with separate ts and js files, mandatory type definitions not being present for lots of dependencies, and back when I looked at it seeming pretty all or nothing. I like flow. The people that built ts are brilliant too though. Curious if anyone has a good comparison between flow and ts. I've heard ts has improved a lot lately.

<comment><USER85> > mandatory type definitions not being present for lots of dependencies

That is the biggest detriment to typescript in my book. I played around with it for a bit but finding accurate (and up to date!) type definitions for external dependencies was a huge pain.

</comment></comment></comment></comment><comment><USER86> This seems to suggest the rate of framework churn has rather settled down. Are JS devs finally starting to be satisfied with their current tools and not needing to restart every 18 months?

<comment><USER32> I see this same, tired old meme in every thread about web technologies.

It's funny to me that certain people are so disdainful of the churn in web development on a forum dedicated to "hackers". Web application development is hard, and the reason why there's so much churn is because smart, inventive people are constantly finding better ways to do things. Things aren't just resetting from scratch every 18 months. The web apps I'm working on today are way more modular, composable, testable, and maintainable than the ones I was writing as little as two or three years ago. Just because Java systems development hasn't changed significantly in the last 5 years doesn't mean Java devs are any more or less reasonable developers than web folks.

<comment><USER87> > _"... the reason why there's so much churn is because smart, inventive > people are constantly finding better ways to do things."_

It also follows that at some point, these smart, inventive people will come up with fairly stable frameworks that are sufficiently flexible and powerful to accommodate most of the problem space out there. It is reasonable to ask if such a point has been reached...

<comment><USER88> JavaScript has been around since the 90's; a quick scan of this page reveals around 2 dozen JavaScript technologies. The only solution is to remove JavaScript from all browsers and replace it with Java.

<comment><USER30> Try GWT ;-)

</comment></comment></comment></comment></comment><comment><USER89> Great report.

I'm very satisfied with Clojurescript.

<comment><USER90> Bit weird that the "Web Framework" section didn't have any Clojurescript libs at all considering it was on the list, heh. Re-frame, Om... Mobx looks pretty based on reagent, heh

</comment></comment><comment><USER91> Never heard of the survey maybe the data is biased to only approach people on the silicon valley where technologies are used as if they were current season premium fashion cloths.

<comment><USER3> 9k responses certainly weren't from SV alone. I know alot of the Spacedojo Slack channel took the survey and I think like 2 out of 300 live in SV.

Would be fun to maybe turn ip addresses into lat/long and map out where the responses came from...

<comment><USER91> exactly this is my point, maybe the data is biased to US developers mostly

</comment></comment></comment><comment><USER92> (Thin sans-serif grey body text means you hate your readers.)

\-----

edit: I've tried to read it now and this site is crappy as hell. Does anyone have a link to a coherent write-up of these results?

\-----

Furthermore, I know it's bad form to mention your own downvotes but I dare you I DARE YOU to make a case for that horrible font choice. You can't because it's pure vanity. Style over substance. Thhhpppppt!</comment>


How web-savvy are you? - <AUTHOR> http://www.campushash.com/quiz/websavvy

<comment><USER2> Oh my, what lovely interaction design!

<comment><AUTHOR> Thanks a lot, but I used typeform.com for this. :)</comment></comment>


Ask HN: Is any ultrasonic aortic valve decalcification available to the public? - <AUTHOR> Hello YC community. One of my close relatives has been diagnosed with
calcific aortic valve stenosis recently.
So, I'm looking for a non-invasive therapy to treat Calcific Aortic Stenosis (aortic valve decalcification).
What I found so far is focused ultrasound treatment for heart valve calcifications by Cardiowave, but their treatment is not available for the public yet. They did trials in France and The Netherlands.
Does anyone know similar treatment/ company/ organization / clinic who can be of any help? <comment><USER2> Speaking here as a Doctor the medical paternalism of this post may immediately disqualify My comments from some on this forum who have a tendency to aim to hack their own bodies the way they hack technology. So I apologise in advance should that reaction occur. However.

There are elements of your relatives case that make adequate commenting very difficult.

For instance, what is their age, what is their leaflet anatomy (bi or tri leaflet), what is the valve area, and is there calcification of the aortic root and what is their NYHA grade.

Aortic stenosis is a condition with high morbidity and mortality if untreated.

Elderly patients can do quite well depending on leaflet anatomy with transcutaneous aortic valve replacement (TAVI) - this is preferred for more elderly patients because the replacement valves don't last as long as tissue or metallic valves (which last from 10ish to 30ish years respectively).

Due to the high morbidity and mortality associated with it, really the best thing your relative can do is listen to their cardiologist and cardiothoracic surgeon.

No-one really wants to have a zipper or go on bypass and it can be quite confronting but hunting down unproven miracle cures for a procedure that is exceptionally routine and has generally excellent results for patients with minimal comorbidities is a fools errand in my opinion

</comment><comment><USER3> Disclaimer: this is not medical advice.

-The severity of aortic stenosis determines whether any intervention is indicated. Only a cardiologist or cardiac surgeon can reliably make this determination.

-The aortic stenosis procedure with the strongest evidence base is transcatheter aortic valve replacement, or TAVR. See the PARTNER 3 trial, [https://www.nejm.org/doi/full/10.1056/NEJMoa1814052](https://www.nejm.org/doi/full/10.1056/NEJMoa1814052)

-Bear in mind that only a cardiologist or cardiac surgeon can apply the available evidence to a patient and make a recommendation. In some cases of severe aortic stenosis, despite the PARTNER trials, an open surgical valve repair is still a better option. Only a cardiac surgeon can decide this after reviewing all of a patient's information.

-The evidence base for other interventions is weak. These options should probably not be considered outside of the context of a clinical trial. You can look for clinical trials here: [https://clinicaltrials.gov/ct2/home](https://clinicaltrials.gov/ct2/home)

-Echoing other commenters, you should know that any procedure on the aortic valve has a risk of stroke. This would include any procedure that removes calcifications and possibly releases them into the blood. Only an interventional cardiologist or cardiac surgeon is qualified to discuss these risks in detail.

<comment><AUTHOR> Thanks for the information and for trials link

</comment></comment><comment> Engineering-MD I would be wary of what you find in this search, especially here. Medicine and healthcare is hard, and novel treatments are frequent, but rarely actually work, and can cause significant harm. That's why there are multiphase trials (1-3) and even then significant harm can slip through the net. From what I can see from a quick skim, this is very much still in trials (phase 1 at that) and not an accepted treatment. Why pursue an unproven treatment instead of the current standard? TAVI and surgical valve replacement are both suitable treatments for the majority.

I guess I just don't see the reason for pursuing a treatment option outside of what is recommended by a specialist who has assessed the person in question.

</comment><comment><USER4> IMHO you should look for the therapy that works better and is more extensively tested. If is more or less invasive, shouldn't be the main factor of choice.

I assume that removing a clot in the aortic by ultrasounds could have consequences when the debris accumulate in another part of the blood stream. This technology should be used with great care (probably, I'm not an expert in aortic plumbing) and probably in combination with anticoagulants. Ask a professional about by-pass and valve replacement instead.

Just an opinion. This is not medical advice and your mileage may vary. Think that if something goes wrong you will want a real physician close and the blood resources that only an hospital can provide ready to use.

<comment><USER2> FYI bypass is for coronary arteries. Calcification of the aortic valve and root is something quite different

</comment></comment><comment><USER5> Ivor Cummings is an engineer that investigated hearth disease based on first principles. He has made some interesting connections with diet and calcification. He always stresses that CAC scans are of vital importance. This interview is with someone who has successfully reversed a severely calcified Hearth Artery: [https://youtu.be/OtyMr1WpPaI](https://youtu.be/OtyMr1WpPaI)

<comment><AUTHOR> Thanks!

</comment></comment><comment><USER6> Pages 97-100 of "Vitamin K2 and the calcium paradox" by Kate Rheaume-Bleue, B.Sc., N.D. presents a clinical anecdote describing almost entirely reversing this condition in 10 months with daily supplement of 100 micrograms K2 MK-7 for a 69 year old man.

<comment><USER7> There's a double-blind, randomised, placebo-controlled study ongoing in Denmark exploring MK-7 as a treatment for AVC: [https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6112404/](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6112404/)

EDIT: There was an earlier trial, [https://clinicaltrials.gov/ct2/show/NCT01002157](https://clinicaltrials.gov/ct2/show/NCT01002157) ([https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4663571/](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4663571/)), exploring MK-7 supplementation for CAC which _should_ have been completed and the results published. The lack of published results doesn't bode well for efficacy.

EDIT: Here's a similar study for CAVD/AVC also still lacking results: [https://clinicaltrials.gov/ct2/show/NCT02917525](https://clinicaltrials.gov/ct2/show/NCT02917525)

<comment><AUTHOR> Many thanks for the resources!

</comment></comment></comment><comment><USER8> I think there's a diet and exercise regiment that is thought to stop and possibly reverse the calcification of arteries (and I assume valves). This probably isn't an option if his calcification is acute, which is usually the case because people only find out about it after a major event.

I think it goes without saying - do your own research and consult a physician. PubMed is a great resource.

<comment><USER8> Not sure why this is downvoted. Even with other treatments, diet and exercise are still an important part of recovery and future prevention.

[https://pubmed.ncbi.nlm.nih.gov/29074383/](https://pubmed.ncbi.nlm.nih.gov/29074383/)

[https://pubmed.ncbi.nlm.nih.gov/29539583/](https://pubmed.ncbi.nlm.nih.gov/29539583/)

[https://pubmed.ncbi.nlm.nih.gov/19772957/](https://pubmed.ncbi.nlm.nih.gov/19772957/)

[https://swansonhealthcenter.com/health- issues/calcification-...](https://swansonhealthcenter.com/health- issues/calcification-of-arteries/) (they don't list sources for everything)

<comment><AUTHOR> Thanks for the information!

</comment></comment></comment><comment><USER9> i think u should consult a doctor not news.ycombinator

<comment><USER10> Sensible advice to be sure, but no need to preclude discussion here

<comment><AUTHOR> Totally agree.</comment></comment></comment>