@mjackson
Thriller.
Nothing here yet.
Nothing here yet.
No blogs yet.
I spend a lot of my time working on our stuff, so my reply is totally biased :) But one of the projects I'm currently most excited about is our Reach UI project. It's a baseline for building accessible components with React on the web that I think is going to really move the React community forward in terms of building accessible apps.
My partner Ryan actually wrote a blog post about this here: https://reacttraining.com/blog/reach-react-router-future/ The tl;dr is that React Router will be the surviving project but reach/router 1.0 will still be maintained with bugfixes. So if you're starting a new project, I'd probably just start with React Router 5.1 that we released earlier this week.
One cool new little tool I just discovered this morning is https://carbon.now.sh. It's handy for posting good-looking snippets of code online w/out having to take a screenshot of your editor. So many times when communicating with other devs, code speaks louder than words 😅 I can't think of very many tools that I use that aren't already fairly popular. My editor is vim. I also use a lot of the standard JS tooling like Prettier and ESLint. Perhaps one tool that I think is underutilized is Rollup, for bundling JavaScript. It's currently mostly used by JS library authors, and not so much for apps. Most people building apps prefer webpack. But I've been using Rollup recently and it works really, really well. And the output is very readable, which I enjoy.
Thanks for the questions :) I graduated from BYU with a degree in Information Systems, which was more of an accounting degree with a little bit of databases, networks, and programming thrown in. I really liked the programming side, so as soon as I graduated I got a job writing code at a company in Utah called Omniture. They were a big web analytics company, later acquired by Adobe. I later moved to the SF bay area where I spent 6 years working in various startups like Path, Twitter, and Luxe. I also applied to Y Combinator and was part of the 2013 summer batch of companies, but our company ran out of money before we shipped. It was a huge learning experience for me, and very humbling. When I started React Training, I was encouraged by the fact that we had money on day one. It wasn't like some of the other startups where I had worked that were still trying to figure out how to make money. So that was a huge confidence booster. It's hard enough to build the technical side of a startup without having to worry about the business model as well. If the business model is already in place, you can focus on the tech.
I do! When I'm not traveling to a conference or workshop somewhere, I work from home in a spare bedroom in my house. When working from home, I try to start by doing something that will get my creativity going like writing in a journal or reading something inspirational. Then it's GitHub, code, email, etc. The usual stuff. One other thing that is really important for me when working from home is to GET OUT of the house. It's easy to spend a whole day just cooped up inside in my pajamas. So I try to do things like take my children to school in the morning or get out for lunch or some exercise.
I think the light bulbs start to turn on when someone finally understands they don't have to manage the DOM anymore. I always say "that's not your job anymore!" and just wait until that piece sinks in. And then they realize that all those little things they were so used to doing like toggling class names, setting properties, adding/removing events, setting styles, etc. ALL of that stuff is just a side effect of the state of the app. When people start thinking in terms of state instead of in side effects, that's when they really become productive with React.
That's a great question, Aravind. Thanks for asking :) I think it depends on what I'm making. When it comes to code, I always try to start with the end API in mind. It's a little counter-intuitive, I think, because I tend to think "well, none of this will even work until I build the backend, so I should do that first". But whenever I go that route, I realize that you never really know what the backend even needs to be until you know the needs of the front-end. So I try to start at the finished product (the final API) and work my way backwards. I hope that makes sense :) I think this mentality applies in other areas as well. One other thing I like making is music. Sometimes I start with a really cool chord progression on my guitar. But the best songs I've made start with a good melody. You can always figure out the chords later if you have a strong melody.