What's so great about React.js?

regular_reddits · 1 日前

1.React proponents would tell you that forcing yourself to separate HTML and JS (presentation and logic) is more of a separation of technologies rather than concerns. If you think in a React way, the concerns of the application will be small composeable components. Each of these components does a specific thing, and from this is where the real separation of concerns comes.

In the classical model its pretty difficult to not tie your logic strongly to your templates by using selectors, which makes so that if you change one of them you have to change both.

2.If you are worried about JSX, you can write React apps in pure javascript. JSX is just sugar. However, youll probably find JSX a little simpler to work with.

Also, Most applications now days have some sort of build step already. Maybe browserify, maybe minification... something. If thats the case you can just tack the JSX build on.

I didn't give react any attention when it was first released because of these concerns. Its approach is very different, and not what I was used to. This article was what got me to give it a chance at first.

danneu · 1 日前

> HTML directly mixed in your JS mixes the
> presentation layer with your logic, breaking 
> separation of concerns.

But UI presentation and UI interaction are closely intertwined. Ever work on a project with index.html and then one big app.js of jQuery select/trigger soup? That's not separation of concerns. That's just indirection. Proof: Change index.html in a random way. You'll have to check app.js to see if it broke anything.

spergery · 1 日前

There's no HTML in your JS. There's JSX, which includes HTML-like syntax as syntactic sugar and compiles to vanilla JS (and it's helpful, but not required). Also, it's not really "in your logic", it's in your presentation layer. What React does differently is that your presentation layer comprises both how a component is structured, and how it reacts to changes. The separation of concerns is between components and business logic, not markup describing how components are structured and javascript describing how they behave.

it's only popular because Facebook made it.

It was extremely unpopular when it was first announced, and a whole lot of people thought facebook was incompetent/insane for inventing it. They've mostly come around.

UgnisKarolis · 1 日前

only popular because Facebook made it.

Nope, because React is awesome. It does look like an ugly duckling at first. My thoughts were exactly like yours before I started using it.

HTML directly mixed in your JS

Sounds terrible right? Having HTML, CSS and JS in separate files is separation of technologies not concerns. Having everything in one place lets you see how the whole component will look like in any given state. And that's the magic of React. (more on that at the end)

.JSX files

You don't have to use it but it is very useful. React code generates HTML. Writing down JSX makes programming faster because you can see what HTML is going to be generated. We are already used to changing layout in HTML.

React still sound like a bad idea. And it probably is not an ideal solution. As I said two years ago about Angular, that's the best we've got. Reacts code separation into components, excellent v-dom and single directional flow (flux) support makes it one of the fastest development tools for web apps.

TL;DR MVC was a terrible idea for big apps. Developing apps with React looks ugly only at the start.

fzammetti · 1 日前

It's funny... a few years ago I introduced my company to a relatively new product called ExtJS. I pushed hard to have what was (and still is in fact) our largest, most complex, expensive and mission-critical app built with it... truly, it's an app that makes most others look like child's play in terms of complexity and size, and it it failed today there's a good chance we'd take the business down with us.

At first, there was A LOT of apprehension... "we're mixing concerns!", "there's no separation of layout and code!", "it's a return to building UIs with code rather than markup!", and so on. It took a number of presentation, prototypes and proof-of-concepts to finally win approval, but I did.

Fast-forward a couple of years and now my multi-billion dollar corporation of thousands of developers use ExtJS almost exclusively across the board and there's a general feeling of "why would you do it any other way?!" I can't claim sole responsibility for that, but I most definitely played a big part, but it was an up-hill battle in the beginning for sure.

I'm not trying to evangelize ExtJS here... some people love it, some hate it, and I'm not trying to have that debate here... what I AM evangelizing though is the approach to app construction that it naturally pushes you towards. I mention this only because as you look at React, while it's not exactly the same thing, there's a lot of similarity... certainly to the extent that it eschews a lot of the "conventional wisdom" of the app development community at large.

It's an interesting shift, as someone who's been in this field for more than two decades now... I think there's a shift starting to occur, an architectural mindset change, and React is definitely a part of it. It definitely takes some effort to get your brain wrapped around the underlying concept ESPECIALLY when it seems to go against a lot of ingrained "best practices"... but if you can get past your own prejudices you'll likely find the approach has a ton of merit (whether you like the particular React implementation or not).

RazorCrusade · 23 時間前

I'm another who thought React looked asinine and kinda refused to use it at first. But I ended up with a project where I needed to create an embeddable JS lib and realized there were no great solutions for including the necessary DOM the lib needed on the page, so React was a natural choice since the "DOM" is included in the JS.

I quickly came around to it.

As others have stated, there is no real separation of concerns. If you're using jQuery in your JS, you're already doing the same thing React is doing. And if anything, keeping everything componentized makes it much easier to work on a project since you don't need to find a bunch of disparate files all of your codebase; it's all in one place. With Backbone, your JS is tied directly to some DOM object somewhere, but depending on how it's written, you may need to look in half a dozen places to find all the necessary files. With React, it's just right there where you expect it.

It also forces you (or tries) to get rid of event emitter hell. I, personally, don't really mind largely event-driven applications, but I also can understand that they can be very difficult to trace and understand. If you're using one-way dataflow, you don't have these problems. You know exactly where data is coming from and there it's going.

As far as an additional compilation step... I've always been of the opinion that the less magic bullshit you need happening as a front-end dev, the better. But honestly, you just set up the watcher in a screen/tmux or as part of whatever other build process you have and never think about it again. The annoying-ness of it is really overstated.

trollingisfun · 1 日前

conversely, what's not great about React.js:

constantly changing component/element API if you don't use JSX transforms (e.g. you don't want to use the whole npm + webpack/browserify/jsx-tools transform+bundle+bootstrap+compress workflow)
slow behavior when constantly recomputing object trees (you can solve this with diligence with data manipulation and shouldComponentUpdate OR use ImmutableJS or something)
awkward ass "class" definition with objects (improved/fixed in 0.13)
stupid mixins (largely removed in 0.13)
virtual DOM (it's really just an implementation detail, if browsers got their shit together, it could really just do a digest or anything)
first-class consumption still uses this horrible browser language (though, CLJS/Om is godlike, so there's that)
hyped up, but not as much money making opportunity as angular and ember (not as easy to integrate and just shit into your project -- the opposite is true also, easy to integrate react components into existing projects)
most people fucking suck at writing JS/programming in general, and letting them just write JS makes it hard to fix and enforce structure. not a problem if you're a small shop or you quality control your devs, but in a "big company"/average corpo shop, this will fuck you
stupid JSX/react style attribute names, because of camelCasing fashion freaks
PRs sit in GH for months before ever getting a response, makes you wonder when X bugfix you see on GH is ever going to get merged

...but overall still better than almost every other npm-listed/JS project, so it's really fucking good

more_exercise · 1 日前

I'm only partially aware of React.js, but at least these points that you have here don't seem especially strong.

HTML directly mixed in your JS

Do you use JQuery? Because $("<your html here>") seems to be just as liable to mix the presentation layer in with logic and break separation of concerns.

.JSX files

You don't run any post-coding steps on your coded JS files? Not even minification?

jacobp100 · 1 日前

I was sceptical about putting HTML in js too. But the fact is that as your application gets more advanced, with traditional frameworks, you have so much code in the HTML anyway. Also, JSX is optional. Use the native functions if you really want. It looks to be gaining traction now because of react native.

dsk · 1 日前

HTML directly mixed in your JS mixes the presentation layer with your logic, breaking separation of concerns.

React IS your view layer, so it should have deep knowledge of your HTML structure.

.JSX files - It's built around the concept of compiling your JS files, which to me seems like a framework overstepping its bounds.

Why? JSX is syntactic sugar. You don't have to use it, but you should, because there isn't any good reason not to.

TheAceOfHearts · 19 時間前

React is one of those things that looks like a terrible idea until you try it, and then you realize it's amazing.

I had the same opinion but then I tried it.

BigOnLogn · 1 日前

1.) Turns out, "separation of concerns" isn't that great. See these talks by Pete Hunt and Tom Occhino for Facebook's reasoning. Or, just Google "reactjs separation of concerns." It's been discussed ad nauseum. The gist being, the benefits of separation of concerns aren't as good as the benefits of developing in a component-based architecture (which is what react/jsx gives you). Side note: you don't have to use jsx.

2.) Compilation is a non-issue, IMHO. Chances are, in any project of size, there already a compilation step.

My suggestion, give react a try over a weekend. I'd bet the benefits of components will ease the heartbreak of having to compile code and above you of the sin of not separating your concerns.

angus_the_red · 19 時間前

I just started using it a month or so ago. I love it.

Declarative code is super easy to reason about.
One way data flows are easy to follow.
Components, composition, co-location. Having view behavior and style and markup in the same file is amazing.
It allowed me to give a middle finger to CSS. It's all about inline styles.

React.js isn't the final view framework, but it is a huge improvement. Check out some of the videos from the recent conference if your curious.

lonahex · 17 時間前

HTML directly mixed in your JS mixes the presentation layer with your logic, breaking separation of concerns.

This is the biggest misconception among people reading about react. You don't have to store logic in your components. In fact, it is not even recommended. Only pieces JS code that goes into your components are, triggers and UI behaviour. For example, if my component is a button, I should write the code to change it's appearance in the controller, not to submit an ajax request. I can tell some other part of the application to do that for me (Actions) and then do data manipulations in yet another part (Stores).

React (+ Flux) actually does a great job at separating concerns. Read about flux. If you want to try it, give reflux.js a shot. It is a slightly impure but simpler version of the flux architecture.

Example: Lets say you have a "like" button. When clicked, it send a POST request to the server to record a like and it also changes it appearance. A very basic (perhaps non-working) example would look something like this,

var Like = React.createClass({
    like: function(){
        this.setState({liked: true});
        Actions.like();
    },
    unlike: function(){
        this.setState({liked: false});
        Actions.unlike()
    },
    render: function(){
        if (this.state.liked) {
            return <button onClick={this.unlike}>Unlike</button>
        } else {
            return <button onClick={this.like}>Like</button>
        }
    }
});

This component only declares what the UI should look like and hands off the "logic" part to Actions. A real world like button would look much different. You'd probably use state to update in real time but overwrite it with props, or you would split the action into 2 (requestLike/Unlike and Like/Unline) and only use props to store status of the button. Also there would be IDs involved, etc, etc.

If you are inclined enough, your logic doesn't even have to be a reactjs thing. It can be plain old JS functions, backbone collections/models/controllers or whatever.

In my opinion React actually properly separates the concerns.

Actions -> Logic, Network stuff, etc.

Stores -> Your data and operations you want to perform on it.

Components -> Just the UI.

I've left out a big part of the flux philosophy, the one-directional data flow. This makes the whole thing work so beautifully and tames even the most complex beasts of interfaces. Read about it.

achen2345 · 1 日前

What makes React very popular:

XML pieced into the JS for templating. Web newbs tend to HATE XML, but old timers love it. XML is too verbose for data serialization, but it is absolutely fabulous for higher order concerns like semantics, language, context, and such. JSON is basically the opposite.
React attempts to address the same templating/framework problems that all the MVC frameworks attempt to solve, but it is not MVC. MVC is extremely OOP, which I guess is cool if you would rather be writing Java or Python or anything else.

Separation of concerns is wildly misunderstood. It is about separating requirements into their own respective quasi-isolated realms. It is not about separating code syntaxes that look different. MVC fails at this where there is a separation of model, view, and controller that represent a single component. It still intermangles behavior, content, and presentation. It is more clear to put all the templating logic together in a single bundle (a single concern) and separate out presentation and behavior.

evereal · 1 日前

HTML directly mixed in your JS mixes the presentation layer with your logic, breaking separation of concerns.

Separation of concerns should not mean arbitrarily separating the various web technologies. React actually encourages the good kind of separation of concerns by recommending things like Flux, where you would separate your business logic from your view logic for example.

The reality of today's webapps, is that your components will often have view logic which is as much a part of it's view as any other <div> or <input> in there. Quite simply, your component's HTML is completely broken without that logic, and that logic is completely specific that that particular piece of HTML. It makes no sense to forcefully separate those things, both of their concerns is exactly the same, they just happen to be using two different languages.

vittore29 · 1 日前

A little bit off-topic, but does anyone have a link to more sophisticated example of flux/react, meaning data entry of more than one field per entity and ideally tree-like structure? All those examples showing something like

   <input name="search-value" onChange={@onChange} />

or in best case

   <input  type="text" valueLink={this.linkState('newDescriptionText')} />

which is not clear how to use with flux or in case of state.a.b.c fields to bind

sazzer · 10 時間前

Both of those can be avoided. You can write your code purely in Javascript and totally ignore JSX, and it will work perfectly fine. You are still defining your markup in the Javascript, but it's not embedded HTML...

As for the combination of presentation and logic, if you use something like Flux alongside it then all the presentation layer is doing is rendering to the screen and triggering actions, and the resolution of those actions is what does the actual logic. This means that the same action can be triggered from all over the place and it all does the same thing - which it should.

serapath · 2 時間前

Maybe this is a stupid question, but: If a user interaction changes a model and i have a mechanism to listen to those changes in order to update the components in the view, where each view does not just re-render it's template, but updates very TARGETED only that part of it's template already in the DOM, that needs changes... ... and i use "requestAnimationFrame" + intelligent batching of read's and write's (by using something like https://github.com/wilsonpage/fastdom)

wouldnt that be faster? (because i do not need to compute a diff)

fooey · 1 日前

Facebook making it was actually a big turnoff for me orginally

I'd say React is popular in spite of FB, not because of FB

Uknight · 1 日前

Have you given it 5 minutes yet?

MashedPotatoBiscuits · 22 時間前

I hated it too before i started using.

TheTophs · 1 日前

I find it appealing for a few reasons, but a couple big ones are:

You described the markup in JS as breaking separation of concerns, but I actually find it appealing. You can use React as a pure view. In that use case, I see it as appealing to have markup and styles all in one place. I like using inline styles with JS a lot more than using CSS because it reduces some headaches from unexpected CSS quirks breaking your styles.
The real benefit I like is that the model React uses involves all components just rendering based on state and props. You can not worry about your views being in sync with your model because you just pass down props and state to child components and everything will re-render correctly and in an efficient way. It really can help clean up some code that could otherwise be very tangled and difficult to manage when adding new features.

Regarding JSX, it would be nice to not have to convert to JS files, but I tend to use browserify anyways, so it doesn't complicate that workflow. However, you can avoid JSX altogether if you want to. I just prefer the JSX syntax because the markup looks similar to a DOM hierarchy.

Randolpho · 17 時間前

React is everything that was ever wrong with PHP shuffled off to the browser.

koglerjs · 1 日前

I am in strong agreement when it comes to JSX, but React is popular because when it came out it was a truly new idea about interacting with the DOM, something that no one else was trying and something demonstrably better.

It is certainly not popular only because Facebook made it.

mooogs · 1 日前

"What's so great about React.js?"

read the homepage.

killinghurts · 13 時間前

I agree I think point 1 kills it for me.

RequireJS + !text plugin is the bet I've come across so far.

javascript

調停者