They could if there was a (nation state) enforced price for carbon and hence a market to operate in.

I your case, was the fortune a product of starting your own company or working at a smaller one?

I’m working on a similar product at https://mygraph.ca and always looked up to James and Actual. Great product and well engineered.

It was amazing to see how productive he has been the past few years working on it while also being at Stripe. Not surprised to hear it got to be a bit much.

This is one of the main reasons I’m building https://mygraph.ca.

Unfortunately the only current and sane way to allow users to aggregate their financial data seems to be by having users pull .csv files from all of their accounts (at least where I am, in Canada).

I built https://mygraph.ca as I was tired of Mint failing to sync with Canadian banks (and later dropped Mint anyway because of the security/privacy concerns).

It’s not targeting technical users but it would be cool to add a SQL integration like Stripe Sigma, etc at some point.

Hey this is pretty cool, I posted an app too and see some opportunities for collaboration here (especially since I'm starting to explore data visualization capabilities). Can you email me? My contact info is in my profile.

"[..] while still allowing for a decent income even in the event of failure." How does this work? You're just taking enough of a salary as an early stage C[X]O/founder that your downside is limited?

Essentially. At least enough not to accrue debt. In the event of complete failure of the startup, you'd still likely come out worse financially than if you'd taken a more traditional job (especially in tech). So there is, of course, still substantial opportunity cost — but the upside of success can be huge.

This sounds very much like Angular 1.

"Some of Vue’s syntax will look very similar to AngularJS (e.g. v-if vs ng-if). This is because there were a lot of things that AngularJS got right and these were an inspiration for Vue very early in its development"

https://vuejs.org/v2/guide/comparison.html

So is it fair to say that Vue is for people that wish Angular had stayed on the V1 path and not diverged to be more like React for V2 onward?

No, I think it would be fairer to say that it's like if AngularJS and React had a child and named it "Vue.js".

Because in the end, Vue.js has stuff in common with React, like the virtual DOM (you don't see this in Angular 2+) and has stuff in common with AngularJS (the good parts).

Check this out: https://vuejs.org/v2/guide/comparison.html

Don't go thinking you are going to read a biased comparison, the Vue.js vs React section has the blessing from a core React contributor (Dan Abramov): https://github.com/vuejs/vuejs.org/issues/364#issuecomment-2...

Unrelated question, but are you working as an iOS developer and making that salary in the Midwest? Or do you have a different role like Architect or PM?

Strictly as a developer. I tend to gravitate toward team leader. I had a role for about 2 years in health care as a architect. Management wasn't for me.

Are you using arrow functions? I find that using es2015 arrow functions for class methods takes care of most of the problems around this and react.

The only annoyance is dealing with binding event handlers to items/components in a list. Generally you need to abstract the list item into it's own component and do the event handler binding there.

I don't use .bind() anywhere in my react code.

Yep, we are using arrow functions and other ES2015+ goodies, but they don't help with event handlers. In fact, I believe class property syntax helps with that, but we only figured it out after we built these few pages and components necessary for the web app part.

>Yep, we are using arrow functions and other ES2015+ goodies, but they don't help with event handlers.

They do. Just do:

  myHandler = (v) => {
    ...
  }

and you don't need to bind in the constructor anymore. You'll need to use Babel of course to transpile that.

Yes, class properties syntax. I mentioned that in the article.

Hmm, so why do you say "but they don't help with event handlers"? Because it's not yet standard?

Sorry, I didn't think about the arrow functions being used in class property syntax too. :) So yes, they do help with event handlers, I stand corrected.

One note: From what I've read, using arrow functions as props in a render method of a component will create new functions each render, so you might end up with a good bit more GC than normal. There are some nice little mix-ins that will autobind to remove the need to remember to .bind everything.

Nowadays you can just stick a class property anywhere in your React component:

   handleSomething = (params) => {
     ...
   };

and the use it in your render function like this without any binding:

  <Foo onSomething={this.handleSomething}/>

Yes, class properties are the way to go.

Good suggestion - Thank you

Not using arrow functions in JSX code to define error handler. Yes, I believe you are right, that would create multiple handlers.

Apply anyway.