jessepollak's comments

We don't have any part-time opportunities, but we'll be hiring interns next summer!

Coinbase | Senior Software Engineer, Site Reliability Engineer, Security Engineer | San Francisco, London | REMOTE, VISA | coinbase.com

We are hiring engineers to help us create an open financial system for the world. Specifically, I'm hiring both frontend and backend engineers to build Coinbase.com and the APIs that power the Coinbase mobile apps. Come work on digital currencies like Bitcoin and Ethereum every day!

About us:

* We use React, Mobx, Flow, webpack, and styled-components on the frontend.

* Our APIs are currently powered by Rails with a MongoDB backend, but we're investing heavily in decomposing the monolith into services written in statically typed languages.

* We're exploring GraphQL for future APIs and are hiring two people to lead our APIs team.

If you're interested, email me at [email protected].

Shoot me an email at [email protected] — if you'd like to pitch it internally, I can work with you to find a price that works!

Ha — I'd never ask you to buy into that idea!

I think this article could easily have been titled "Choosing Ember over building our web framework"

I think this is a fair criticism and I agree that I might have used this comparison in a simplified way to make my point, but I think the primary thesis still holds: when building a React app, you necessarily need to make a very large number of choices that you don't need to make when building Ember.

This isn't because React is bad, it's because React is just the view layer! If we look at it this way, we can re-examine that list as:

* language

* view

* data modeling

* routing

* network connections

* functional utilities

* build

* styling

* testing

And, with React, when you have just a view layer, if you want to build an advanced application, you likely need to add on a bunch of other layers to get everything working. I hear you about being able to "just use React", but I also think that's a an oversimplification the other way: how many applications on the web today are built with only the view layer and none of the others?

After evaluating all the decisions we made in the past when building a React app, we decide to trust someone else to make them for us :)

p.s. the original title was "Choosing Ember of the React ecosystem in 2016" but I ended up shortening it :)

Absolutely! I would say that with Ember + ember-data, the framework conforms to a pattern where data is represented as models on the frontend, which can be updated and persisted to the server. These updates happen through a CRUD / REST API (in our case we conform to JSONAPI) and are generally triggered in a controller (or a route that contains logic and acts similar to a controller in a traditional MVC framework).

In the React ecosystem, I think there's been a pretty stark departure from that general pattern with things like redux and GraphQL, so while we love it, compared to what we'd been using , it felt a little behind.

Does that make sense?

Hey everyone - OP here! This was a really fun blog post to write and I think I learned a bunch in the process: if you have any questions, would be happy to answer!

I'm the author of this post — would love to answer any questions about our decision if people have them!

Yeah, at our current size + team composition we don't feel like we have the knowledge/experience to do remote work well. With that informing our decision making, we've decided to prioritize other things (that have different tradeoffs).

I think as we keep growing this will definitely change. Would love to learn from someone like you who's obviously been super successful at doing remote well :)

Wasn't intentional, but I like your thinking :P

Thanks Andreas! I know this isn't necessarily a "product," but thoughts on putting it on PH?

Thanks for the feedback! We just realized this document is actually out of date with our legal contracts.

I've opened up a PR with the change here (https://github.com/clef/handbook/pull/56), though it may be 10 years rather than 7, so I'm waiting for confirmation from our CEO before merging :)

EDIT: Our CEO's response was: "this is more complicated than just changing that number, give me some time to write the fully change up." Incoming!

EDIT #2: Updated with the 7 year number and a more depth explanation :) - thanks @brennenHN!

Hi everyone! I'm one of the members of the team, if you have any questions I'd be happy to answer here :)

Clef actually doesn't require internet on the secondary device. We just shipped offline mode a few weeks ago: it's not as seamless as the primary flow, but it works well and solves the problem. Turn on airplane mode, sync the wave and let me know what you think.

Fixed :)

Which version of Safari are you in? I've tested it in all of the latest versions, but it could easily be broken in an older one.

Haven't gotten to that point yet — I originally just set about implementing all the cards in CSS then decided to actually make it into something people could drop in really easily.

This looks great. Doing your taxes sucks.

One completely unrelated question (and I hate to be that person on HN): is the accelerated scroll on the website intentional? It's a really good looking site, but the scroll speed makes it very hard to read.

I actually haven't, I should look into that.

That doesn't really happen — I deliver before most everyone else is awake and I rarely have strict deadlines where adding an extra hour (most of which I would already have to do to get to work) would matter.

The couple times that I have had to back out, I either got my roommate (and co-founder) to take my spot or my employers have been understanding.