Has Vue passed React yet? - <AUTHOR> https://hasvuepassedreactyet.surge.sh <comment><USER2> I kind of think this herd mentality in the tech industry is annoying. There are a lot of people using React, but that doens't make Vue a bad choice. Conversely, just because Vue is new and relatively popular doesn't make it the "new React." Pitting them against each other like this is disingenuous, as engineers will make choices and use both — it's not like picking React will kill Vue or vice versa. That doesn't say anything about the likes of Ember and Angular that are still in use.

A good comparison is backend stacks. Rails exists, but so does Laravel and Django. If it were truly a big deal which was the biggest, then only one choice would remain. Instead, they all have healthy ecosystems with companies using all three.

It doesn't have to be a war.

<comment><USER3> I wonder if it's a nerd thing.

"Linux is better than Windows"

"Android is better than iOS"

"Python is better than PHP"

"Vim is better than everything else"

<comment><USER4> Once you get old enough, you realize everything is shit and nothing is better than anything else because, again, it's all shit.

<comment><USER5> Especially when you work in enterprise, and even more so when you work in public sector enterprise.

We're using tech that's outlived more fads than I can count, yet I'm still surprised when younger hires insists on using stuff that's basically supported by one man.

I'll admit JAVA almost made it to the list of techs we were going to have a conversation about in the late 00s, but these days it's as relevant as ever. So is C#.

The front end is nothing but terrible though. I trained a few of my employees to do angular, and then they had to relearn things with angular2. Maybe that's not an issue for start ups where youngsters slave away in their free time, but it cost me roughly $60.000 in expenses and missed work to retrain our people.

<comment><USER6> > I trained a few of my employees to do angular, and then they had to relearn > things with angular2

Had to? Did you hit the limit of the things you could do with AngularJS?

Your developers probably decided to move to Angular2 because it was new and shiny, and when they'll be out for a new job it'll look good on the CV. I doubt there was _any_ business reason for investing those $60k.

<comment><USER5> There are several business reasons to do update, I'll take you through a few if them.

* We operate a lot of IT systems, some of them are build in corporation with smaller local firms. This isn't necessarily the most sound decision financially, but it's a political decision to support the local area. We handle the business end, the project management, we do fairly strict code reviews and we take over once it's ready for operations. I said it wasn't the most sound decision financially, but so far it's actually been a cheap way to develop smaller user friendly functionality in a lot of areas. None of these small companies have AngularJS qualified people anymore, and haven't had for a while.

* I can't hire people to do AngularJS. It didn't stick around for long enough for any real talent to develop on it, at least not in Denmark. I'm not hiring from the most lucrative position either, mind you, it's the public sector after all.

* I don't want to operate two Angular versions in my stack. I already manage more than 500 different IT systems, it'd be crazy to manage more JavaScript frameworks than I have to.

* I spend a lot more than $60k upgrading my employees. A few of my developers wanted to go with Angular 2 rather than stick with AngularJS. I'm perfectly fine with that. They could've learned something else, but I generally let my employees chose their direction as long as it also makes sense on the business end. This upgrade was perfectly fine with me.

Unless Google does a completely new take on Angular2-6 in the coming years, it'll turn out to save me a lot more than the $60k in the long run.

<comment><USER6> It's fine, just none of the reasons you gave is an actual business reason. Basically you moved to Angular2 because everybody else around did, and it would have been harder to recruit and to keep developers, and to interact with developers of other companies.

They're perfectly valid reasons, but they have nothing to do with the quality of tool, or of the product, or with the cost sustained to develop it. Basically you had to move on just to stay exactly where you were.

<comment><USER5> You're not really reading what I write, are you?

<comment><USER6> Am I missing a bit of sarcasm in the first line, maybe? Yes, you are right, those you list are all valid business reasons. They just don't have anything to do with the frameworks: if everyone had made the inverse move from Angular2 to AngularJS, you would have done the same for the exact same reasons. Do you agree?

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> According to Google search traffic, React is 10x popular:

[https://trends.google.com/trends/explore?date=today%205-y&ge...](https://trends.google.com/trends/explore?date=today%205-y&geo=US&q=%2Fg%2F11c0vmgx5d,%2Fm%2F012l1vxv,%2Fm%2F0j45p7w)

According to NPM download stats, React is 6x larger:

[https://www.npmjs.com/package/react](https://www.npmjs.com/package/react) [https://www.npmjs.com/package/vue](https://www.npmjs.com/package/vue)

For Vue to catch up to the number of React stars would mean that their rate of starring is significantly higher.

I wonder if rate of new Github stars are a leading indicator of future popularity increases? Probably? Would be interesting if someone could study that.

Weird thing, commits to Vue are decreasing over time and are mainly done by a single individual - I've never seen that pattern in a popular library: [https://github.com/vuejs/vue/graphs/contributors](https://github.com/vuejs/vue/graphs/contributors)

While commits to React are regular and come from a much wider base of contributors: [https://github.com/facebook/react/graphs/contributors](https://github.com/facebook/react/graphs/contributors)

The writing is clearly on the wall (or the stars are on github), Vue is definitely going to overtake React usage in the long run unless another new library appears or React changes significantly.

<comment><USER8> Comparisons in Google Trends are extremely easy to manipulate (or just interpret wrong). The ".js" you added to Vue is killing its results, and the generic term "react" is propping that one up.

[https://trends.google.com/trends/explore?date=today%205-y&ge...](https://trends.google.com/trends/explore?date=today%205-y&geo=US&q=vuejs,reactjs)

or how about

[https://trends.google.com/trends/explore?date=today%205-y&ge...](https://trends.google.com/trends/explore?date=today%205-y&geo=US&q=vue.js,react.js)

Maybe alexa matters?

[https://www.alexa.com/siteinfo/vuejs.org](https://www.alexa.com/siteinfo/vuejs.org)

[https://www.alexa.com/siteinfo/reactjs.org](https://www.alexa.com/siteinfo/reactjs.org)

Or maybe one community uses their respective primary domain more than the other for one reason or another.

React also has more than 4x as many dependent packages in npm, which could be propping up its install count.

<comment><USER7> > Comparisons in Google Trends are extremely easy to manipulate (or just > interpret wrong). The ".js" you added to Vue is killing its results, and the > generic term "react" is propping that one up.

The search I linked to is not a keyword search but rather extracted topics. Your criticism is just based on misunderstanding how Google trends work. Not saying it is accurate but in both of your "corrections" to my link you are getting less accurate Google Trend results.

<comment><USER9> You typed vue.js so technically your results are less accurate. :/

Regardless of the fact Google trends is not even an accurate way to gauge usage of vue or react to begin with.

<comment><USER7> Vue.js category that I used is the official Google aggregate category. You do not understand how Google Trends work. There are keywords you can use or you can pick Google aggregate categories. I pick the aggregate category, which generally should be the most accurate.

I am not responding to any more because it seems that people refuse to understand it.

<comment><USER10> Quite likely Google is underrating Vue, because Vue has heavy presence in China and Google does not.

</comment></comment></comment></comment></comment></comment><comment><USER11> Stars don't matter. If we want a measure that's actually meaningful to some developers, look at job postings.

Anecdotally from my on and off job searching, React leads here by orders of magnitude. And unfortunately for me, my Vue personal experiments/side projects have to be put in the sideline for a bit. Many people I've talked to want direct React experience and not just experience in reactive frontend stuff.

<comment><USER12> Meanwhile we're still using ASP.Net MVC w/ a vintage 2008 web design. Could care less about $latest_web_technology, because having a viable business is more important than what the site is coded in or how it looks.

<comment><USER13> While that is a valid point and a company should never leapfrog to the new hotness. Using outdated technology can have major pitfalls with technical debt. Also looks, ie ui/ux does matter greatly. A modern Android app wins vs something built for 4.0

<comment><USER14> UI look really only matters in competitive consumer markets.

In B2B spaces where there are limited competitors and vastly different levels of investment involved for the users, the UI largely becomes irrelevant as long as it works.

<comment><USER13> I have evaluated b2b on a regular basis, features matter, but UI absolutely matter to me when I make a recommendation. If it looks like shit from the 90s I won't even put it on the list. If it doesn't have a solid UI it's a nonstarter.

I've recommended other b2b services over Salesforce because they have such a shitty UI and it worked out nicely.

<comment><USER15> There's a lot of other reasons to run the other direction from Salesforce. Ugh, their REST api...

<comment><USER13> While I hated their stupid custom software I think it worked over rest API. That was probably was a better feature they had, which isn't saying a lot.

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> Microsoft just announced they are betting big on React, and a quick search at JS/frontend job posts only show React and the odd Angular/Ember ones in my area.

Stars might matter to some but it looks like React is here to stay and be the most supported and used library for some time.

<comment><USER17> React is the heavyweight, no doubt, but it also feels heavy for smaller projects. VUE is a great option and believe it or not Meteor just announced 1.7 with at least one killer feature: Babel-free JS for modern browsers.

[https://blog.meteor.com/meteor-1-7-and-the-evergreen- dream-a...](https://blog.meteor.com/meteor-1-7-and-the-evergreen- dream-a8c1270b0901?gi=c82300da60f4)

It's good to see Vue gaining steam as more options = better fit per project.

<comment><USER18> What does heavyweight mean?

<comment><USER19> The term comes from the name of a boxing weight class; the analogy is that a heavyweight would be hard to "knock out" of the fight. In this case, it means that the existing market share of React and resources of the team behind it will make it hard to displace. Note that in this case, it doesn't necessarily refer to the perceived bloat of the framework (although a pun may have been intended).

(Apologies if this was rhetorical and I ruined the point you were trying to make)

<comment><USER18> Seems like a great contender for a small project then. KO in no time :).

</comment></comment></comment></comment></comment><comment><USER20> I'm always baffled by web developers constantly moving to new frameworks and toolchains. I can't really think of other sectors of development that chase as many fads. I mean its one thing if it solves a significantly new problem, but a lot of times it comes down to like "so and so likes gulp better than grunt or sass better than less and they're going to stall the project for two weeks while they switch the codebase over while pretending they're fixing tech debt". In game development, where developers are frequently on the cutting edge of things, the idea of switching engines and apis all the time for marginal benefits would get you a lot of raised eyebrows, and im guessing desktop app developers and people into scientific computing feel likewise. Don't get me wrong things evolve, but code in those fields doesn't seem to be treated as disposably.

<comment><USER21> > I'm always baffled by web developers constantly moving to new frameworks and > toolchains

I'm baffled why anyone thinks anything like this is actually true. So everytime you see a JavaScript or CSS library or framework posted to HN, you think all JavaScript developers switched to it? Game development has well over 1000 engines to choose from. I don't assume you switched from unity to Godot when it showed up on HN.

</comment></comment><comment><USER22> Vue: 238,410 weekly downloads

React: 1,596,809 weekly downloads

(from npm)

<comment><USER23> I wonder though, how CDN links might mess with this comparison? And whether devs are more likely to use the CDN version with Vue vs React.

</comment></comment><comment><USER24> To me the most obvious technical competition for Vue is Angular, not React, and if Microsoft were going to choose something other than React, I would've presumed it would be Angular.

Both Angular and Vue have a similar component DSL and contrasts from React by trying to have a complete out-of-the-box experience, rather than the build- your-own framework style of React. But Angular is backed by Google, and it supports TypeScript out of the box as well as RxJS, which is somewhat of a cross-platform API for async. Unfortunately I think the Angular reputation still suffers from its Angular 1 days.

<comment><USER25> I think you're spot on about Angular 1. I really like Angular myself despite that transition issue but I also like React and Vue. I currently use Angular for larger web projects (it's more complete out of the box), Vue for smaller web apps and widgets and React Native for mobile.

</comment></comment><comment><USER3> I often read "I chose Vue because it feels easier than React".

Programming in React requires some basics in JavaScript and functional programming. It helps if you already have a dev background, but if not, then you will learn things really useful for a developer. And not only for frontend dev.

Then you just have to learn the React API: 4 concepts (component, state, props, render) & 3 functions (didMount, didUpdate, willUnmount).

<comment><USER7> Ease of use matters.

<comment><USER26> I found the biggest barrier with react in understanding concepts, not learning API. API is 3 methods as mentioned above. Once you got the concepts you will never go back to old ways.

</comment></comment></comment><comment> crooked-v As somebody who really likes Vue, I feel like it's hampered by comparison by not being able to use "real" JS in the bulk of the view templates. There's a lot of minor boilerplate annoyances in outputting stuff that go away when you can do array maps and Ramda functions as a direct part of your rendering.

<comment><USER27> Vue supports both JSX and JavaScript rendering functions and has for a long time (since at least v2.0 IIRC)

</comment></comment><comment><USER28> I wish Ebay's Marko got _any_ mindshare. It'd be nice if our choices weren't limited to React and Vue.

[https://markojs.com/](https://markojs.com/)

<comment><USER29> That link is blocked in China.

</comment></comment><comment><USER30> Why should anyone care how many github stars one library has compared to another?

<comment><USER31> Github stars are proportional to the size of the community.

You don't want to bet your company on a project with only a few thousand stars, it could die quickly.

<comment><USER32> Anecdotal counterpoint: I star projects to bookmark them, so that when I have a spare moment I can go through the list and find interesting repos that I might use. But I typically don't unstar later if I stop using something. I should, but I just don't "clean" my collection that often.

<comment><USER33> +1 for this - I star things to come back to and try out. I've started Vue for this reason, unlike React which I use in working hours

</comment></comment></comment></comment><comment><USER34> This frames it a lot as a competition; it really isn't. Facebook Open Source is a contributor to Vue.

I think it just resonates with the community that this is a Patreon-backed, very community-driven project, whereas React has Facebook behind it, and Facebook has been controversial. Not that that has much to do with React itself-- if anything it means it probably scales well.

Either that, or it's another iOS vs Android situation, where people just like picking teams.

</comment><comment><USER35> Competitive angle aside, Vue deserves all the stars it gets.

It's a pleasure to work with and a much needed tool in the frontend landscape. The more mindshare it gets the better for everyone.

I'll keep on rooting for it!

</comment><comment><USER36> Reminds me of [http://isitsnowinginpdx.com/](http://isitsnowinginpdx.com/).

I'm rooting for Vue.

</comment><comment><USER37> Do we consider js frameworks to have 'jumped the shark' when they descend to the same sort of popularity polling as a reality TV contest? :)

(I am tongue in cheek here - I realise stars <> actual usage in the wild, and the results can be gamed).

For what it is worth, as a 35+ year veteran in the software coding world, I tried dabbling in both frameworks, and Vue seemed to make more sense to me and fitted my mind's view of how things should work.

<comment><USER38> _fitted my mind 's view of how things should work_

Why so? Could you add some detail to this comment?

</comment></comment><comment><USER39> Both are outdated. Cycle.js is the new framework. :)

</comment><comment><USER40> I just starred it, and moved it across the finish line! I actually do like Vue.js more than react, so it wasn't just for the fame!

</comment><comment><USER41> I prefer Mithril.js, used from TypeScript, with Tachyons for inline-ish CSS. That is what I use when I have a choice like for personal projects that are single-page applications (e.g. StoryHarp, NarraFirma, Twirlip7 on github). That way almost all code is in one language and can be easily refactored. Mithril is most naturally used via a "HyperScript" API where you define DOM/vdom nodes via function calls -- e.g. m("div.ba.bw2", m("span.blue", "Hello World")). Templating systems (including JSX for React) are unfortunate crutches which ultimately make development harder because they get in the way of refactoring, modularizing, and testing. And typical semantic CSS use (e.g. .warning vs. .red) often ends up in a messy snowball where people eventually are too afraid to remove anything -- whereas if you make your components in JavaScript code, you don't need semantic CSS. It turns out that "best practices" for server-driven Web 1.0 applications (e.g. HTML-ish templates and semantic CSS) often are "worst practices" for JavaScript-first single-page applications.

React also is overly complex because it tries to over-optimize redrawing speed through encouraging components to maintain a lot of local state using setState -- even though the increasingly popular Flux model encourages global-ish state for one-way data flow that makes the internal workings of UIs easier to reason about. Mithril is more Flux-ish out of the box in terms of the design patterns it encourages. Mithril's default behavior is based on rerendering the entire current vdom tree any time the user interacts with a DOM element or after a network request completes -- and the Mithril community only encourages optimizing beyond that if there is a specific performance issue. (You need to add your own redraw calls in callbacks for timeouts and a few other cases.)

That said, I can understand how the herd mentality shapes the employment landscape for both programmers and their managers. It does in my own work life too -- where I have spent a couple of years working in Angular for my day job despite knowing what a mess of accidental complexity it is compared to something like Mithril. Angular was chosen years ago by other developers before I joined the project -- developers who mostly did not stick around to suffer the maintenance consequences. At least new projects may be in something other than Angular -- typically React (which is at least better than Angular).

It's saddening how many times in my career I've ended up having to work with worse technology because of herd effects -- despite knowing better alternatives existed and having personal experience with them. For example, IBM chose to promote Java instead of Smalltalk in the late 1990s (despite having two Smalltalks it owned). Or Netscape ultimately foisted a Java-ish looking JavaScript on the world when Brendan Eich was originally recruited with the promise he could write a Scheme for the browser. Although, as with both Java and JavaScript, after a couple of decades, most of the worst rough edges are worn smoother and many of the worst bugs are fixed, and so the developer experience for both by now is finally not that bad.

<comment><USER42> Have you used Elm and if yes, what do you think about it. As far as I have seen, it blows everything out of the water for me. It feels a bit weird at first, and It may not be just there yet in terms of features, but the paradigm is solid.

<comment><USER41> I have not used Elm other than to play with it briefly. I see a lot of great praise for it though. It seems like a great set of concepts (including design choices for functional, immutable, and static support -- a bit like Clojure in the first two) and is very Mithril-like in its vdom and redrawing approach. I think I would enjoy programming in it. I can see why many people have the reaction you have -- especially if they come at Elm from, say, using ES5 JavaScript and some complex UI library like AngularJS or Dojo/Dijit or whatever else.

Why have I not switched? It is useful to disentangle the value produced in Elm by using vdom (similar to Mithril) versus the value produced by Elm being a better language than JavaScript. Both are true, but which one provides more value in different contexts?

When I researched Elm in the past, I also read posts by a few people who moved away from Elm due to integration issues with the rest of the JavaScript ecosystem (as well as a miscellany of typical other issues any new language has related to bugs/tooling/libraries/platforms/etc.). Whether those criticisms of Elm by past users were fair -- or whether they still are true -- I do not know. But those issues were about the language, not about the vdom/redrawing paradigm.

It seemed to me that TypeScript was a safer bet three or four years back for me to choose for myself over other compile-to JavaScript languages because I would also be learning plain JavaScript better at the same time -- and learning plain JavaScript well seemed like a good thing to do.

These are really tough choices given moving targets for languages and libraries -- including trying to predict where communities and designs will be in a few years.

JavaScript is a badly designed language because in trying to make things "easier" for non-programmers writing a few lines of code (like making vars global by default) it made programming much more difficult for anyone doing anything more complex. Languages like Elm (or many other compile-to-JavaScript languages, even C++ now given WebAssembly) can fix those core issues in JavaScript (given no need for backward compatibility) and are appealing for that reason even as they may have their own challenges.

And as a negative, TypeScript only goes half-way there to a better language -- leaving many of JavaScript's warts in place. Just one example of such a wart is the many globals defined on "window" which make it appear a local variable might be defined when it is actually some global value being referred to (e.g. "length" or "name" are defined as globals on window as in "const x = length"; for more gotchas see: [https://developer.mozilla.org/en- US/docs/Web/API/Window](https://developer.mozilla.org/en- US/docs/Web/API/Window) ).

But that said, typically issues comes up in any framework or language that involve a "leak" in the abstraction. And then you need to learn about the surrounding system to make your application work well. While things may change in a ten years, right now, to make a good Single-Page Application for the web, you need to learn the basics of HTML, CSS, and JavaScript fairly well. I don't feel there is any substitute for that. I've tried (e.g. using Dojo/Dijit) and gotten burned. One thing I like about Mithril is that, vdom aside, it keeps you close to the "metal" of HTML/CSS/JavaScript with just enough support to handle repetitive issues well while not getting in the way and being relatively easy to debug.

Decades ago when I learned BASIC, I had already learned assembly language before that, and digital electronics before that. The combination of BASIC and Peek-ing and Poke-ing assembly language was great. But just knowing BASIC would have left me pretty mystified about what was going on under the hood of the computer.

I think the same would be true for someone whose first browser-based language was Elm or Java/GWT and not JavaScript. After learning the basics of HTML/CSS/JavaScript (the assembly language of the web), then sure, learning and using other languages like TypeScript or Elm can potentially help a lot -- though with tradeoffs (like Elm integration issues mentioned above).

For simpler things, I find just plain ES6/ES7 with Mithril actually works fairly well given JavaScript has improved a lot with ES6 and ES7 (especially with "let", "const", and "async/await").

For Elm and me personally, it is undoubtedly better to use than JavaScript/TypeScript in-and-of-itself, but having gone up the learning curve on those, whether it would be worth a switch at this point, I don't know. It clearly is "better" as a language -- but I am not convinced it is so much better as to make up for other possible downsides. There are a lot of great languages out there.

Personally, I am tempted by Elixir as a next language to learn (given Erlang's fundamental design beauty). But I feel productive enough in TypeScript and ES6/ES7 at this point (years into the learning curve on "the good parts") that I don't feel an urgent need to do that. Likewise for Clojure/ClojureScript which many developers also love and is also tempting. Or even Scala which can compile to JavaScript.

Anyway, for all my complaints about herd effect, I am sorry to bring up those sorts of issues as negatives for Elm given how entrenched plain JavaScript is right now. One of the problems with making choices like these is that people rarely switch languages because the alternative is 1.1X or even 2.0X better for some task overall. They tend to switch when something is 10X better. And that is a high bar -- especially if you compare Elm against TypeScript+Mithril+Tachyons and not ES5+AngularJS.

</comment></comment></comment><comment><USER43> I use Vue at work every day. We build large applications in it and it's extremely pleasant to use.

That said, I wouldn't use a number of stars in Github as more than an indicator of people pushing a star button in Github.

I've starred many things so that I can remember them some day. If I use something every day it's most certainly not starred.

</comment><comment><USER44> Question for Vue users: whats the value prop over React?

I haven't had a chance to look at Vue in depth but it seems to me that its useful for building apps where you don't need a build tool which makes sense to me.

The main thing I don't get is why use Vue over React if you're going to use single file components with some kind of build tool?

<comment><USER45> > Question for Vue users: whats the value prop over React?

I'll paste my comment from another post in this thread:

>> I hear a lot that "Vue is easy to learn"...

> That's why I started working with Vue. It seemed easier to approach for > someone coming from a server-side language perspective (I'd mostly worked > with Python/Flask and PHP/Symfony before). I could slowly ease into using > pieces of it until I learned enough to write a whole project in Vue. You can > probably do the same thing in React, but the Vue docs were written to > address my use case.

</comment></comment><comment><USER46> Github stars are a rather meaningless proxy. Many people like have all the major libraries starred but actual usage is quite different.

Vue is great, but React has about 10x more libraries, frameworks, components and just general "stuff" built around it, along with the mindshare that it brings.

</comment><comment><USER47> Provocative and simply wrong.

</comment><comment><USER48> Microsoft rewrote the whole thing in React Native! It's like keeping score of the opposing team in the match when they have already qualified for the Olympics. Play the long game.

</comment><comment><USER49> I used to hate react, but being forced to work with it for a while has helped me get used to it. I still very much prever vue so this is great news to me.

</comment><comment><USER50> meh, I've given up. At the end, it's whatever your client wants and will ultimately pay for. React is popular in enterprise circles, Vue.js is also popular amongst new front end developers and seasoned.

In a few years it won't matter as deep learning will generate front end UI with just a wireframe sketch.

</comment><comment><USER51> It will pass React, when they're more Job posting about Vue more than React. The market determines the winner not GitHub stars. Even here on the HN WhoIsHiring threads, React is miles ahead of anything. brutal law of the market, Vue is pleasurable to use, but the market doesn't care what you think or care about.

<comment><USER52> I see a lot more jobs on Angular(2+) and React in Australia. Hardly ever do I see Vue mentioned in jobs and I don't even hear people talking about it. Even while starting a new internal project, people are just comparing React vs Angular. But my exposure to frontend stack is limited so I could be wrong.

</comment></comment><comment><USER53> Because vue is Chinese and China has huge population of developers! lol Haha

</comment><comment><USER54> I just starred Vue to give it 100,000 stars.

I'm feeling irrationally happy about that.

</comment><comment><USER55> Loading...

(iPhone safari)

</comment><comment><USER56> Does this mean Nativescript will be on the rise?

</comment><comment><USER57> 22...17...15.. It's about to happen.

</comment><comment><USER58> People are actually un-starring react.

</comment><comment><USER59> vue makes coding so much more enjoyable than reqct for me that im glad to see it get more traction

</comment><comment><USER60> I love Vue!

</comment><comment><USER61> It's happening!

</comment><comment><USER62> I just starred Vue to make it even with React at 98,564

</comment><comment><USER63> Woot! Go Vue.

</comment><comment><USER64> People say that "you only have to learn a few things to know react" and that with Vue you need to learn this whole API and well that is just too much to learn! These people are of course just trying to find an argument to match their emotional investment in a product. It isn't a real argument and can be refuted with logic and maths.

I started a node/express/vue project about 6 months ago. Here are the APIs and syntaxes and so on I had to learn:

Mongoose API

MongoDb API

Express API

HTML5 Validation and Validity API

Fetch API

Bootstrap 4 API

Flexbox

some new javascript concepts like destructuring

Webpack/source maps/hot modules

Node

The differences between importing/exporting modules in node and the browser

Oh yeah, and the Vue API. You know what percentage of learning the Vue API was? About 0.01%. What is even more ridiculous is that it wasn't even the learning of the API that took the most time.

All of the concepts in Vue/React take more time to learn than the API of Vue. The differences between data and props, what reactivity is, how single page routing works, how components work, and so on. In fact, as React is so barebones, it probably requires more learning than Vue because you have to find all the other libraries to make it the full product.

</comment><comment><USER15> Maybe people could just stick with one frigging thing for more than 12 months? I'm sick to death of Javascript churn. Polish one thing up until it is actually done before chasing some shiny new half-baked thing like a cat with a laser pointer. A slightly different spin on MVC concepts from twenty or thirty years ago doesn't get me out of bed, much less rewriting my front-end code more often than I file my taxes.

<comment> xkcd-sucks Job security

</comment></comment><comment><USER65> hehe, my star passed it.</comment>


Improving startup time in Atom with V8 snapshots - <AUTHOR> http://blog.atom.io/2017/04/18/improving-startup-time.html <comment><USER2> New world, same old problems. Fascinating to see how this parallels the way Emacs tackled this problem long ago.

\- [https://lwn.net/Articles/673724/](https://lwn.net/Articles/673724/)

\- [https://news.ycombinator.com/item?id=11001796](https://news.ycombinator.com/item?id=11001796)

<comment><USER3> I don't recall overcoming long startup times in _vi_ and _vim_. Did I miss something?

<comment><USER2> Emacs and Atom share the architectural aspect of implementing most of their functionality in a higher-level language inside of an execution environment. This has costs and benefits.

 _vi_ had a much simpler structure and much more limited feature set. _vim_ is obviously a much more capable/flexible editor and has scripting support, but is still predominantly written in C.

</comment></comment></comment><comment><USER4> I'm way more worried about memory issues while running. Atom take up 1 gig+ with very little open. It pushes all my other tools out of RAM and into swap. Switching to the browser to see documentation takes a few seconds if I'm lucky.

Compiling a few more seconds to page in. Ssh a few more. Everything on my laptop slows to a crawl as they fight for RAM with Atom taking up the way more than it should.

I know the answer, "buy more RAM it's cheap", from the Atom people, but then my browser people tell me the same thing. So do my interface people, and my kernel people, and by the time I say "okay" to all of them, I'm out of RAM again.

Application need to learn they aren't the only thing running. For some reason, my machine seems to be getting slower and slower no matter how much I upgrade.

<comment><USER5> > For some reason, my machine seems to be getting slower and slower no matter > how much I upgrade.

I've been feeling this way for years, and I've mostly ascribed it to my faulty perception. I figured that if things simply aren't _getting faster_ (i.e., they're not changing at all), I'm probably just _imagining_ them getting slower.

But then I start wondering why _aren 't_ things getting faster...

<comment><USER6> amdahl's law

</comment></comment></comment><comment><USER7> Is there any way not to conclude they have just been out designed/architected/optimized by Microsoft?

What a compliment to the VSC team that after all this work, Atom still doesn't seem to match startup time, or more importantly perceived performance while editing.

It's a more interesting comparison since they're both bound by similar constraints, and building cross platform apps.

In the bad old days I once worked for a MS competitor where there were often complaints of unfair competition. Most often around how knowledge of closed sourced OS internals allowed optimization insights unavailable to others.

Not all MS devs are great for sure, but I'm inferring two things here. The VSC team is pretty damn good, and that IP and institutional knowledge from decades of investment in dev tools probably helps a bit.

<comment><USER8> I'd offer the alternative theory that the VSCode team learnt everything they could from Atom's past mistakes.

Speed is only one of the issues–I'm actually quite happy with Atom in that regard. VSCode has a much more restricted API, and a more robust extension system. With Atom, I always felt like extensions started interfering with each other, and with the 'vanilla' experience. OTOH, I was exploring a few ideas, such as inline rendering of comments in markdown, and that's really only possible in Atom.

<comment><USER9> Sounds similar to the complaints about Firefox, though the only notable issues I've run into with Atom have been related to shared file editing (and resulting sync issues). If someone could just leverage etherpad lite with Atom, it'd make me so happy!

<comment><USER8> Firefox mostly has the problem that the open web suddenly became incredibly important for Google: it's their platform, in the fight against Facebook and Apple's iOS.

No organisation on the planet could compete with a team that Google considers a core asset for actual survival.

Mozilla has made quite a few mistakes, but the times may change, and I sure hope they'll be around when Google's incentives are no longer aligned with the open web's.

<comment><USER9> Google can be out-competed, look at their attempts at social networks & messaging/calling.

Google has lit dumpsters full of cash on fire in an effort to get anywhere near Facebook, Twitter, Whatsapp, Viber or even Signal Private Messenger, and yet their extremely fractured strategy that they have dumped R&D into still has less users than any of those in their respective categories.

Mozilla can be competitive, akin to Darktable vs Adobe if Mozilla chooses to be. No more mucking about bailing their friends out (ie: Pocket acquisition), or trying to fight Google on hardware prices (Firefox OS's entire strategy). Mozilla can create a playing field tilted in their favor, and force others to compete on their turf rather than duking it out on Google or Chinese OEMs turf.

</comment></comment></comment></comment></comment><comment><USER10> I'll provide a contrasting opinion to the comments saying startup time isn't important to them.

I tend to work chaotically. I dive into a project and tackle whatever the problem of the day is. The result is a sprawling mess of reference code pulled up in different editor windows, documentation and google results spewing out over 4 browser windows and 30 tabs, and just as many terminals managing VCS, compilation, tests, etc.

It's not that I'm a messy coder or anything; it's just that when I'm focused on a problem then my concern is about that problem, not about the growing heap of reference material. The problem is particularly pronounced when working on web applications, where I have to handle multiple code bases at once.

Once I'm done, I'll become horrified by the state of my desktop and proceed to close everything.

The next coding session starts fresh.

So startup time is actually important to me. I have to say I'm annoyed by VSCode's startup time. It starts up to a state where I can hit the menu and start opening things very quickly, but isn't completely finished for another couple seconds. Atom's in a very similar boat.

I'm glad to see progress being made here.

</comment><comment><USER11> Great article. Avid ST3 user here, but glad to hear about the improvements.

For anyone curious, I made a quick gif comparing startup times on my machine for Sublime Text 3 (Build 3129), Atom (1.16.0), Atom Beta (1.17.0-beta2, the one mentioned here), VSCode (1.11.2), and VSCode Insiders (1.12)

[https://media.giphy.com/media/3ohzdTHkfj5ISAAPq8/source.gif](https://media.giphy.com/media/3ohzdTHkfj5ISAAPq8/source.gif)

I should mention - my ST3 is heavily customized (28 plugins), while Atom and VSCode are absolute stock.

<comment><USER12> They all look to be within the same ballpark; none of those startup times would be a problem for me, at least. But when I tried Atom it was noticeably less responsive, which I have very little tolerance for. I haven't tried VS Code. (I also use Sublime)

<comment><USER13> My experience is that VSCode is much more responsive than Atom.

Just a lot "snappier". Startup is not much of a problem, I don't open ordinary files in VSCode or Atom by default (I use gedit for that)

</comment></comment></comment><comment><USER14> > Overall, on a stock installation, we made loading Atom almost _50% faster_ > and snapshots were a crucial tool that enabled some otherwise impossible > optimizations.

Note that this hasn't shipped on stable yet, but is available on 1.17 beta.

The article mostly lists the various problems and associated optimizations. Concise & nice read.

</comment><comment><USER15> Google long ago released Snappy Start, a tool for snapshotting processes, saving the full state to disk, so new instances can be launched faster. This is a more general Checkpoint-Restore capability than V8's impl and a bit different, but definitely somewhere in the same field of computer technology.

[https://github.com/google/snappy-start](https://github.com/google/snappy- start)

<comment><USER16> Seems also related to CRIU, which does something similar, but for the purposes of live migrating a process from one host to another. [https://criu.org/Main_Page](https://criu.org/Main_Page)

<comment><USER15> Yeah I probably should have lead with CRIU. It's been a longstanding ongoing project of excellence. A lot of people who work or worked (unsure of breakdown) on OpenVZ have been cranking on this for many year.

Work from the CRIU crew started getting upstreamed almost exactly four years ago, breaking some initial resistance to the tech needed for CRIU- [https://mobile.twitter.com/__criu__/status/58727373960931328...](https://mobile.twitter.com/__criu__/status/587273739609313281) [https://criu.org/History](https://criu.org/History)

It's interesting the breakdown in sell- CRIU is a swiss army knife of a tool, whereas Snappy Start and V8 Snapshots seem targetted and marketted largely towards fast "initialization" concerns.

</comment></comment></comment><comment><USER17> Emacs does a similar thing for startup time with dumping:

The Emacs dumper dispute [https://lwn.net/Articles/707615/](https://lwn.net/Articles/707615/)

</comment><comment><USER18> Funny how everything old is new again. Dumping an image, something seen with Emacs, and with SmallTalk and LISP languages since before Emacs was derided as "eight megs and constantly swapping" :)

</comment><comment><USER19> Unfortunately Atom is not on par with VSCode considering responsiveness.

There are a few more issues, _Emanuel Quimper_ summarized in: [https://equimper.github.io/2017/02/25/why-i-moved-away- from-...](https://equimper.github.io/2017/02/25/why-i-moved-away-from-atom-to- visual-studio-code-and-my-setup/) explaining why he moved from Atom to VSCode in detail.

A month ago there was an interesting submission in favor of Sublime Text 3. Mainly because of its incredible responsiveness: [https://news.ycombinator.com/item?id=13928752](https://news.ycombinator.com/item?id=13928752) by _Tristan Hume_ , comparing Vim, Spacemacs, Atom and Sublime Text. I highly recommend it.

My workflow now looks like this: VSCode+Plugins replaces my zsh+tmux+vim toolchain when running on AC. On battery zsh+tmux+vim provide VSCode+Plugins functionality with less beautiful gfx but unmatchable battery lifetime.

The zsh+tmux+vim toolchain is heavily customized, though: [https://github.com/rscircus/dotfiles](https://github.com/rscircus/dotfiles)

</comment><comment><USER20> I love it when new problems can be solved in old ways. In physics we say there aren't 10,000 problems there are just 10,000 manifestations of 5. And it really seems like that's true here. Maybe we should stop laying off people for being old lol.

<comment><USER21> The industry is doing fine without the old workers with outdated skillsets. Correctness does not matter as much as velocity to release.

<comment><USER22> No, industry is pushing food around the plate, and has been for some time. It must have been amusing (to some) to see WebSockets arise, when TCP sockets do the same thing. Why is a new standard needed? Because firewalls block everything but port 80 and 443, and every other program that uses non-HTTP sockets has all-but-died off (with the exception of some games).

90% of the "innovation" in application programming is just an exercise in combinatorial virtualization.

(That said, it's not all bad. The browser has had a remarkable and wonderful effect on GUI application architecture that probably wouldn't have happened elsewhere.)

</comment></comment></comment><comment><USER23> Interesting! Image-based development is actually really useful for many applications. It would be interesting to see V8 support this more generally. It's something I quite like about CL and Smalltalk systems.

</comment><comment><USER24> From the article it sounds like they're basing these tests off probably their dev machines. Seems like they should be trying this out on slower machines.

<comment><USER25> It sounds to me like they are testing it on slower machines (specifically slower hard drives), as they specifically call out one of the "smaller" optimizations as having a significant impact on machines with slower hard drives.

<comment><USER24> It sounded to me like they were extrapolating though, "This resulted in a ~100ms improvement on a fast machine with an SSD but, since most of this work was I/O bound, we expect it to be even more noticeable on slower hardware." This in fact was where I drew the inspiration for my comment from.

</comment></comment></comment><comment><USER26> From the article, they have the electron-link[1] module that anyone can use in a electron app to get the same functionality working. Not sure how it plays with webpcack.

[1][https://github.com/atom/electron-link](https://github.com/atom/electron- link)

</comment><comment><USER27> Minifying the code can also speed up the startup time ... Another trick is to auto-start the app and bring it to the background (invisible). Then when the user "starts" it, just make it visible.

<comment><USER28> Your solution is a good one, but I get kind of sad when I remember the context : launching a text editor :/

</comment></comment><comment><USER29> I wish atom would just add preloading. I be happy to always have a hidden, sleeping window ready to pop to front on request. There must be some reason this is harder than I imagine...

<comment><USER30> You can basically do that now: just don't quit. If you start Atom and it discovers that it's already running, it tells the running process to handle the request. It even honors environment variables and flags like --dev.

For example, starting Atom cold on my medium-sized project (by running `atom .` in the base dir) takes 6 seconds. If I close all windows but leave Atom running, do something else for a while, and then run that command again, it takes 3 seconds.

(That's still a disturbingly long time... but it's quick enough once launched. I like Atom enough that I can live with it for now.)

Edit: just tried the beta. It's a little quicker: 4.5ish seconds and 2 seconds. Still OK for long-term coding but too slow to be $EDITOR for things like `git commit`.

<comment><USER31> This is really simple procedure that should take like a millisecond why does it take seconds?

<comment><USER25> I always hated this argument. It feels to me like someone is complaining why a train can't go from 0-60 in 10 seconds while many cars can. The answer is always "because that's not what it's designed to do".

Regardless of how you feel about it, the team behind Atom made a design decision to sacrifice performance to gain a large amount of other benefits ("easier" higher level language, easy cross platform support, extremely easy to write plugins for it from it's target "demographic", etc...).

Because of those architecture choices, things like spawning a new window aren't as easy and straightforward as they might be in another architecture.

So just because you want a method of transportation that goes from 0-60 in 10 seconds, doesn't mean that all methods of transportation need to go from 0-60 in 10 seconds. And just because a method of transportation can't go from 0-60 in 10 seconds doesn't mean the designers were lazy or cut corners, it just means that they prioritised other things, and are solving different problems.

</comment></comment></comment></comment><comment><USER32> Oh man, I wish I could use snapshots in the browser. In some extreme cases, I'm dealing with multi-minute startup times.

<comment><USER33> I think v8 does cache machine code in some cases. There are a couple of flags in chrome://flags you'll want to look at:

V8 Caching Mode, V8 caching strategy for CacheStorage

[https://v8project.blogspot.ca/2015/07/code- caching.html](https://v8project.blogspot.ca/2015/07/code-caching.html)

Edit: Not the same as snapshots mentioned in the article

</comment></comment><comment><USER34> I started this issue a long time ago, and it's been frozen since: [https://github.com/electron/electron/issues/3041](https://github.com/electron/electron/issues/3041)

Maybe now we can have actual source code protection?

<comment><USER35> if you want to protect your source code, don't use Javascript.

<comment><USER36> >don't distribute your programs

That's what it really comes down to. From what I can see, it's mostly an emotional response. I'd be surprised if code/binary obfuscation is a net win in general.

I've had to disabuse developers of this idea. One distributed binaries that weren't quite valid but ran on the CLR, though not Mono. A 10 line script was enough to remove the invalid sequences. What did the developer gain in this case? An extra build step, undoubtedly more than one bug, and in the end, no "protection".

<comment><USER34> I agree with the idea that anything can be reverse engineered. However electron by default has plain text javascript code. I'd like to prevent people from editing plain text (!!!) to evade my licensing check!

<comment><USER37> For what it's worth I agree with the Electron dev's decision to close the ticket. They don't seem to have the same use case as you and are under no obligation to support it.

There's also the unstated issue of ongoing support for the feature. If they put in code obfuscation they'll be obligated to make sure that it provides adequate protections to avoid a deluge of "someone hacked my obfuscated code" type tickets. What constitutes "adequate protections" will have to be updated over time as more advanced techniques are discovered for reversing out the code.

Combined with the performance drops that were clearly outlined by the Electron devs it would seem like a code obfuscation feature could be a really big waste of time.

</comment></comment></comment></comment></comment><comment><USER38> just tried the beta its still pretty slow :(

<comment><USER39> About 10 seconds of startup opening a directory, from terminal to loaded workspace. I'm on a MacBook Pro (Retina, 13-inch, Early 2015). I have 76 community plugins installed.

<comment><USER30> 76? Daaam. I thought I was overdoing it at 53. (If anyone wants to check:

        ls ~/.atom/packages | wc -l  # minus 1 for the README

Have you checked Timecop? (cmd-shift-p, "timecop") Might be a few you can do without.

<comment><USER39> I have too many. But it works well for me. I've worked on too many languages with the same editor, so I've got... Front and back-end JS tools (linting, tern autocompletion, builds); clojure with a repl and parinfer, paredit; some rust and elm plugins that can probably go since I just experimented with those mainly. Linter for terraform. I also use atom for general note taking, so I've got a couple plugins for that.

</comment></comment></comment></comment><comment><USER40> Or you can not have a text editor in a browser. :)

Cool article regardless

<comment><USER41> Must every thread about VSCode and Atom start the same way? It's a trade off: performance for a cross platform JavaScript app development. If that is a tradeoff you don't have to make, don't do it. Atom and VSCode have made that tradeoff. I don't know what rehashing this can possibly accomplish.

<comment><USER42> > _Must every thread about VSCode and Atom start the same way_

If many people believe this is the case, why not? All articles get some common types of responses based on the topic, this is just one topic/response combo that you happen to disagree with.

> _It 's a trade off: performance for a cross platform JavaScript app > development._

It's an unnecessary tradeoff.

If a single developer can create ST from scratch for Windows, OS X and Linux, then surely GitHub or Microsoft (for VSCode) can create a cross platform native set of UI components in C or C++, wrap them, and have the rest of the development (plugins etc) happen in JS (to keep the familiar language, easy access to npm modules, etc).

<comment><USER43> If this was truly that simple, don't you think someone would have already done it? Furthermore, is there even an actively maintained, open source, cross platform, development-focused text editor with native UI components?

<comment><USER42> > _If this was truly that simple, don 't you think someone would have already > done it?_

Someone already has done it. An one-man-shop built Sublime Text by himself.

Surely it's not having JS as an extension language as opposed to Python (the only difference between ST and what I propose) that's making it difficult.

> _Furthermore, is there even an actively maintained, open source, cross > platform, development-focused text editor with native UI components?_

There's a "cross platform, development-focused text editor with native UI component" that's working great.

Whether there's an open source editor like that is orthogonal, since what I'm discussing is whether is technically feasible to create such a browser -- and the existence of ST proves that it is (and that's by a single developer: with resources such as that GitHub or even better MS, have, it would be much easier).

The choice of license is just a decision after that.

<comment><USER44> I think the developer behind Sublime Text is widely recognised as an outlier.

>> "Sublime Text 2 is mostly coded in C++ and uses a custom UI toolkit." ... [0]

How many other devs/teams are going to reasonably take that on.

(And how do you think the debugging story of his custom framework compares to Chrome Devtools).

[0] [http://stackoverflow.com/a/9201645](http://stackoverflow.com/a/9201645)

<comment><USER45> > How many other devs/teams are going to reasonably take that on?

This strikes me as a sort of devolving-human standpoint that might lead to someone in 2050 asking how anybody could possibly walk 10 miles unassisted.

In the past, small teams of talented developers have written an entire game + game engine + associated tools from scratch, countless times.

Doing in-depth custom UI development for the desktop as part of creating a text editor does not bin as 'Mountain-moving; Don't even try' difficulty.

</comment></comment></comment></comment></comment></comment></comment><comment><USER46> I thought everybody moved over to Visual Studio Code by now.</comment>


DevShore: Match-making vetted software outsourcing companies for your business - <AUTHOR> http://devshore.co/ <comment><AUTHOR> Last quarter our team was committed to building DevShore: a different tool allowing small and medium-sized businesses in the US to connect with qualified software companies (or partners as we use to call them) all over the world, and reduce all frictions in terms of efforts, risks and time invested in a successful software outsourcing relationship.

If you want to reduce almost 30% in your time/cost investments finding and working with the right software partners, start using our FREE service to matching your business with vetted software partners and companies that will align with your immediate objectives and expected outcomes. Depending on the information you share and the ideal type of engagement, we will offer the best choices from all over the world.

</comment><comment><USER2> Is there a way for new partners to join?</comment>


Join social media's 'country club' for just $9,000 - <AUTHOR> http://www.cnn.com/2014/09/16/tech/social-media/netropolitan-social-media/index.html?hpt=hp_bn5 <comment><USER2> Heh. Notch should join up and ask them what to do with all of his money.

</comment><comment><USER3> Sounds like a killer app for separating suckers from their money.</comment>


ActiveState launches 'Basecamp for developers' - <AUTHOR> http://workspace.activestate.com/

<comment><USER2> Couple of UI tips: Center-align the layout. It's way too busy, I have no idea what I should read first or even click on. Cut out 90% of that text and assume your user has never been your site before. Show me pics and tell me why I should switch from Basecamp. It's also loaded with colors; I feel like I should be wearing a hard hat on this site.

</comment><comment><USER3> Summary: another hosted trac site.

</comment><comment><USER4> I think I'll stick with Assembla. It's the same concept but not as mature. Nothing against it, but it's not really all that unique.

</comment><comment><USER5> Definitely a far cry from Basecamp's intuitive design. Although, this may evolve into something worthwhile in it's own respect, as ActiveState's Komodo Edit is my editor of choice: it's fast, free, extensible and open source. In it's current state 'ActiveState Workspace' doesn't seem like much, but I'm interested to see how it evolves.

</comment><comment><USER6> I'm not sure how this differs from Unfuddle.com, except that it's not out of beta yet. Unfuddle is pretty great by the way; I was part of a distributed team of about 20 on a large project last year, and that company used Unfuddle for that and about 40 other projects.

Nevertheless, here's to more choices and good competitive pressure for all the developer project infrastructure companies out there.

</comment><comment><USER7> How is this particularly different from a paid GitHub account? Now that they have issue tracking, it's pretty much a one-stop shop.

<comment><USER8> The issue tracking on github is very basic and just about useless in my experience for managing any private development environment. Hopefully they continue to improve it like the rest of their services so I won't have to use other systems in the future but it's really not there yet.

<comment><USER9> How would you like us to improve it so it isn't useless to you?

<comment><USER8> Just a few things I can think of off the top of my head

\- Alternative priority system. Putting them in order is cool and I like it but I need a way to say "This isn't important" vs "This needs to be done yesterday" without using labels and to have them be sortable

\- Dependent issues. Ticket 4 can't be completed until 5 and 7 have been done.

\- Custom status folders on the left hand side. Open and closed aren't really enough for a lot of work flows. New, In progress, ready for review, ready for deploy, closed are ones I like but everyone is different here so maybe make them customizable? You could use labels for this I guess but it just doesn't feel as right as I folders on the side would.

Those are the main ones for now.

</comment></comment></comment></comment><comment><USER10> I don't understand how this is a basecamp for developers. More like hosted svn and trac. Might do better if marketed that way.

<comment><AUTHOR> I was thinking that the project blogs, wikis, forums and the fact that it's hosted (plus the developer-specific stuff) make it like Basecamp.

</comment></comment><comment><USER11> not as smooth, elegant, or intuitive as basecamp. It could just be that I'm biased because I've been using basecamp for the past 2 years.</comment>


Interview with ericries from Lean Startup - <AUTHOR> http://twit.tv/tri30

<comment><USER2> awesome interview! thanks for sharing the link</comment>


CO2 and Climate Task Force (AQ-9) (1980) [pdf] - <AUTHOR> https://insideclimatenews.org/sites/default/files/documents/AQ-9%20Task%20Force%20Meeting%20%281980%29.pdf <comment><USER2> From the conclusion:

"At a 3% per annum growth rate of CO2, a 2.5℃ rise brings world economic growth to a halt in about 2025."

I wonder if attempts by the scientific community to persuade world leaders of the severity of this problem would have been more successful if this had been more emphasized, rather than inches of sea level rise, wildlife extinctions, effects on poor populations, etc. If there is one thing political and financial leaders understand, it is their own dependence on continued economic growth - and continued _expectations_ of economic growth.

<comment><USER3> I don't think global warming is on track to bring world economic growth to a halt by 2025, that's only 5.5 years away. As emphasized in the report, the models of the time had a very wide cone of uncertainty - on one end you had the immediate destruction of human civilization, on the other you had a slow meandering towards harsher conditions. Fortunately for us we got off easy relative to what could have been. (Although, it's not right to say we "got off," we are continuing to put CO2 into the atmosphere and unless we stop we will eventually push it far enough make good on every ghastly possibility they considered in the 80s.)

<comment><USER4> The trouble is CO2 isn't even a pressing problem compared to everything else. There are so man forms of pollution that are killing things right now. There are the great garbage patches in both the Pacific and Atlantic oceans. There are the lakes of sludge in factories cities in China. There are the coal fly ash dams at coal plants all around the US (and dams like the one in Kingston Fossil Plant that broke and contaminated the entire watershed between Nashville and Knoxivlle), water supply contamination from fracking, the ongoing ramifications from the BP oil spill in the Gulf that is still not really cleaned up, but everyone has forgotten about.

To solve all these other very current sources of pollution that are killing us right now, we need to consume less. We need more trains, fewer cars, cellphones that are designed to last 8~12 years instead of 2~4, industry that isn't based on infinite growth, more automation, less fear over loss to automation, and just a huge change in the way we think about the world, consumption and the economy.

All of these changes will reduce CO2, but CO2 is just a symptom of a much much larger problem. People will continue to argue about CO2, and it'd a red haring. Humanity needs to focus on the actual Flu and not the runny nose/sniffles.

<comment><USER5> This is very far from correct.

CO2 is not just disrupting the climate, it is also acidifying the seas, which will soon suffer an eco-collapse as shellfish and coral become unable to precipitate calcium out of the water.

There is a nearly commensurate problem. If existing A/C and refrigeration systems end up venting their HFCs, that will cause as much climate disruption as CO2, and remain in the atmosphere for centuries. Somehow we have to drain every failed compressor and incinerate it all.

</comment></comment></comment></comment><comment><USER6> Want to make a difference as a technologist?

Feel free to join these communities actively looking for support and with ongoing projects (that are alive):

\- [https://climateaction.tech/](https://climateaction.tech/)

\- [https://techimpactmakers.com/](https://techimpactmakers.com/)

\- [https://www.tmrow.com/](https://www.tmrow.com/)

<comment><USER7> Thanks for posting this. I have a climate change related project that is getting traction and its needs are exceeding my ability to keep up with the dev work. Hopefully these communities have someone who would like to help. If anyone on HN is interested in helping, you can find details in my profile.

</comment></comment><comment><USER8> So very succinct.

"Timescale for significant impact, very roughly 50 years"

"1°C Rise (2005): Barely noticeable"

"2.5°C Rise (2038): Major economic consequences, Strong regional dependence"

"5°C Rise (2067): Globally Catastrophic effects"

The world has released more _since_ that document was produced, than in the whole of human history before it.

<comment><USER9> > The world has released more since that document was produced, than in the > whole of human history before it.

Unfortunately there's still a lot of people that think this is a natural cycle and that it's not caused by humans. The sad truth is that for anything drastic to happen we will probably need to wait another 20-30 years for (a) the consequences to be right in your face, and (b) a majority of the old decision makers holding us back to be dead, retired, or irrelevant (no longer have the pull whisper in new decision maker's ears).

<comment><USER8> 20-30 years and we're in chaos, and have to go into reverse emissions.

In Europe there seems to be a growing public awareness and will to respond, the EU might catch up to public opinion. It's been in our face consequence wise for most of the last 10 years. Summers we expect once or twice in a lifetime coming every 2 or 3 years is kinda hard to not notice...

<comment><USER9> Notable is difference from in your face. I'm referring to regions drastically changing. I know it will be too late then, which absolutely sucks. This is why I don't think we'll get through this as a majority of the population... and this is coming from someone that's typically an optimist.

</comment></comment></comment></comment><comment><USER10> This has been public for several years, any reason in particular to post it here now?

</comment><comment><USER11> Anyone living in Europe now will tell you the problem is of dire importance today. 2025 may have actually been a conservative estimate for the halt of global economic growth.

Today we have a massive heat wave in June which threatens half a billion people in the first world who have never needed air conditioning. France has already seen high temps of 115 f.

It boggles the mind to think the American government is actively accelerating this crisis.

<comment><USER12> The sun is getting hotter, is America to blame for that too?

CO2 doesn't matter.

<comment><USER13> Would you please stop posting flamebait to HN? We ban accounts that do this repeatedly.

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


The Fallacy of Placing Confidence in Confidence Intervals - <AUTHOR> https://learnbayes.org/papers/confidenceIntervalsFallacy/index.html <comment><USER2> Statistician here, 90+% frequentist

It is not easy to be a Bayesian or a frequentist. For insights, I recommend Brad Efron's article entitled `Why isn't everyone a Bayesian?', widely available online and not at all technical or pedantic. One of the difficulties is that the Bayes prescription asks a lot of the user. You have to supply a lot of distributional information. In high dimensional problems, the mathematically convenient answers might not be benign. [The article predates an explosion in Bayesian computational methods but is still relevant.]

From the Bayesian side, I recommend reading Andrew Gelman's blog. He points out many of the failings from frequentist approaches, but also acknowledges that many of those things can happen for Bayesian approaches.

The submarine example looks to me to be very contrived. It is one where all the information you need for a Bayesian approach is simply given. Real world problems are messier. For instance, what prior distribution should a drug company assign to the effectiveness of a new drug they've spent half a billion dollars developing? Should the FDA use the same distribution?

I'm pretty sure that a partisan frequentist could come up with examples where the Bayes approach fails, maybe in a funny way to boot.

There are tricky interpretation issues with confidence intervals, and they depend on assumptions in the `all models are wrong but some are useful' way. But a much bigger problem is p-hacking and unacknowledged multiple testing which leads to more false discoveries. Much the same would happen in practice with Bayesian approaches. Those false discoveries are valuable to people who think something is better than nothing when reporting their findings. They can get what they want by Bayesian means, not just by frequentist ones.

I'm not worried that the confidence interval either has or has not got the true value inside of it. The same is true of a credible interval. The Bayes approach gets a probability statement by making the true value random, and the frequentist approach gets one by making the end points random. If you want a probability and you want an interval, it seems like you're stuck with this is- or-isn't issue. One way to look at your interval is like it is a lottery ticket. The winning number was already drawn but not announced. You can state a probability in terms of how many tickets were sold, but really you either won or you didn't. The probability is still useful in thinking about the interval.

</comment><comment><USER3> Could someone explain what this implies?

As a non-mathematical person who sometimes uses these tests in biological experiments, I find it frustrating why statisticians can't just give us something we could indeed use with confidence that it actually tells us what we think it tells us...

<comment><USER4> The beginning of the article discusses common fallacious interpretations of confidence intervals (i.e. what most of us probably naively think a confidence interval means, e.g. 10 ±2 95% means there is a 95% probability that the true value is between 8 and 12). The authors then go back to basics and explain what a confidence interval actually is (that, on average, experiments conducted the way this experiment was would have had a 95% chance of capturing the correct value inside the interval -- a subtle but important distinction). Then they create a neat example which shows how four different approaches to calculating confidence-interval-like-things work in practice. Then they go into technical details I couldn't be bothered reading. Finally, they suggest that bayesian "credible intervals" do a much better job of providing what people intuit a confidence interval to be.

As someone trained in classic statistical methods who has not had occasion to really use Bayesian methods, one of the things I like about Bayesian approaches is that they seem much more real world and practical to me. E.g. most statistical analysis tools assume a bunch of ridiculous and impossible things (e.g. that you do not look at the data until it has all been collected; that every time you look at the data you need to add a "degree of freedom" meaning that looking at the data 10 times produces 10 increasingly less reliable results -- literally NO-ONE does this and yet it is crucial for the theory to work.)

The Bayesian approach is more like "as you get data, make and refine estimates of what the data means" which is how we actually do things, and so -- everything else aside -- we aren't violating the approach's base assumptions every time we use it.

<comment><USER5> > had a 95% chance of capturing the correct value inside the interval

I'm still not clear on this, what does it mean? I also tried to read the linked text but it's quite dense and drawn out.

<comment><USER4> The experiment has already taken place and its findings are either correct or incorrect. It's not a Schrodinger's Cat, the Cat is alive or dead.

Imagine two studies have been completed and they have non-overlapping confidence intervals each of 95%. Does each have a 95% chance of having captured the result? Obviously not -- at most one may be correct.</comment></comment></comment></comment>


Ask HN: Scrum vs. Kanban vs. Agile vs. Waterfall – what is working for you? - <AUTHOR> <comment><USER2> I think a mixture. Coining the term "Ban Scrum". Which is a mixture of KANBAN and scrum sprints. Where the sprint is not over until an identified set of tasks/stories are completed. The truth about software development is, it takes as long as it takes. But you don't have infinite time. So digest what needs done, carve up/reduce into the smallest workable step/task, group like things into sprints. Work those sprints until complete. This also allows for larger teams to work more sprints concurrently by dividing the dev teams up into smaller unit teams. Then having a single KANBAN board for management to watch progress. While also allowing for continuous development and rolling releases, eliminating the artificial deadline of the traditional scrum sprint and resulting crunch of code reviews a day or so before the end of sprint cycle.

Ritual meetings are similar, but there is never a end of sprint meeting/next sprint planning session. Rather a weekly sync up to talk about what's working and what's not, what can we do better. Then weekly backlog grooming to identify and group future sprints to get them ready to be started, when it is natural to start that work. Then of course daily standup to communicate roadblocks to managers so they are aware and can do their job to unblock the road, and also to promote general awareness to of other team members of what each other are doing.

</comment><comment><USER3> Not a developer here. I work mainly as a translator, and I work alone, so YMMV. Kanban works best for me. I have a self-hosted Kanboard instance ([https://kanboard.org](https://kanboard.org)). However, sometimes even that is difficult due to the hectic pace of work when business is abundant.</comment>


Apple confirms TV series order of Asimov's Foundation - yaseen-rob https://arstechnica.com/?p=1363339 <comment><AUTHOR> This was the first full series of novels I ever read. I recall being so enthralled with them that I literally stayed up all night reading a couple of them. I still remember the brilliance of the writing building the suspense toward foundation's first encounter with empire. I hope they can capture some of the magic!

<comment><USER2> try to read Three Body, you will find another new world. [https://en.wikipedia.org/wiki/The_Three- Body_Problem_(novel)](https://en.wikipedia.org/wiki/The_Three- Body_Problem_\(novel\))

<comment><USER3> I loved tTBP but its nowhere close to Asimov's Foundation. Perhaps the 2nd & 3rd books flesh out the universe?

<comment><USER4> 2nd book lays out the foundations of cosmic sociology, and it's a dark, dark universe out there. 3rd book expands on that, reaches epic proportions.

</comment></comment></comment></comment><comment><USER5> Big Asimov fan, and really looking forward to this. I just hope they don't screw it up. Fortunately the stuff coming out of the internet based media companies has been good. I would not trust the blockbuster movie industry to do it. JJ Abrahms does Asimov would be an abomination. That I Robot movie with Will Smith as an abomination. At least Apple has the $$$ to pull it off.

Foundation series would be ideal though, as you could cycle through actors. Really would like to see a miniseries, maybe 10 hours for each book could do it, but I don't know about the 1 hour format. Would like to see 2 hour movies. I don't know how compatible it would be with the internet attention span.

What I don't trust Hollywood to do, is to keep it hard sci-fi, which is why I love Asimov.

For example, through the series he spends many pages covering hyper-spacial navigation. Sub light until you get outside the gravity wells, micro jump, then spend two weeks figuring out where you are, micro jump again, etc. This changes as technology is developed from Robots through Foundation.

They'd have to do the same with many other topics, such as mathematical psycho-history. That's what makes it Asimov. Otherwise they would turn it into a space-opera.

<comment><USER6> 10 hours for each book seems excessive, especially since most of the actual events in the Foundation novels happen "off-screen" and are only revealed through conversations by the characters.

10 hours is the equivalent of the entire Hobbit trilogy of movies, for a book that is much shorter - and we all know how that turned out.

<comment><USER7> I don't think there's anything inherently wrong with taking a sparsely plotted novel (like The Hobbit or Foundation, both of which have a lot of details happen off-stage and sometimes bafflingly so) and fleshing out the details.

The problem with the Hobbit movies is just that they did that very badly.

</comment></comment></comment><comment><USER8> I have fond memories of the first time I read the Foundation series. I chose to read it the long way, in a recommended order I found online that pulls in the robot novels and the empire novels. Only frustrating bit with that is that every single one of those books _except for one_ (I think it was Robots and Empire) is available as an ebook. :)

<comment><USER9> Neat! Do you have a link to the recommended order?

<comment><USER10> Many people (including me) think it's best to start with the Foundation core set - Foundation, Foundation and Empire, and Second Foundation. Then you can move to the Robots Series - Caves of Steel, Naked Sun, and Robots of Dawn. Then circle back to the Foundation sequels, which ties them together a bit. It's important not to read Robots and Empire until you read the Foundation series.

<comment><USER11> And I'd top them off with The End Of Eternity, which although its in its own world (or is it?), it's ending ties indirectly to the whole series...

</comment></comment></comment></comment><comment><USER12> As eager as I would be for a Foundation TV show, I think about Dune and what an abomination that was. Similarly, I loved The Hobbit, but Jackson's trilogy was all but unrecognizable. With few exceptions (GoT, for example), multi- volume novels are made well.

<comment><USER13> I'd love a good modern Dune movie series. It would go well in the current genre of dystopia movies.

<comment><USER14> Denis Villeneuve is working on a new Dune adaptation.

<comment><USER15> As a movie though, I think the material is so dense it can't be expressed in a movie setting especially with today's need for everything to be about action and special effects.

I just finished reading The Butlerian Jihad and even though it's not the same as the original works it's more suited for today's audience.

<comment><USER13> There's plenty of dark plots and action for a movie. But his philosophy and pernicious stuff could be hard to convey.

<comment><USER15> I agree the story is hardly about the action but about politics, religion, fanaticism, will power etc. The important parts are in the details and will be hard to be put in a movie. More time is needed to develop the characters than what's available in a movies length.

</comment></comment></comment></comment></comment></comment><comment><USER16> Although Amazon has had some success doing what everyone else does and extending Philip K. Dick's work with The Man in the High Castle, Asimov famously quoted that most of his action happens offstage. [1] So it remains to be seen if Apple can rework Foundation's action enough to keep viewers engaged without tweaking the material so much it's unrecognizable to True Fans (TM).

I'm not saying video can't be compelling when much is implied; Jaws is famous for suspension building as a happy accident from the shark robot's unreliability. But Foundation is a quarter million words and modern audiences do IMHO expect engaging and visual story telling.

[1] [https://archive.org/stream/AsimovTheFoundation_201705/Asimov...](https://archive.org/stream/AsimovTheFoundation_201705/Asimov_the_foundation_djvu.txt)

 _I read it with mounting uneasiness. I kept waiting for something to happen, and nothing ever did. All three volumes, all the nearly quarter of a million words, consisted of thoughts and of conversations. No action. No physical suspense._

 _What was all the fuss about, then? Why did everyone want more of that stuff? - To be sure, I couldn 't help but notice that I was turning the pages eagerly, and that I was upset when I finished the book, and that I wanted more, but I was the author, for goodness' sake. You couldn't go by me._

 _I was on the edge of deciding it was all a terrible mistake and of insisting on giving back the money, when (quite by accident, I swear) I came across some sentences by science-fiction writer and critic, James Gunn, who, in connection with the Foundation series, said,_ "Action and romance have little to do with the success of the Trilogy - virtually all the action takes place offstage, and the romance is almost invisible - but the stories provide a detective- story fascination with the permutations and reversals of ideas."

</comment><comment><USER17> Awesome, that's the first reason I have to get an Apple device!

</comment><comment><USER18> Meanwhile the full series isn't available in iBooks</comment>


SmoothMouse for OS X - <AUTHOR> http://smoothmouse.com/

<comment><USER2> This project really needs at least one shred of documentation.

<comment><USER3> i downloaded it, and nearly installed it - but then thought.. "what even is this?"</comment></comment>


HTML5: Anchor Content, Not Anchor Text - <AUTHOR> http://baymard.com/blog/anchor-content-not-text

<comment><USER2> I've seen surprisingly few news sites doing this.

Google's new search-preview-thing is somewhat along the same lines, although it doesn't actually take you to the same content as the other links.</comment>


Ask HN: Thoughts on Our Business Model? - <AUTHOR>

We want to crowd source developers to startups ~(1000:1) and use product managers to break down the tasks into very little pieces that are given to the users to solve/do. Ideally, users can build points (like github, dribble, and stackoverflow do) and earn shares of their favorite startups! Thoughts? Link: http://www.joinastartup.org <comment><USER2> It doesn't really work for me:

a) Wearing my business owner hat I don't see that your product managers will be able to split up the work in effective ways to deliver business value early without having an in-depth understanding of our business. I don't know of _anybody_ who outsources product management.

b) Wearing my developer hat a major part of my skill set is the conversation you have with product owners about the work they want done, the value they want out of it, the alternatives available, etc. The original request for X can rapidly transform into Y with a bit of Z. By cutting the developer out of the loop with the product owner I'm likely to deliver less value for time spent.

c) Anybody who has worked with large distributed teams on product development knows that communication and integration is hard. This model would seem to be adding in extra layers that will only make it harder. There isn't a team - there's a bunch of separate developers who's reward is tied to their piece of functionality rather than the product.

... so colour me unconvinced with the model as stated.

</comment><comment><USER3> Regarding your original title of: "Our Business Model Repel's Our Customers... Tips?"

How much of your business model relies on people converting from your website? If it is a substantial number: As part of your audience (a developer) I can divulge my first impression of your site. It is that I have no idea what your website does, and I won't give you my e-mail address to find out.

Some solutions: 1) Explain with both sufficient and few words what it is your website does. Use pictures if you need to. 2) Allow me to explore your website risk-free, or in other terms, without requiring any information of me. 3) Try further to persuade me to try your product through marketing ploys such as free things, empty promises, etc.

</comment><comment><USER4> Sounds like there will be some tough legal hassles.

And the earning shares thing will have to be exact using some formulas basically, which could then lead to potential for someone to game the system and get lots of shares, which would be a problem.

I think it's a neat idea but hard to get it all to work, good luck.

</comment><comment><USER5> I just left a comment on one of your other posts, but a new thought did occur to me: What's the difference between this and something like github?

</comment><comment><USER6> It's an interesting concept, but I'm not sure how it's a business model. Do you guys also take a cut of equity from your startups?

</comment><comment><USER7> Do I still get negotiation room?</comment>


The Myth of the Sustainable City - <AUTHOR> https://www.scientificamerican.com/article/the-myth-of-the-sustainable-city/ <comment><AUTHOR> "Urban areas are usually celebrated for their energy efficiency and low per capita carbon dioxide emissions, but such accounting ignores how and where they acquire their resources."

</comment><comment><USER2> From 2016.

<comment><AUTHOR> Did the data change?</comment></comment>