10 ms·

What Is React: A Visual Introduction for Beginners

105 points by focuser 6y ago

rockostrich 6y ago
Just skimmed through it, but this looks like a great intro for non-technical folk. I'll be saving it for when people ask me for resources into getting into frontend dev.
- tiborsaas 6y ago
  I'd suggest to send them a more boring but traditional approach first to DOM/CSS/JS. That way they will understand way better what problems React solve.
majky538 6y ago
It's Facebook library, not FE framework, enough for me. Never spent so much time configuring Angular app as React one.
- madeofpalk 6y ago
  What configuring do you need to do to use React? Install Node, run `npx create-react-app my-site` and you're all configured.
  - deleted 6y ago
    [deleted]
  - dimitrios1 6y ago
    CRA is one way to get a very opinionated starter kit, but like all boilerplates and toolkits, they are very tailored to one particular use case, and you never learn what is possible with the library outside of the toolkit. Breaking from the happy path of the toolkit yields an even more frustrating experience than if you had set it all up by yourself. (Ejecting anything above a medium-complexity SPA from CRA is painful) For example, on the reactjs.docs, https://reactjs.org/docs/create-a-new-react-app.html https://reactjs.org/docs/create-a-new-react-app.html, create-react-app is simply one of four toolkits recommended, along with countless others in open source land.
    - amenod 6y ago
      In practice though, unless you have some very specific needs (and the people I have met who thought that they did, well,... didn't :) ), you should still "just use CRA". There are folks who like to live on the bleeding edge, and for those using something else (or ejecting) might even make sense... maybe. But for any production app you should just use CRA, otherwise you will find yourself explaining to your new hire all the obscure choices you made a year or two ago. Believe me, I've been on the receiving end of these explanations and it sucks.
      - codingdave 6y ago
        I've been on the other end of that story, where entire dev organizations freak out because of a concern with webpack, babel, or some other piece of the stack... and nobody knows how to fix it. CRA has its place, certainly. But it is a black box, and somebody in your org should know the tools well enough to make good decisions to build up a product from scratch without CRA... and then you may still choose to use CRA, but it is an educated choice, not a default answer because you do not know any other options.
        sli 6y ago
        I agree with it being important to know how to do this stuff from scratch (with Google, let's be realistic), but the black box problem is solved by ejecting.
        kingdomcome50 6y ago
        Have you ever ejected a CRA? If you think your problems are about to be solved after doing the above... I have a bridge to sell you.
      - fabioborellini 6y ago
        My excuse for longing for something non-CRA is updating an existing frontend to React piece by piece. To integrate it with the existing Django app’s asset pipeline, I kind of had to eject and now my Webpack configuration and its dependencies are completely out of control. I am considering starting over with another tool chain, copying the existing components to the new structure. Replacing the whole thing with a new SPA would not have been feasible.
  - kingdomcome50 6y ago
    Have you ever ejected a CRA? Your problems are just beginning once you've opened that can of worms. I used CRA exactly up until the point when I ejected it the first time. Never again. The sheer amount of code behind CRA is... remarkable. Now I have a package/webpack/tsconfig files that I just re-use (and update as needed) between projects. I've never encountered a problem I couldn't solve. Sure now I need to manage the configuration of each project, but, I kid you not, my webpack.config.js file is 100 LoC total. This includes everything most projects probably need: Dev server setup and proxying, JS minification, JS bundling/code splitting, and SCSS/CSS transformation and purging. I'm sure other projects have other needs, but it's really not that hard to understand these technologies. And don't give me this "But all of that code is there to help you!" lecture. I've been deploying reasonably complex React apps since its inception, and have yet to encounter the kinds of edge cases to which the above sentiment is likely referring. Hey, maybe I'm just lucky...
    - madeofpalk 6y ago
      The comment I was replying to was "React has too much configuration", which I disagree with because CRA and other low-effort build tooling exists. I like CRA, it's my default go-to because i want to avoid maintaining a webpack configuration. If you have a solution that works for you, that's good too!
      - kingdomcome50 6y ago
        Sorry, the impetus of my comment above was that CRA is introducing FAR MORE configuration/dependency/complexity than maintaining a webpack.config.js file! The build process of a modern React application has a certain amount of necessary complexity. Hiding it behind a "low-effort" build tool like CRA doesn't change the above and, frankly, is really a disservice to anyone who wants to understand the tools they are working with. Go ahead, eject a CRA sometime. See how "low-effort" it really is...
        madeofpalk 6y ago
        I've splunked through CRA webpack config and submitted patches to the project. I've ejected and then years later un-ejected because I didnt want to maintain a webpack configuration.
recursivedoubts 6y ago
The traditional approach stopped working. It becomes chaotic and inefficient to always directly talk to Domo. No. The traditional approach was web 1.0, which was abandoned due to UX issues, not complexity. Later on, the chaos of direct DOM manipulation by multiple javascript entry points became too much and was formalized into the SPA frameworks we see today. An alternative solution is to go back to the true traditional approach & address the interactivity issues within that architecture (REST/HATEOAS).
- chrischattin 6y ago
  Yes! You 100% dont need a front end framework like React to achieve dynamic UI effects. I’d argue they’ve degraded the user experience over time, complicated development process, and slowed down the web experience for most people. The fact remains client side JS frameworks did not grow organically from the open source community. They had to be pushed into the dev mindspace by the mega-caps tech cos to offload processing power to the client. For the vast majority of companies (all but a handful), front end frameworks hold an org back. I’ve had this unpopular opinion for several years, and have yet to meet/work with a startup who didn’t regret choosing Angular/React/etc.
  - slifin 6y ago
    SPAs designed to mirror state on the server have a distributed data problem, there are lots of problems there in terms of fetching, updating, ensuring the users are traversing from action, loading, success/failure etc Then there's the problem that the page could have changed since the user started filling out that form, what happens when those form values now conflict etc etc The difference between serving a dead fish of a HTML page, and a SPA application is vast because you're essentially creating 2 independent systems, server and client instead of just server and then adding one of the hardest thing in computing which is consensus between disparate systems I'm quite excited about React Server Components because it means for the majority of your web app you can return to the simplicity of shipping HTML it doesn't solve everything but at the moment client side applications have a lot of boilerplate to do with just keeping the server in sync that would have been historically "for free" in a server context
boringg 6y ago
So I can't discern if React is a loved or hated technology (also it doesn't have to be binary). At the company I was working at the front end devs brought in React and were super excited about it, but reading a couple comments in here it seems like people have some reservations. I haven't invested the time into as I don't have a use case but I keep hearing about and now get the sense it isn't necessarily worth looking at until i have a needed case.
- dinkleberg 6y ago
  Many love it, many hate it, and many are indifferent to it.
- fabioborellini 6y ago
  My personal professional view is that I found web frontend development quite disgusting between the days of static HTML and React. The frontend apps built by my colleagues using jQuery or Angular seemed to have no structure and seemed quite fragile. Of course, one could use any tool well, but in my world it was not happening. From my point of view, React and JavaScript improvements in later versions have made frontend development more tolerable and even interesting.
- duxup 6y ago
  I think HN's comments of front end type topics tends towards 'back end focused folks talking about front end'. I love HN, but I would really be wary of taking too much front end type commentary seriously as it comes from HN comments. Now sometimes the comments are GREAT, that's not to say it is all bad, but other times the comments on front end topics on HN is like walking into a meeting with a bunch of managers and non front end focused folks who got together to list their gripes ;) In those cases I often don't say anything because the ranting is on and nobody really cares. Edit: This was longer but I decided I didn't want to go that far down the meta rabbit hole.
  - ng12 6y ago
    It always reminds me of the Simpsons quote: "Am I out of touch? No, it's the children who are wrong.". I've seen many people here more willing to believe that all front-end devs are clueless than admit they might not understand modern web-dev.
hliyan 6y ago
When I'm pressed to oversimplify, I usually respond with "A React component is basically a function that takes a set of parameters and spits out HTML, and can react to changes in those parameters and update said HTML. The rest is implementation detail."
kingdomcome50 6y ago
I'm rather convinced at this point that all of these people chanting "Can we just go back to traditional approaches!" have never built a web app of reasonable complexity, never used something like React, or have some sort of combination of FOMO and/or comfort in their long-held approach. I don't have experience with all of these technologies but have been using React since its inception, and let me tell you, there is no amount of (reasonable) money that would make me want to go back to the times when jQuery the big new thing. It was awful! Procedurally manipulating the DOM! I mean, c'mon guys. Talk about a mess... Where are all of the FP evangelists when you need them? And I know someone out there is bound to downvote me and respond with something like, "B b b but that one site where it downloaded 300kB of JS for a landing page! It's such a bad user experience!". Sure. That's precisely what I'm talking about /s. The reality is that libraries like React are so popular because they make front-end web development not suck. You can actually reason about the behavior of your UI without first committing to memory a whole of bunch of procedural, ad-hoc `let el = document.getElementById('i-hate-myself')` nonsense. I get it. It makes web pages a bit slower, and sometimes (maybe more often than that) get abused. That isn't fun for anyone. But level the critique at the idiots downloading a MB of JS to power a single dropdown, not the tool managing that dropdown's state.
- duxup 6y ago
  I mentioned in another comment that I think HN's comments on front end type topics tends towards 'back end focused folks talking about front end'. That doesn't make them wrong when they say "hey this super simple site doesn't need to be in react" but at the same time it also misses the use case(s) for react and other frameworks when they rant on the topic more generally.
- bern4444 6y ago
  I totally agree. Using react is a breadth of fresh air for building web applications. If all you need is a static site landing page that changes once a year, sure use something else, plain ol html, css, and JS will do wonders. But when you want to build an entire application and experienece for consumers, React is exceptional. Web applications always have state and side effects, there's no escaping it. If you squint and tilt your head, ReactJS is like a pure function given the environment. React lets you model your view around your state and takes statefulness as a given and doesn't try to obfuscate it away. As you say, its far easier to leverage FP ideas in a react application. Most react components can be pure. State can be modeled with all the fun FP tools and ideas. At the end of the day, React clearly delineates the stateful from the stateless and lets you easily model both relative to each other in a ergonomic manner.
systemvoltage 6y ago
Have you tried developing a doctors appointment website with React (or any SPA frameworks) say Django or Flask? It's a pain in the ass. Usually, you throwaway all the cool things about Django and turn it into a stupid JSON API and then you build a bunch of cruddy shit with npm tooling and cry yourself to javascript dependency hell. Then you need another server to serve up this bundle.js and a barebones index.html file. Great if you're building a Google Docs competitor. 99.999% of the people aren't. I think VueJS is excellent and surprising to see React's popularity. Vue can be used just like jQuery without any nodejs tooling. Just like every discussion about this topic, React fanboys will respond with "But, technically, you can do that with React too" [1], yeah... It sucks at doing that. Without JSX, you can't interweave for example Jinja2 templates + React. Nor can you interweave JSX + Jinja2. With VueJS? It's just HTML with a few v- attributes. Even if React worked well with direct script tags in HTML, it still sucks at it because it's mainly designed for SPAs in mind. There is a lot of existing discussion on this topic [1]. I absolutely abhor the tooling/npm/babel/nodejs/webpack all this nonsense that Javascript frameworks need. They should be sort of like jQuery - no prebuilding steps - just drop and play. A doctors appointment website doesn't need to be an SPA. VueJS is the only framework that allows you to progressively enhance something like a Flask based website in the most natural jQuery-like way. Oh btw, Svelte is yet another one - of course its SPA framework (Good luck trying to make it work on an MPA website). I am completely underwhelmed by Svelte, and ofcourse the JS peeps are flocking to it. :| [1] https://news.ycombinator.com/item?id=24520116 https://news.ycombinator.com/item?id=24520116
- algo_trader 6y ago
  Hmm.. is jsx a standard tool these days for new React projects? Sorry if this doesnt make sense. I am mostly backend/servers.
  - systemvoltage 6y ago
    JSX is a way to express HTML but its a deception. It's all javascript that looks like HTML.
    - 6y ago
vladsanchez 6y ago
Thanks for sharing your illustrations but this site/page is an effing CPU/GPU HOG!!!! https://imgur.com/9Pi1rBa https://imgur.com/9Pi1rBa

105 points by focuser 6y ago

Just skimmed through it, but this looks like a great intro for non-technical folk. I'll be saving it for when people ask me for resources into getting into frontend dev.

tiborsaas 6y ago
I'd suggest to send them a more boring but traditional approach first to DOM/CSS/JS. That way they will understand way better what problems React solve.

majky538 6y ago

It's Facebook library, not FE framework, enough for me. Never spent so much time configuring Angular app as React one.

madeofpalk 6y ago
What configuring do you need to do to use React? Install Node, run `npx create-react-app my-site` and you're all configured.
- deleted 6y ago
  [deleted]
- dimitrios1 6y ago
  CRA is one way to get a very opinionated starter kit, but like all boilerplates and toolkits, they are very tailored to one particular use case, and you never learn what is possible with the library outside of the toolkit. Breaking from the happy path of the toolkit yields an even more frustrating experience than if you had set it all up by yourself. (Ejecting anything above a medium-complexity SPA from CRA is painful) For example, on the reactjs.docs, https://reactjs.org/docs/create-a-new-react-app.html https://reactjs.org/docs/create-a-new-react-app.html, create-react-app is simply one of four toolkits recommended, along with countless others in open source land.
  - amenod 6y ago
    In practice though, unless you have some very specific needs (and the people I have met who thought that they did, well,... didn't :) ), you should still "just use CRA". There are folks who like to live on the bleeding edge, and for those using something else (or ejecting) might even make sense... maybe. But for any production app you should just use CRA, otherwise you will find yourself explaining to your new hire all the obscure choices you made a year or two ago. Believe me, I've been on the receiving end of these explanations and it sucks.
    - codingdave 6y ago
      I've been on the other end of that story, where entire dev organizations freak out because of a concern with webpack, babel, or some other piece of the stack... and nobody knows how to fix it. CRA has its place, certainly. But it is a black box, and somebody in your org should know the tools well enough to make good decisions to build up a product from scratch without CRA... and then you may still choose to use CRA, but it is an educated choice, not a default answer because you do not know any other options.
      - sli 6y ago
        I agree with it being important to know how to do this stuff from scratch (with Google, let's be realistic), but the black box problem is solved by ejecting.
        kingdomcome50 6y ago
        Have you ever ejected a CRA? If you think your problems are about to be solved after doing the above... I have a bridge to sell you.
    - fabioborellini 6y ago
      My excuse for longing for something non-CRA is updating an existing frontend to React piece by piece. To integrate it with the existing Django app’s asset pipeline, I kind of had to eject and now my Webpack configuration and its dependencies are completely out of control. I am considering starting over with another tool chain, copying the existing components to the new structure. Replacing the whole thing with a new SPA would not have been feasible.
- kingdomcome50 6y ago
  Have you ever ejected a CRA? Your problems are just beginning once you've opened that can of worms. I used CRA exactly up until the point when I ejected it the first time. Never again. The sheer amount of code behind CRA is... remarkable. Now I have a package/webpack/tsconfig files that I just re-use (and update as needed) between projects. I've never encountered a problem I couldn't solve. Sure now I need to manage the configuration of each project, but, I kid you not, my webpack.config.js file is 100 LoC total. This includes everything most projects probably need: Dev server setup and proxying, JS minification, JS bundling/code splitting, and SCSS/CSS transformation and purging. I'm sure other projects have other needs, but it's really not that hard to understand these technologies. And don't give me this "But all of that code is there to help you!" lecture. I've been deploying reasonably complex React apps since its inception, and have yet to encounter the kinds of edge cases to which the above sentiment is likely referring. Hey, maybe I'm just lucky...
  - madeofpalk 6y ago
    The comment I was replying to was "React has too much configuration", which I disagree with because CRA and other low-effort build tooling exists. I like CRA, it's my default go-to because i want to avoid maintaining a webpack configuration. If you have a solution that works for you, that's good too!
    - kingdomcome50 6y ago
      Sorry, the impetus of my comment above was that CRA is introducing FAR MORE configuration/dependency/complexity than maintaining a webpack.config.js file! The build process of a modern React application has a certain amount of necessary complexity. Hiding it behind a "low-effort" build tool like CRA doesn't change the above and, frankly, is really a disservice to anyone who wants to understand the tools they are working with. Go ahead, eject a CRA sometime. See how "low-effort" it really is...
      - madeofpalk 6y ago
        I've splunked through CRA webpack config and submitted patches to the project. I've ejected and then years later un-ejected because I didnt want to maintain a webpack configuration.

recursivedoubts 6y ago

The traditional approach stopped working. It becomes chaotic and inefficient to always directly talk to Domo. No. The traditional approach was web 1.0, which was abandoned due to UX issues, not complexity. Later on, the chaos of direct DOM manipulation by multiple javascript entry points became too much and was formalized into the SPA frameworks we see today. An alternative solution is to go back to the true traditional approach & address the interactivity issues within that architecture (REST/HATEOAS).

chrischattin 6y ago
Yes! You 100% dont need a front end framework like React to achieve dynamic UI effects. I’d argue they’ve degraded the user experience over time, complicated development process, and slowed down the web experience for most people. The fact remains client side JS frameworks did not grow organically from the open source community. They had to be pushed into the dev mindspace by the mega-caps tech cos to offload processing power to the client. For the vast majority of companies (all but a handful), front end frameworks hold an org back. I’ve had this unpopular opinion for several years, and have yet to meet/work with a startup who didn’t regret choosing Angular/React/etc.
- slifin 6y ago
  SPAs designed to mirror state on the server have a distributed data problem, there are lots of problems there in terms of fetching, updating, ensuring the users are traversing from action, loading, success/failure etc Then there's the problem that the page could have changed since the user started filling out that form, what happens when those form values now conflict etc etc The difference between serving a dead fish of a HTML page, and a SPA application is vast because you're essentially creating 2 independent systems, server and client instead of just server and then adding one of the hardest thing in computing which is consensus between disparate systems I'm quite excited about React Server Components because it means for the majority of your web app you can return to the simplicity of shipping HTML it doesn't solve everything but at the moment client side applications have a lot of boilerplate to do with just keeping the server in sync that would have been historically "for free" in a server context

boringg 6y ago

So I can't discern if React is a loved or hated technology (also it doesn't have to be binary). At the company I was working at the front end devs brought in React and were super excited about it, but reading a couple comments in here it seems like people have some reservations. I haven't invested the time into as I don't have a use case but I keep hearing about and now get the sense it isn't necessarily worth looking at until i have a needed case.

dinkleberg 6y ago
Many love it, many hate it, and many are indifferent to it.
fabioborellini 6y ago
My personal professional view is that I found web frontend development quite disgusting between the days of static HTML and React. The frontend apps built by my colleagues using jQuery or Angular seemed to have no structure and seemed quite fragile. Of course, one could use any tool well, but in my world it was not happening. From my point of view, React and JavaScript improvements in later versions have made frontend development more tolerable and even interesting.
duxup 6y ago
I think HN's comments of front end type topics tends towards 'back end focused folks talking about front end'. I love HN, but I would really be wary of taking too much front end type commentary seriously as it comes from HN comments. Now sometimes the comments are GREAT, that's not to say it is all bad, but other times the comments on front end topics on HN is like walking into a meeting with a bunch of managers and non front end focused folks who got together to list their gripes ;) In those cases I often don't say anything because the ranting is on and nobody really cares. Edit: This was longer but I decided I didn't want to go that far down the meta rabbit hole.
- ng12 6y ago
  It always reminds me of the Simpsons quote: "Am I out of touch? No, it's the children who are wrong.". I've seen many people here more willing to believe that all front-end devs are clueless than admit they might not understand modern web-dev.

hliyan 6y ago

When I'm pressed to oversimplify, I usually respond with "A React component is basically a function that takes a set of parameters and spits out HTML, and can react to changes in those parameters and update said HTML. The rest is implementation detail."

kingdomcome50 6y ago

I'm rather convinced at this point that all of these people chanting "Can we just go back to traditional approaches!" have never built a web app of reasonable complexity, never used something like React, or have some sort of combination of FOMO and/or comfort in their long-held approach. I don't have experience with all of these technologies but have been using React since its inception, and let me tell you, there is no amount of (reasonable) money that would make me want to go back to the times when jQuery the big new thing. It was awful! Procedurally manipulating the DOM! I mean, c'mon guys. Talk about a mess... Where are all of the FP evangelists when you need them? And I know someone out there is bound to downvote me and respond with something like, "B b b but that one site where it downloaded 300kB of JS for a landing page! It's such a bad user experience!". Sure. That's precisely what I'm talking about /s. The reality is that libraries like React are so popular because they make front-end web development not suck. You can actually reason about the behavior of your UI without first committing to memory a whole of bunch of procedural, ad-hoc `let el = document.getElementById('i-hate-myself')` nonsense. I get it. It makes web pages a bit slower, and sometimes (maybe more often than that) get abused. That isn't fun for anyone. But level the critique at the idiots downloading a MB of JS to power a single dropdown, not the tool managing that dropdown's state.

duxup 6y ago
I mentioned in another comment that I think HN's comments on front end type topics tends towards 'back end focused folks talking about front end'. That doesn't make them wrong when they say "hey this super simple site doesn't need to be in react" but at the same time it also misses the use case(s) for react and other frameworks when they rant on the topic more generally.
bern4444 6y ago
I totally agree. Using react is a breadth of fresh air for building web applications. If all you need is a static site landing page that changes once a year, sure use something else, plain ol html, css, and JS will do wonders. But when you want to build an entire application and experienece for consumers, React is exceptional. Web applications always have state and side effects, there's no escaping it. If you squint and tilt your head, ReactJS is like a pure function given the environment. React lets you model your view around your state and takes statefulness as a given and doesn't try to obfuscate it away. As you say, its far easier to leverage FP ideas in a react application. Most react components can be pure. State can be modeled with all the fun FP tools and ideas. At the end of the day, React clearly delineates the stateful from the stateless and lets you easily model both relative to each other in a ergonomic manner.

systemvoltage 6y ago

Have you tried developing a doctors appointment website with React (or any SPA frameworks) say Django or Flask? It's a pain in the ass. Usually, you throwaway all the cool things about Django and turn it into a stupid JSON API and then you build a bunch of cruddy shit with npm tooling and cry yourself to javascript dependency hell. Then you need another server to serve up this bundle.js and a barebones index.html file. Great if you're building a Google Docs competitor. 99.999% of the people aren't. I think VueJS is excellent and surprising to see React's popularity. Vue can be used just like jQuery without any nodejs tooling. Just like every discussion about this topic, React fanboys will respond with "But, technically, you can do that with React too" [1], yeah... It sucks at doing that. Without JSX, you can't interweave for example Jinja2 templates + React. Nor can you interweave JSX + Jinja2. With VueJS? It's just HTML with a few v- attributes. Even if React worked well with direct script tags in HTML, it still sucks at it because it's mainly designed for SPAs in mind. There is a lot of existing discussion on this topic [1]. I absolutely abhor the tooling/npm/babel/nodejs/webpack all this nonsense that Javascript frameworks need. They should be sort of like jQuery - no prebuilding steps - just drop and play. A doctors appointment website doesn't need to be an SPA. VueJS is the only framework that allows you to progressively enhance something like a Flask based website in the most natural jQuery-like way. Oh btw, Svelte is yet another one - of course its SPA framework (Good luck trying to make it work on an MPA website). I am completely underwhelmed by Svelte, and ofcourse the JS peeps are flocking to it. :| [1] https://news.ycombinator.com/item?id=24520116 https://news.ycombinator.com/item?id=24520116

algo_trader 6y ago
Hmm.. is jsx a standard tool these days for new React projects? Sorry if this doesnt make sense. I am mostly backend/servers.
- systemvoltage 6y ago
  JSX is a way to express HTML but its a deception. It's all javascript that looks like HTML.
  - 6y ago

vladsanchez 6y ago

Thanks for sharing your illustrations but this site/page is an effing CPU/GPU HOG!!!! https://imgur.com/9Pi1rBa https://imgur.com/9Pi1rBa