5
6 Comments

Rapid development in react

I work for React agency which means our development process is more focused around whatever specifics needs customer has (custom made ui, tools which integrates well with specific infrastructure, security, good code documentation etc). This means development is not optimal if you want to quickly create personal projects or MVPs, I am curious what is your workflow for quick prototyping in react? Few things I can think of and please if you have some specific recommendation for each of these points, write them!

  • use premade boilerplates like CRA
  • use UI libraries, css frameworks without much of customization
  • use server-less platforms like netlify
  • use Gatsby or similar for static websites
  • use tools like Webflow for easier stuff(this actually seems to speed up development process a lot for me)
  • have a premade set of HTML templates to reuse
  • use or maybe don't use typescript
  • use newer, more experimental version of Javascript to speed up development (which might not be possible if you are working with 10 other people who don't keep up with latest changes)
  • or use more boring technologies, which are well tested, have great ecosystem which you can use
on December 17, 2019
  1. 2

    I built https://divjoy.com to make React development and prototyping much faster. It’s basically a boilerplate generator that includes a visual editor for quickly creating UIs. Would love to hear your thoughts.

  2. 2

    Always use TypeScript! Even for small stuff.

    There’s one little-talked about other thing I noticed whilst building the MVP for https://www.influencegrid.com/ (whole front end took 2 weeks), and that’s not being afraid to copy and paste. I used be so wedded to DRY principle / extracting common components but sometimes it’s overkill/ really slow and you’re better off copying and pasting. You can tidy up if/ once your MVP gets traction.

  3. 1

    I definitely use CRA by default and have been getting into Next.js more lately to improve performance.

    I like TypeScript (and have also used Flow a lot) but I agree with others here that it’s probably not worth it on small projects.

    Also, Redux is great for larger applications, but I’ve been surprised just how far useState and useContext will go!

    I recently built https://authentiform.cubicle6.com to save my fellow React developers the hassle of responsive, accessible sign up, sign in, account recovery forms.

    It’s based on 100% stock Bootstrap (reactstrap) so it works with every theme immediately.

  4. 1

    My own opinion, since building my react app Spandraw.

    • Use CRA and eject so you can customize webpack and Typescript
    • Definitely use Typescript, it's a hell of a lot better now than 1 or 2 years ago
    • Netlify is great but I ran into some bugs, I recently switched over to AWS Amplify and it's even better.
    • I use wordpress because it's proven to have good SEO, especially with the Yoast plugin. I even use a drag and drop UI Elementor, just because it's easy.
    • I would use "boring, proven, and simple" tech, I use a Go backend with postgres just because it's easy. Go is the easiest backend language to be productive straight away and deploy in my opinion (coming from someone with no serious backend experience). I still use classes in React over hooks just because there's more examples using class components.
  5. 1

    I wouldn't use TypeScript for projects under 10k lines of code and with one or just a few team members. It can be fun to type things, get better autocompletion and see the red squiggles go away, but it does slow you down. It also results in more lines of code.

    When you're prototyping you are writing code you'll change heavily/throw away. TypeScript tends to cement your code. Yes, it can make refactoring easier, but it can also make changes more cumbersome because you'll have to change types and function signatures.

    Also avoid verbose state management libraries like Redux. Just make anything as easy, fast and dirty as you can -- it will be easier to throw it away then.

  6. 1

    Right tool for the right job vs use the one thing your awesome with.

    Don't use cutting edge out of instinct, unless you can really call why this is 10x faster, usually there are issues to be found.