What Is React: A Visual Introduction for Beginners

https://learnreact.design/posts/what-is-react

by focuser • 5 years ago

105 79 5 years 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• 5 years 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• 5 years ago

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

madeofpalk5• 5 years 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.

dimitrios1• 5 years 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, create-react-app is simply one of four toolkits recommended, along with countless others in open source land.

kingdomcome508• 5 years 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...

recursivedoubts6• 5 years 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).

chrischattin2• 5 years 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• 5 years 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

franklampard2• 5 years ago

Curious why they regretted and how else would they have built the web app

hombre_fatal2• 5 years ago

That clients exist to do work so that a company's hardware doesn't have to is cynical, a "client bad [if it's built with JS]" cargo cult, and it suggests that you can't think of any upside to doing things on the user's powerful device instead of a phone-home network request to a server.

lucasmullens• 5 years ago

You've never met anyone who didn't regret React? According to the Stack Overflow Developer Survey, 68.9% love React. I feel like you haven't talked to enough people.

The idea that client side JS was pushed to offload processing power is a bit ridiculous. Do you have any evidence for that claim? Many React sites these days do SSR anyway (running the client-side code on the server) so it doesn't seem like they would save money doing that.

tshaddox• 5 years ago

That sounds nice, but isn’t it really just saying “the problem is too hard so the solution is to not even try?”

recursivedoubts6• 5 years ago

No:

https://htmx.org

franklampard2• 5 years ago

Can you show me an example of such a solution?

recursivedoubts6• 5 years ago

Yes:

https://htmx.org

paulie_a• 5 years ago

Web 1.0 involved massive amounted of tables. It was definitely abandoned due to complexity

recursivedoubts6• 5 years ago

That was layout, not logic. It doesn't have much to do with the adoption of React and other front end libraries.

systemvoltage7• 5 years ago

Also Tables are abandoned altogether even when we need them like displaying tabular data.

boringg• 5 years 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• 5 years ago

Many love it, many hate it, and many are indifferent to it.

fabioborellini2• 5 years 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.

duxup3• 5 years 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• 5 years 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.

hombre_fatal2• 5 years ago

You can tell how lopsided the discussion is here by how many people here think it's some sort of badge of honor that they're a "back-end guy" who barely even touches the client instead of feeling sheepish how far removed they are from the user experience and thus the concerns of how hard it is to build a good client and the tools that improve it.

A good example of this is how many "back-end guys" here think it's Javascript and web tech that are hard/annoying instead of all client tech due to the nature of building user-facing software that has to run on a 1,000,000 devices instead of sysops-facing software that runs on one server.

Be wary of anyone who just peddles downsides without acknowledging trade-offs. They don't have much experience (You can have 20+ years of dev experience while inexplicably avoiding this sort of realization). Right now there's someone in the top thread saying they literally don't know a single company that didn't regret using Angular/React. Oh bother. This sort of person just has to ask, but they don't because they prefer to cling on to their little sneering world view.

If someone seriously can't say why anyone could prefer React (or any other tech, like JS or PHP or jQuery) without a cynical disparaging trait like these people are just idiots, simply write this person off and seek more even-keeled opinions about the world.

peruvian• 5 years ago

People are more likely to chime in if they hate it.

I think most people are happy or content with React - but honestly, it doesn't matter. Nearly every job listing I've seen or applied to asked for React experience (if the position asked for frontend skills). It's so ubiquitous in the coastal US tech industry that if you want to be a frontend dev, you're limiting your career choices by refusing to learn it.

esperent• 5 years ago

People are more likely to chime in if they hate it.

Or if they love it.

The silent majority will just see it as a tool fit for certain jobs and not for others and wonder what all the fuss is about.

ssully• 5 years ago

I did web dev from 2012-2015, until I moved into doing security engineering. I started doing some React tutorials on the side in December and now have a small project at work that uses it. I do not consider myself a web dev, so I will take any actual web dev's opinions over mine, but React seems nice!

At first it seemed a bit complicated, but looking back at the stack I left behind in 2015 (LAMP, numerous JS libraries, Bootstrap, some Ruby was starting to creep in), it actually is a little more consolidated.

I guess I should bookmark my comment and check back in a year from now in case I am still using React and see how my thoughts change by then!

blackoil• 5 years ago

If your project requires high interactivity, with lots of moving pieces, you'll love it. Particularly unidirectional data flow is a breeze to work with. If you need a static/basic CRUD site with few popups, you may prefer plain HTML/JS.

rk06• 5 years ago

~~People don't complain about things they have not used.~~ People complain about things they have used so, if you have heard complains, it means a lot of people are using it, and using it despite those complains.

So, you should consider that there is some benefit which outweighs the complains

UPDATE: original line came out wrong. and was flat out incorrect

madeofpalk5• 5 years ago

People definitely complain about things they have not used.

lovegoblin• 5 years ago

People don't complain about things they have not used

Whew can I get on the version of the internet you're on? Sounds nice.

ASalazarMX• 5 years ago

My impression is that developers love it because it makes things easier to develop, but users not so much because it makes interacting with web pages even slower than it already is.

Also, it makes webpages a pain to scrape, consumes more RAM and CPU, and recursive module dependencies can become a huge attack surface.

hliyan• 5 years 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."

kingdomcome508• 5 years 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.

duxup3• 5 years 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• 5 years 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.

bestinterest3• 5 years ago

The mental model of UI = f(state) is really beautiful. And I got it explained to me that its best to use an SPA when you have 'interrelated, dynamically updated state' from Tom MacWright and I very much agree.

The issue I had with React is that it forced a lot of mental models and API's on you to achieve UI = f(state) but after finding Svelte and spending 20 mins on the tutorial [0] I feel like I can say I 'get it' when it comes to building web apps.

Though the things you throw away when you decide to go all in on the SPA approach for your site is crazy, I hate not having access to my freaking database while building a page and having to create a ton of unnecessary code just to express a page that pulls in bits of data from my database. I do not want to complex myself with GraphQL. I much prefer the approach of dhh were we should only be paying that interactivity cost on the pages we need high fidelity on (which is probably going to be one or two pages you have for 80% of apps).

I think Hotwire looks promising where you mostly have logical split up sections of html that you want to be independently rendered across the page or on a click. When it comes to communicating and weaving state between those I'd be thinking about Svelte if it starts getting too complex.

Some examples of Hotwire I've seen so far https://twitter.com/tonysmdev/status/1355996616361205760 https://twitter.com/tonysmdev/status/1356460628819533824

[0] https://svelte.dev/tutorial/basics

andrei_says_3• 5 years ago

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 think it’s a bit different - they are so popular mostly because of the massive crowds of front end devs cargo culting static websites into SPAs.

And then maybe because of the many cases where they’re applied to replace jquery or a few js sprinkles with unnecessarily complicated SPAs. This is where stimulusjs + turbo or similar could solve the problem with 10% of the effort and complexity.

Then, maybe in third place or further, because there are more cases for SPAs than 10 or so years ago.

kingdomcome508• 5 years ago

I agree that the cargo cult is real and abuse of the "SPA" paradigm has never been higher! But that is orthogonal to the tool.

React does make front-end web dev not suck. It may not always be the right tool for end-users, but as a developer? C'mon. It's never been so ergonomic (and plain simple) to build a complex UI.

I googled stimulusjs[0] and you know what? From a development perspective it looks like it sucks compared to React. I'd rather just write vanilla JS than that hot garbage. Is the bundle smaller? Didn't bother to look, probably. Is it faster? Didn't bother to look, hopefully.

I get it! "Our job is to deliver value to the customer blah blah...". Engineering has costs as well. From training to velocity to, yeah I'll say it, developer happiness, you can't just ignore these costs. Working in a shitty, homegrown codebase using these niche libraries is a recipe for turnover.

On the other hand, if you are just whipping a some simple pages here and there that probably don't need to be looked at ever again... go for it! Your future self will cringe a little bit when you open up the source to change something simple years down the line (I know I have!), but at least those interactions are fleeting.

[0] I apologize for my crassness if you are somehow involved in the project.

bwindels• 5 years 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've got plenty of React & front-end experience and vastly prefer a thin library on top of the DOM than something like React, also for large applications. React is ok if all goes well, but when you have to debug or profile something, all the complexity behind the scenes occludes what you are looking for. Most of the time, people want JSX so you need a transpiler. Also keeping up with changes in new React releases seems like a lot of lost time.

I've been building [1] without a transpiler and just a 600 lines template library (see [2]), and it has been such a breath of fresh air. The fact that there is so little code between you and the browser makes it very easy to see what is going on. Call stacks of max around 15 frames.

It sounds like you are comparing React to jquery code without components, and I justed wanted to highlight that DOM APIs have evolved since those days, and that you don't need a library like React to structure your code.

React has popularized good ideas in front-end development, like components, but I think the complexity cost of a virtual DOM is often underestimated.

1: https://github.com/vector-im/hydrogen-web/ 2: https://github.com/vector-im/hydrogen-web/blob/master/src/pl...

kingdomcome508• 5 years ago

I see this sentiment often, that React is too complex, and I just don't understand that criticism. Is there some bloat? I'm sure. But the problems that React solves aren't trivial either.

The signature of a React application (and each component thereof) is simply `f(state) => HTML`. That isn't hard to understand, and the complexity behind the scenes is the complexity necessary to distill and optimize an application to the above. And to your point about JSX, yes, I do want that. I find it silly to write HTML using some other DSL. I have yet to find one that is anywhere near as transparent or ergonomic. How could there be?

I suppose I can agree profiling for the cause of undesired cycles could be easier, but, frankly, I rarely need to do so because I can simply reason about why a function/component is being invoked. The "flow" of a React application is well-defined (and rather simple). To your last point about structuring your code, you are probably right. Things have come quite far since jQuery in many respects, and I am sure that, if I were to try my had at it again, I would find it to be much more sane than 5-6 years ago. I just don't see why anyone would subject themselves to that though...

Kudos on your project! It looks great, and I'm sure provides the faculties important to you and your platform. I would be careful though. Given enough time and energy you may find, in the end, you have simply reinvented React!

systemvoltage7• 5 years 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

algo_trader2• 5 years ago

Hmm.. is jsx a standard tool these days for new React projects?

Sorry if this doesnt make sense. I am mostly backend/servers.

systemvoltage7• 5 years ago

JSX is a way to express HTML but its a deception. It's all javascript that looks like HTML.

mixedCase3• 5 years ago

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

Or you could just shift your backend expectations and adapt to the different needs. If you're doing an SPA because you want an app-like experience and very decisively not a website-like experience, your backend should be as simple and stupid as possible and not force you into a model like MVC; you shift much of the complexity to the frontend when you go from website to SPA. You know, like it would if you're writing a desktop app or a mobile app that uses an API. Because it's an application, not a website.

You could pull the 99.999% number out of wherever, but the truth is that many things we used to do as websites are better off as apps. My bank's website is better off as an app, the social networks I use work better as apps. Hacker news doesn't. Blogs don't. Online newspapers don't. It all depends on the amount of interactiveness needed and how much better the experience is with access to real-time information streaming and quick UI responses based on things other than data loads.

And as dreadful as Javascript dependency hell is, it's objectively better than Python dependency hell since it's had a passable package manager for much longer than Python (and even then, most Python devs still don't use or even know of Poetry) so the ecosystem is better aligned to modern software development expectations. You're just used to one variation of hell, and don't want to learn a new one.

Try to understand modern frontend needs before assuming newer frameworks are shit at everything and that everything related to it sucks. They might be shit at the specific thing you're doing, and some lessons seem to have been forgotten when things were redesigned.

What hasn't changed however, is how most software development sucks, and the fashionable things that were done under terrible standards (devs and/or management) have changed, but are still done by the same terrible standards so you still have shit results.

VueJS is the only framework that allows you to progressively enhance something like a Flask based website in the most natural jQuery-like way.

No. You're just allergic to build tools because you have not enough knowledge of them. Probably because, from what I've been led to believe from your comment, most of your experience seems to be with Python. All your described problems ultimately stem from there.

systemvoltage7• 5 years ago

I’m allergic to build tools because I want zero JS in the backend.

Thanks for the counter, I have made previous attempts at App-like websites but have left me high and dry. There is something to be said about clarity and separation in MVC frameworks. I love MVC. I love boring tech.

Python dephell is no more after poetry. Have you used it?

bestinterest3• 5 years ago

Do social media sites really need to be SPA's? Does Twitter or Reddit really have to be a SPA?

Do Reddit really need the UI = f(state) paradigm? Is there much of any complex cross component state sharing that an SPA would be valuable there?

Here is an example of Hotwire with Twitter https://twitter.com/tonysmdev/status/1355996616361205760

deergomoo• 5 years ago

Vue can be used just like jQuery without any nodejs tooling

You can, but you probably shouldn’t (outside of prototyping). It requires you to both ship the template compiler to the client, and to perform the template compilation on the client, on every single page load (vs serving a cached, pre-compiled JS file).

If you want to sprinkle JS onto an otherwise server rendered page, you’re better off with something like Alpine.js [1]

[1] https://github.com/alpinejs/alpine

systemvoltage7• 5 years ago

You made my day. Thank you!

vladsanchez• 5 years ago

Thanks for sharing your illustrations but this site/page is an effing CPU/GPU HOG!!!!

https://imgur.com/9Pi1rBa

What Is React: A Visual Introduction for Beginners

Related Stories