Developers September 15, 2020

Do I really need React?

reformer

I'm going through a phase of paralysis and probably just procrastinating by worrying over this.

I've come from a Node/Go background but really wanted to build out my new project in something extremely productive, rather than writing queries and validation over and over again. I'm decently familiar with Python, and Django is something that will do a lot for me and let me focus on features so I went with that.

What followed was me assuming I needed React, and spending a fair amount time learning about DRF and struggling to implement the correct Auth routes (Allauth) and obviously all the React/Redux boilerplate, with Typescript thrown in (I've used Typescript extensively, but it's not exactly low friction with React/Redux).

I've now wasted so much time.

Now the project is a Dev focused tool so will be behind a login screen, so no SEO concerns, but I thought React would mean it was ultra snappy but now I'm thinking I should just build this damn thing and worry about all that later.

I've even seen cases where you can have a hybrid/progressive app where some parts of the tool bring in React/Vue where required.

Thoughts?

Edit; thank you all for your overwhelming encouragement to get back on track! It's clear that using React right now was a distraction.

  1. 14

    "I'm going through a phase of paralysis and probably just procrastinating by worrying over this."

    • This happens when a craftsman chooses tools that he does not master and all his mental energy is spent on making the tools work... There is little time and energy left for creativity and high level problem solving when the biggest challenge is to use the tools properly.

    Imagine trying to play music with no muscle memory and having to work out where to put your fingers as you play... A real nightmare.

    This is why a craftsman must stick to the tools that he has mastered, when he is producing his best work and not training.

    1. 2

      I appreciate your honest reply, I think I knew this in the back of my head and it's a symptom of the procrastination I struggle with.

  2. 8

    After a couple of years of doing SPA+API (with multiple frameworks) I've now turned around on this. I think it's ridiculous we go to SPA+API as the default option. There are indeed legitimate reasons to use that pattern, but if you can't justify it IMHO you're shooting yourself in the foot.

    Going SPA+API allows you to have full control over the UX, and yes, decoupling presentation from data is good, but it's a shit ton of work which may not make sense in many cases. Not only you now have to deal with application state, complex architecture, etc, but reproducing the same native UX found in browser in an SPA requires a ton of work. For example, when you click back and land on a page with a form that form is pre-filled for you.

    My point is that a classic SSR monolith (PHP, Go, Python, Node, etc) is totally valid. It's less work and you can still have modern UI features. If you go that route, I think Vue is a better choice than React as it's easier to use as a modern jQuery replacement, so to speak.

    Another approach you could use is SSR+hydration. You can setup this on your own, or use something like Next.js. In my current project I'm using Svelte for this. You can check my example setup here if you're interested.

    https://github.com/PierBover/svelte-ssr-webpack-example

    Some people argue that users prefer the "app like" feeling. But I don't think that's relevant. Github, Wikipedia, Stackoverflow, Amazon, and a very long list of successful companies are not SPAs.

    Heck, even using jQuery might be valid. Digital Ocean's dashboard is made with jQuery and it's perfectly fine.

    Edit:

    It's the Vultr Dashboard not the DO one!

    1. 2

      DigitalOcean’s dashboard is written in Ember, and they’re migrating to React. Source: I used to work on that team!

      I agree with your point, for the most part; most apps don’t need to be a SPA. But it’s not a bad idea either. It’s all trade offs, and there are some compelling UX/DX benefits to that route!

      1. 1

        Oh you're right! I just checked it.

        It's actually the Vultr dashboard.

    2. 1

      Definitely agree with the Next.js (React) or Sapper (Svelte) approach. Then you can begin with a complete server-side website, and make the client-side richer at a later point (or not).

      1. 1

        FYI Sapper is not really SSR. The first request is rendered server side, but afterwards it becomes an SPA.

    3. 1

      Why does jQuery need to be replaced?

      1. 1

        Because having components, data binding, and some kind of reactivity will allow you to build sophisticated UIs with more ease.

    4. 1

      "Digital Ocean's dashboard is made with jQuery". Do you have other good examples of companies using jQuery?

      1. 2

        React is still a tiny niche solution in Web development: jQuery is used by 76.5% of all the websites, that is a JavaScript library market share of 97.3%.

        Source: https://w3techs.com/technologies/comparison/js-jquery,js-react

        1. 1

          I guess this would be a better metric:

          https://trends.google.com/trends/explore?cat=31&q=Vue,React,Angular,jquery

          Not as dramatic, but jQuery is still much more popular.

        2. 1

          Comparing total usage when React and jQuery have a 7 year age difference is pretty misleading, since 7 years in programming terms is a VERY long time. It would probably be more worthwhile to see how the interest between React, Vue, Angular, and jQuery from the point of the latest birth between these 4 technologies and today has changed over time.

          1. 1

            That would also be misleading because anything new and small will grow faster... Hence developing country economies grow faster. Anything new and fashionable is growing faster but may still remain relatively small because the market leader is huge. React was made for the Facebook UI and most web apps are not that busy.

            1. 2

              That's not true when the majority of new technologies don't even make it to mainstream, plus frameworks like Angular, Vue, and React (library) are easier to compare when it comes to usage cause they were released in a smaller time difference (one year between React and Vue and 3 years between React and Angular). Not to mention at the time of its release jQuery had no real competitors. However, I do agree with you that a lot of web apps are misusing React by their needs.

      2. 1

        Pieter Levels makes $600k a year with PHP and jQuery - https://www.nocsdegree.com/pieter-levels-learn-coding/

      3. 1

        (It was Vultr not DO)

        I don't have any from the top of my mind, but I use an extension to check what websites use in the front end and you'd be surprised how many still use jQuery.

        https://chrome.google.com/webstore/detail/ui-stack/ijagbooglignnjecmjnmdfapfbgblkdk

  3. 6

    React was invented to occupy developers so that they don't have enough time to build their own businesses.

    Just a conspiracy theory 😉

  4. 3

    It's a boring answer, but if you like it, you "need" it. It doesn't really do anything that plain HTML and JavaScript will do for you, except to give you a natural way to break up your code.

    I happen to like it, but wouldn't describe it as much more as a mild convenience unless you have a very complicated user interface that often has a lot of small updates.

    1. 2

      lol "if you like it, you 'need' it"... so true =)

  5. 3

    Not really, I'm using Ruby/Rails/with TurboLinks and it does the job.

    React is more for highly interactive apps (which is <10% of apps)

    1. 1

      Yea, that's the area where something like React really shines. An interactive map, say, with tons of layers and filters and popups, would benefit hugely from React/Vue/etc. — I'd even say in that case, using a FE framework is the best option.

      For most apps doing relatively simple CRUD operations, React is a fine choice for building your UI, but mostly if it's already what you're comfortable with. Definitely not necessary.

  6. 2

    This is a helpful thread. https://news.ycombinator.com/item?id=22161880

    Basically,
    1- use what you know
    2- use what you know
    3- use what you know

    Just like you don’t want a surgeon to operate on you using a shiny new robot that he never used before. You don’t want to ship stuff that you just learned.

    Personally, I am Django + bootstrap fanboy to get stuff up and running quickly. If it sticks and there is users, then I will think about getting fancy.

    1. 1

      The problem with this mantra is that people who work professionally as devs know tools that are appropriate for companies with the resources to pay multiple, sometimes dozens or even hundreds of devs.

      The idea tools for a solo dev an a 10M+ company aren't the same! I see people get into trouble with this not only on the front-end stack, but also around devops. Building for the future now decreases a new business's chances of getting to product market fit and having a future.

    2. 1

      Ah, I now feel less alone...

      Django + jQuery + Bootstrap FTW!

  7. 2

    React is still a tiny niche solution in Web development: jQuery is used by 76.5% of all the websites, that is a JavaScript library market share of 97.3%.

    Source: https://w3techs.com/technologies/comparison/js-jquery,js-react

  8. 2

    You definitely don't "need" any particular technology. Just use what gets the job done so you can start getting product/market fit.

    That being said, you probably didn't "waste so much time" either. You spent time learning (hopefully), came back with some understanding (of what the tradeoffs are) and now can make an informed decision.

  9. 2

    Now the project is a Dev focused tool so will be behind a login screen, so no SEO concerns, but I thought React would mean it was ultra snappy but now I'm thinking I should just build this damn thing and worry about all that later.

    This. Do this.

    Or, to directly answer the question. No.

  10. 2

    Yes build the damn thing and worry about all that later. Your customers don't care what you use; they all see the same information at the end. If your product can't succeed without React, then you are doing something wrong. This is a business not a tech product.

  11. 1

    I don't think you need React. I don't think you even need a backend framework. I'm using jQuery. And for the backend I use plain PHP & Python for automating certain tasks. If it gets the job done, use whatever you know.

  12. 1

    I was in the same situation just a few months ago. I am a PHP developer and wanted to learn React for a while.
    I eventually decided to start my side project while learning it.
    The time it is taking to developing it, of course, have doubled but at the end I am having double reward too (being excited to work on something new, thus keep working on the app and learning a new thing).
    if you do not have time restriction, and you got a full time job I'd advice to go for it!

  13. 1

    We've all been there. It is important to remember that bikeshedding is an addictive form of procrastination. People will have a lot of advice, but in general the best advice is to use what you're already comfortable with as long as you can, because learning new stuff is expensive. Yes, you always want to be learning, but I would argue that learning a new thing when you're supposed to be building something is just putting off the building part. Don't be that person!

    Now, coincidentally I saw a great talk earlier tonight that speaks to this, and there's countless excellent posts addressing this topic far better than I can in a comment.

    All that said, what I'm actually excited about is using the new wave of SSR, over-the-wire update frameworks like StimulusReflex to capture the best of both worlds by managing application state exclusively on the server. There's an excellent Django spin-off from SR called Sockpuppet which you should check out for sure: https://github.com/jonathan-s/django-sockpuppet

    I personally believe that React is already a legacy technology, and just hasn't realized it, yet.

  14. 1

    You do not need React! If you know Django, why not use that with some jQuery or JS to build? I use Laravel all the time for apps and it works great for my needs. React has a purpose, to build complex UI's in a more maintainable way, many apps don't need to have complex UI's with big teams of developers.

  15. 1

    I’ve worked on multiple big projects in Django, React, and Angular and spent many many hundreds of hours in each framework. I’ve launched projects in each framework that sales teams have sold in the tens of millions of dollars ranges. My recommendation is not to concern yourself with learning React if you are trying to be productive. Learning React, especially with Typescript will not be productive for you. It’s a steep learning curve especially concerning Typescript and especially with redux. There are countless issues with Redux with Typescript and adding typescript might reduce bugs in the end but will increase coding time. I was by far more productive with Django and Angular projects I would say I was able to launch Django projects faster than any of the 3. If this is for a personal project and this is on your own budget I would definitely just stick to Django and Python and learn React or Angular when you have down time. I’m throwing Angular in there as an option for the future because it’s my personal opinion that it’s a more solid framework than React, but I also feel both of those frameworks just click better with different developers. I feel like you need downtime to spend at least a few dozen hours in each of them to determine which is a better fit for your personality. In the meantime i would be productive and stick to Django. I’ve launched enterprise apps in Django that generated hundreds of millions in sales, you do not NEED React. It’s more of the shiny new toy than anything.

  16. 1

    When I tried react, my biggest gripe was the typescript pain. Types are great. I cant believe they aren't first class in react. I do like function programming, but just didnt have that great an experience with react overall.

    For my website/app Im using angular, which I also use in my day job. Im pretty happy apart from the size on my homepage. But I'm still getting good lighthouse scores.

    I agree with the general sentiment here, that you should lean towards using what you know so you can focus on your product.

  17. 1

    More importantly than your choice of tech: Tell us what it is, and maybe we'll buy it! You either win or you learn.

  18. 1

    Unless you need to build very interactive interfaces I would strongly recommend avoiding a SPA approach. It just makes things more complicated and in many cases it can affect performance negatively if you are not careful on how you do it, vs what you would expect.
    For most kinds of apps these days I would use something like Stimulus.js. It is A LOT simpler, and works great with any kind of server rendered content, making it easy to add dynamic behaviour on the client. If I really have to do an SPA I would go with Vue instead of React.

  19. 1

    You don't need React.

    Use what you already know to build the damn thing.

  20. 1

    React/Vue/Angular become noticeably more helpful when you need a lot of client side interactivity without page refreshes (i.e. ajax requests on button clicks to load additional items on the page, making one part of your page interact with some global state that updates a different part of your page, etc). Server rendered pages are fine depending on your use case with just some vanilla event listeners to handle simple interactions.

    I work in both Angular (at work) and React (for side projects). They're both great options if you want to learn something that will be useful in the job market - although React is outpacing Angular now. For mobile/pwa setups, you have the option of Ionic/React Native, so if mobile is something you would ever want to get into, it would be easier to do so with React than it would be with Django.

    A lot of developers make the mistake of bringing redux in way too early in their project. Unless you need redux, don't bring it in. The context api will probably be all you need. If you meet a limitation with it, then you can bring redux in. That's one less thing to have to worry about right now - and that alone can cut out a lot of boilerplate.

    You said it wasn't, but if SEO ever was a concern, you have options to go with SSG through Gatsby/Next.js, as well as SSR through Next.js. I've used both and both are good frameworks, but I prefer Next.js.

    All of that being said, I've also used Django and it's a really great framework. The admin panel that comes out of the box is great for doing simple CRUD operations when you're getting started, and the built in ORM makes queries super simple.

    Hope this helps

    • Brandon
  21. 1

    Short answer is no.

    It really depends, if u r building async solution, polling/websocket, u need it.

    Otherwise, u do not have to.

  22. 1

    If you want to have rapid development with React, you definitely need Clojurescript and its awesome wrappers. Hot code reloading is total magic and completely changes the way you program: https://www.youtube.com/watch?v=KZjFVdU8VLI. Of course there is an extra investment to Clojurescript but I personally consider it worthy.

    1. 1

      Is there something different about Clojurescript's hot reloading that you couldn't get from Create React App's or Gatsby's hot reloading?

      1. 1

        Not sure how these work, I just have experience with Dart + Angular where on change the aplication was automatically reloaded but the state got restarted which is super annyoing.

        If hot code reloading should work correctly, it has to preserve the state of the application. Therefore it requires certain discipline when programming: you have to have a separate state which you do not mutate randomly all over the place. I think it is quite common in JS+React to have components which mutate the state on mounting (for instance, loading their data from the server) which makes hot code reloading difficult. This could be resolved with some discipline but I don't think people do it, so it is an uphill fight.

        On the other hand, Clojurescript promotes separating state and doing most of stuff via pure functions (actually turning React into a nice functional framework, as it should be), so it is very natural there.

        I would recommend using Clojure(Script) anyway since it is much better language than anything else out there and increases the productivy everywhere. I can't imagine coding without Clojure REPL but its full value is impossible to explain to someone who did not spend multiple months writing Clojure. Some time ago I gave this talk on why we are super happy with Clojure in our startup: https://www.youtube.com/watch?v=4UoIfeb31UU.

        1. 1

          Cool, thanks for sharing. Always good to learn about new things.

          I currently use React with Gatsby's hot reloading which also preserves state. I'm using Redux for state management which also uses immutability and pure functions so I think there are a lot of similarities there.

          1. 1

            I heard that Redux is doing similar things to Clojurescript's Re-frame library and these approaches are great since they lead to less coupling and simpler more understandable code. But it is better to use these approaches on top of a simple language like Clojure where you have amazing fast immutable data structures while you can still leverage any code from JS or JVM. In the end, I am probably 10x more efficient using Clojure(Script) and I could never write something like OrgPad in one person in anything else. Clojure is so simple that I can fully understand it which I can't say about any other language, maybe except C. (And Clojure is not new, it is 12 years old, changing very slowly, which is a good thing.)

            Btw. the creator of Clojure is absolutely amazing, surely one of the best people and most innovative in IT. I really recommend his amazing talks and his Simple made easy is a must watch for every programmer, it is general and applies even outside of computers.

            1. 1

              Sounds cool, I'll definitely check it out more.

  23. 1

    Generically speaking...while you may not "need" any specific tool right now it is possible that you can benefit from it in many ways.

    • You might legitimately need it in the future.
    • You'll learn to see code from a different viewpoint.
    • Even if it doesn't speed up your workflow now, it may later on a different project. You'll know to use it out of the gate.

    It's more a question risk/reward, pro vs cons when it comes to the resources you have available and the constraints you're currently working with.

  24. 1

    You did not describe any feature that would actually need React. Do you need SPA? Why?

    For the app to feel snappy? Server rendered apps can feel super snappy with Turbolinks.

    I've even seen cases where you can have a hybrid/progressive app where some parts of the tool bring in React/Vue where required.

    Exactly.

    React is definitely more heavy than many alternatives. Maybe you just have one part of the app that needs some interaction, but there is no need to build everything with it.

    Try to refocus on building server rendered MVP first. Iron out details later.

  25. 1

    Honestly, whatever technologies you're most productive with are the best choice. I personally like React a lot, and it does let you build complicated, performant UI quite quickly. It's not the only way to do things though.

    One thing I would point out is that you're trying to jump into too many new technologies at the same time. You do not need Redux or Typescript to use React. Redux especially adds an enormous amount of boilerplate to your code. I would never recommend learning React and Redux at the same time.

    If you're still interested in getting going with React, use it vanilla for a while. Eventually you might need a state management library like Redux, but it should be fairly clear when you get to that point. Even then, you might find that your needs are simple enough that the context API is sufficient.

    1. 1

      If you do use Redux, I strongly recommend using Redux Toolkit (https://redux-toolkit.js.org). It's a thin abstraction layer on top of Redux that is now the recommended approach for Redux users, and it basically eliminates all the boilerplate. I love it and haven't looked back at vanilla Redux.

  26. 1

    Of course it depends, usually I don't use any JS framework. For a while, I'm investing time on Flask and SqlAlchemy, and trying to provide ordinary features (search, filters, pagination, login, validation) without JS at all, before adding the frontend magic. I guess, if you need to experiment some features in the frontend, maybe Vue can excel your requirements, before going to a more complex approach (like React). What your thoughts on Go? I'm considering it for next projects!

  27. 1

    https://blitzjs.com/ https://redwoodjs.com/ seem to be best of both worlds, i'm waiting for v1.0 as im risk adverse when it comes to tech.

    I still use React classes and Redux :)

Recommended Posts