Artsy's engineering team writes about mobile and web development, including Swift, React Native, GraphQL, AWS, and team practices.
HN links it for its multi-year React Native retrospectives and its guide to writing outage post-mortems; a commenter criticizes a post-mortem as thin.
At Artsy, my team of long-time native developers, started using React Native on valentine’s day 2016 in our pre-existing iOS app. Overall it has been a net-positive for us. In short, the developer experience and ability to be productive is much better, we now are able to leverage the product engineering skills from devs that would previously only work on web projects, and our initial tests in porting our React Native iOS code to Android are looking promising.
I think there’s no binary answer to whether or not React Native is a viable option. I can definitely imagine a bunch of situations where that would not be the case, but in our case the app is largely just a collection of views that show remote JSON data. Some small animations are done using the React Native animations API, but e.g. our navigation completely relies on native APIs and also has custom native transitions.
In short, I think that the companies that will succeed with RN are those that have native experience and a can-do-self attitude, both to ensure proper platform UX and deal with lower-level details such as RN bugs and limitations that would prohibit the product design from being possible to implement at all (for instance, in our case nested scrollviews); or those that are willing to sacrifice on UX and product design. (Not making any judgements here btw.)
We’ve written a bunch about our experiences https://artsy.github.io/series/react-native-at-artsy/ and I recently spoke about our specific case of…
Hey there, author here, we've been exploring React Native in the open at Artsy for about 1.5 years now. This post is a continuation on our series on React Native. It's really changed the fundamentals for our iOS team at Artsy to the point that we don't really recognise ourselves as a specific team anymore.
I think a lot of teams would definitely benefit from using the technology, but understanding the trade-offs up-front is hard. So this post is not a quick overview but something that will take 45m to read and understand. It's worth a read IMO. :)
For the rest of the series see, http://artsy.github.io/series/react-native-at-artsy/
:disclaimer I work at Artsy:
cool to see this on the front page!
If this interests you be sure to check out the artsy org on github:
https://github.com/artsy
Artsy is open source by default so there are a fair amount of interesting repos and projects, including our website and mobile apps (react and react native).
I am biased of course but I think the engineering culture at Artsy is pretty unique and special.
The blog and podcast may also be of interest:
https://artsy.github.io/open-source/
https://podcasts.apple.com/us/podcast/artsy-engineering-radio/id1545870104
I totally agree with your first statement.
But I think it is complete BS to say that Scala isn't good for "making software". The two most successful projects of my career were relied heavily on Scala to deliver robust product on aggressive timescales, with teams largely composed of first-time Scala users.
You can read one of the stories here: http://artsy.github.io/blog/2016/08/09/the-tech-behind-live-auction-integration/
I'm not going to tell you that it's an easy language to master. But I do believe it is a fantastic language for making software.
Artsy, https://artsy.net and http://artsy.github.io, NYC.
Experienced engineers only ATM, full stack or dev-ops focused. Exciting projects ahead. Prefer people with serious art passion or some art background.
Email me db[at]artsy[dot]net or find us at Miami Basel this week.
Yeah - not really a post mortem, is it? "We had a bug and we fixed the bug."
They could probably cut and paste that same page for 90% of future outages. Maybe they need to read this: https://artsy.github.io/blog/2014/11/19/how-to-write-great-outage-post-mortems/