Anyone interested in learning React.js to build their project?

I saw this post and wanted to share my experiences and opinions since I dove off the deep end with React in 2017. I didn't intend to write so much, but hopefully it is helpful in some way.

TL;DR — I love React and plan to keep using it for the foreseeable future, but developing production quality web apps is so much harder than I had ever dreamed it would be.

---

I decided to do exactly that when I started Paddock Tech. For the first decade of my career I had predominantly been a backend software engineer, but had always had a very strong desire to do frontend work. When I started development on app.paddock.tech I had

• Very little knowledge of Javascript, its nuances
• No knowledge of React besides the sheer amount of support from Facebook and the love from the web and app development communities.
• No knowledge of how to make a PWA or what it was
• Very basic knowledge of CSS and SASS
• A strong eye for good UI/UX/design, but now idea how to pull it off myself as I'm not a designer.
• A history of building strong, web APIs and Flask-based websites

From my journey so far, I've found that it is extremely easy to write simple apps, but once you want production-quality, data driven apps it becomes very difficult to do well. I've also written my entire app in Typescript where everything is typed. Some things that I have struggled with and continue to have issues with:

• React's built-in state management is terrible for complex state (much better, but still painful with the new Hooks) and you almost certainly have to use a third-party state management library like Mobx or Redux. FWIW I use Mobx and observables which have a great DX and feel like what React state management should have been.
• I love using typed languages and Typescript has been amazing for catching bugs and preventing all sorts of human errors, but you'll inedibly need to use a bunch or libraries to build your app (e.g. react-select).

These libraries often don't have typings (you have to write them yourself), have outdated/incorrect community typings, or have typings which assume and force you to use Typescript in a particular way (e.g. non-exported types needed to type your code correctly). This has slowed me down immensely and continues to do so. If you are writing an MVP or proof of concept (basically anything other than a full production quality PWA), stick to JS and migrate to Typescript when your MVP gains enough traction to become a real product. Despite how much Typescript has helped me dive deep into web development I regret building my MVP with it.

• Building and testing your app.

You can't avoid bundlers like Webpack, Grunt, or Gulp. Babel is also inescapable due to how much backwards compatibility and cross-platform you need to support the majority of devices. All of these utilities are massively under documented and hard to understand/use. Couple that with the rapidly-changing, non-uniform standards there are across the JS ecosystem that you need to take into account and it basically becomes a requirement to use packaging framework like create-react-app.

• Code splitting.

The JS ecosystem creates massive bundles for complex apps. 250 kB (and that is on the small side) might seem tiny, but when loaded on a 2 or 3G network load times can seriously hurt your business due to the impatience and short attention spans of humans. Splitting that bundle up and serving only the code you need for a particular view in your app is non-trivial. Bundlers like Webpack support code splitting and there are libraries out there which make loading bundles in the React app easy (react-loadable and soon native Suspense built-ins), but handling all of the edge cases that can arise when those micro-bundles fail to load is a PITA. I would love to see how a very large PWA/web app handles this.

• Data loading.

We're in the middle of an API renaissance with REST giving way to GraphQL. I'm using it to access every bit of data my app needs, even SEO metadata. The community loves Apollo, but it is the only major OSS player. New and possibly better alternatives are constantly being open sourced and the best practices for using GraphQL are constantly changing because it is so new. I tried using Apollo, but found its lack of enforced standards actually slowed my app down because it expects you to make lots of queries to your API. I decided on Relay because it enforces "data colocation" onto your "smart" components. In the end this results in a single API query to grab all data a view needs and is much faster. The catch 22 is that Relay's documentation is very basic and incomplete.

• Javascript lock-in

The React community seems to be 100% behind Server Side Rendering. This is great for faster page load times and SEO, but comes at the cost of having to run the initial render on your own infrastructure ($$$) and requires you to run a Node.js server. Just like Python, Javascript isn't designed for more than one thread which makes it ill-suited as a web server. This problem has caused a lot of issues for me in the past so I want to avoid it like the plague (using Go, for example). Business wise it makes more sense to just load balance a bunch of instances of your SSR web servers based on your traffic volume and call it a day.

Things I'm uncertain of and have not yet had the time to work on:

• Authentication and authorization. I don't have user accounts yet, but will be getting there soon.
• Service/web workers and how to do them well. From what I've read so far not doing these properly could result in some potentially catastrophic consequences.
• Data persistence. LocalStorage probably shouldn't be relied on. Data security is a fundamental principle for me .

I don’t know React, but It is in my todo list to learn. Here are the items I was planning to research:

• Advantages/disadvantages vs. plain JS, jQuery or Vue.js
• Are there any Licencing issues that would come back to byte you ? See the HN discussion about this: https://news.ycombinator.com/item?id=8985541
• How to do a transactional flow using React. For example, an onboarding flow or a shopping cart flow.
• Charting support. Doing native vs. integrating something like d3

I would. Writing my first React apps. I love it. This is my second real dive into front end after vuejs :-)

Interested in:

• best practices
• building a responsive, attractive landing page
• GraphQL
• (TypeScript)

React >= 16.8.6

I am also building my product using React & react-native, apollo, graphql, styled-components. On the web part, I am using Next.js to support server-side rendering.

I’m building my side project with React and I have to say, I love it. This is my first real dive into front end and it’s been a really fun learning experience.

I think one thing I’d be interested in is what I need to expand on as a React developer to find a fit in more professional roles.

I’m sure there’s a big difference between what I hacked together for my side project (no flux, redux, etc - I’m just throwing out frameworks I’ve heard of here!) and what I might need to really understand.

I would. Haven't used React beyond the hello world.

Interested in:

• User authentication (either to a local resource or a 3rd party service)
• Send / receive files/data (images, binaries, etc)
• Local storage management
• PWA's
• User interaction (for instance how Notion.so works to add / remove data from a page)

I assume the integrations you mention are just using an API and the responsive / attractive part are more HTML / CSS related than react (not that I think you shouldn't include them).

Heh, I actually just paid for a React course today.