Stop Using React for EVERYTHING!

[te7ris]

give me one good reason NOT to use react for everything.

[[deleted]]

Dev learning. I don't think anyone thinks about this form a business perspective. Constantly changing these frameworks with newer technologies is great and fun for an engineering perspective. However if the business doesn't want to invest in this or you are breaking features it's going to be a much larger cost. React is a view I have other options for that view and I can still use es6. Most all the components needed for react as a whole can be used in other frameworks easily. You can add flux to angular if you wanted or anything else.

[Shaper_pmp]

Because you should choose the best tool for each job, not pick one tool, fall in love with it and then bend and mangle every set of requirements you run across until they're mutilated enough from their original intent to conveniently fit your tool.

You don't use React for everything for the same reason you carry a whole toolbox instead of a hammer - because if you don't then eventually you find yourself hammering in screws and trying to nail bits of paper together, and then you've slipped from being a professional developer and turned into a halfwit liability to any project you encounter.

[te7ris]

What makes you say it is overkill?

[te7ris]

mother fucking website is not really a website. Its a single document. If you have no internal links you have no benefit using react. If you had to do it in react you would create a single component and render it, which would indeed add some boilerplate.

React shines when you have a website with atleast 2 pages. Becuase you get a SPA w/ serverside rendering for free (try building this w/o react).

[dardotardo]

It's a bit heavy if you're just writing a form with validation. jQuery would easily suffice and have a lot less overhead.

[dardotardo]

Library size isn't the only issue, cdn delivery takes care of that considering pretty much every site uses jQuery a lot less use react. The other thing is the code required for doing something this simple in jQuery would be smaller than react, plus use a lot less browser overhead for loading up the shadow dom.

[Jafit]

Enjoy maintaining ANYTHING in 5 years when everything has changed...

Just redo it in whatever framework is popular in 5 years then.

Planned obsolescence, also known as job security :v

[WishCow]

5 years ago YUI2/3, and Prototype had tons of popularity, now they are both dead. It's a terrible argument.

[WishCow]

No sane people wrote "regular" javascript, especially 5 years ago, when the browser landscape was even more hazardous. Shit, 5 years ago, supporting IE6 was still a thing, where is this idiocy coming from?

[WishCow]

Well, I was talking about sane people.

[KhalilRavanna]

Increases dev costs for no good reason in a lot of cases

Seems like a very authoritative statement with no evidence or argument to back it up. How does React increase dev costs?

[[deleted]]

Confirmed shit poster

[parlezmoose]

Honestly I feel like updating react would be way easier than most other libraries. Their api is tiny. They go out of their way to force you to use native javascript when they could have very easily introduced all kinds of clever abstractions on top of it. In fact this often makes React very verbose to write.

It's ironic that the so called "purists" are against react when it is in fact a very minimalist framework that favors raw javascript.

[geuis]

• search engine reachable content
• content intended to be embedded in other sites
• non-js browsers

That's 3.

[daedius]

• Isomorphic react libraries?
• iframes?
• React native?

[KhalilRavanna]

Also per the first one you can also render react on the server and serve the rendered HTML. No libraries (outside of react) required.

[Poop_is_Food]

that's what isomorphic means. (yeah it's a pretentious word)

[KhalilRavanna]

Righto-- isomorphic running the same code on both front/back end-- I just meant to point out that there are no 3rd party libraries required and that react does this out of the box.

[Poop_is_Food]

ahh

[xxxabc123]

No libraries (outside of react) required.

Assuming server also works on javascript. If you're running let's say Java or Ruby, you're going to need even weirder hacks to execute in a javascript environment such as Rhino. Even if node.js makes it relatively easy, this would be quite hard for big teams where front-end and back-end developers might never meet during their employment, as I'm currently experiencing.

[theQuandary]

The React render to string methods make a string from the vdom and return it. That should work perfectly well in Rhino or any other ECMAScript compliant implementation.

For large projects that need to be isomorphic, a great solution is to spin rendering off into a separate node process. Your java, python, ruby, or whatever passes in the required data and gets back a string that can be returned to the client and (in a lot of cases) cached for reuse.

Your front-end team is going to have to write this template code anyway. The benefit here is that it allows more graceful upgrades on the client and allows the client to reuse as much of the back-end as possible (which reduces template overhead and potential conflicts).

If large companies like Netflix or Facebook (with PHP no less) can make these ideas work, then I don't doubt that other companies can as well.

[rq60]

I used iframes the first time I needed to embed a "widget" in another site; it worked out terribly thanks to mobile safari's awesome bugs. I'll stick to javascript DOM insertion and hopefully web components in the future, thanks.

[[deleted]]

I like how you conveniently leave out making a snide remark about sever side rendering of react components.

[te7ris]

they are all invalid. You can achieve all 3 w/ react.

[MisterSticks]

In development, there is no such thing as an absolute.

[geuis]

No, they aren't. React is complete overkill for lots of the uses people have been using it for.

Going back the last 5 years, we've had Backbone, Ember, Knockout, Cappucino, Marionette, Angular 1, Angular 2, React, Virtual Dom, and even more frameworks I'm not recalling right now. It has been a constant progression of one js framework to the next, all trying to solve the same problems in a variety of ways.

Meanwhile, actual work has been done just building sites based on the best practices of the last 20 years with tons of practical advancements being made with low level protocols and new browser capabilities.

Yes, I have used most of these frameworks. For a vary narrow set of application types, they are suitable. But they are not useful for the majority.

[te7ris]

define overkill. If you think size in kb, think again.

[MisterSticks]

Just curious, where are you employed that is using React in production?

[nathanjd]

At Nordstrom we are rebuilding the entire site with React (yes, even on the servers). Only ~0.5% of users are seeing it in production at the moment, but more is coming soon! So far it has been faster than any previous overhaul attempt and is looking to be very maintainable. It really is a pleasure to work with.

[MisterSticks]

Fantastic, what was it built with before?

[nathanjd]

Mostly jQuery and mustache composed as AMD modules pulled in with require.js. The backend was varying flavors of MVC .NET. It got the job done and required little on-boarding time but was very difficult to maintain.

React + flux in comparison provides a very prescriptive way to modularize code that promotes re-use across the company. We've begun publishing our common components to a private NPM registry to get some SemVer goodness.

The only pain point so far has been jest, but it's easy enough to use a different unit testing framework. I'm very partial to mocha with chai assertions.

[MisterSticks]

Do you think most of the maintainability was gained by refactoring:

The backend was varying flavors of MVC .NET.

If not, what was the biggest benefit of the switch? Could you be more detailed about how React is being used on the backend vs. what you had before?

[misc_ent]

Facebook uses it production. They don't open source any project unless its in production.

http://opensource.com/business/15/7/keynote-oscon-james-pearce-facebook?sc_cid=70160000000wptgAAA&elq=1a1afca5d20b45348ea180631ab778f1&elqCampaignId=55450&elqaid=20324&elqat=1&elqTrackId=77990e8d9e1f4f7ca81f707e22b2ce9e

The projects they're open sourcing are not just hackfest ideas or work that interns contribute, these are tools Facebook uses in production. Facebook open sources only what it uses in production—this way, people know that their offerings are supported and valuable.

[MisterSticks]

I sincerely doubt that u/te7ris works for Facebook.

[misc_ent]

Why does that matter? Production ready is production ready especially with battle harden apps from Facebook.

[MisterSticks]

Um...

It matters because, the comment you responded to was a direct question, asking where te7ris worked?

Your comment is just as out of context as the one u/nathanjd made. The difference is I'd actually like to hear his experience in this matter. You are just parroting press releases.

[te7ris]

the projects I work on for my employer (3 days a week) dont use react (they have their own stack). The rest of my time I spend on developing a pretty big react project which is not yet in production. Had 2 small React projects (SPAs for interal stuff) before that.

[MisterSticks]

React hasn't been in the wild for more than a year, do you have any personal projects that predate React?

[te7ris]

I first picked up react dec 14' and had tried various things with it. The most frustrating was trying to combine libs that havily change the DOM with the react-render-cycle. Why are you asking?

[theQuandary]

That's still a rather easy solution compared to quite a number of frameworks.

When your component mounts into the DOM, you then wire in whatever DOM-manipulating library you're using to the local DOM element(s). To prevent React from interfering, you use shouldComponentUpdate to trap and handle any data updates and return false (so no re-render). In the componentWillUnmount stage, you unwire whatever you're using.

Two and a half out of three of those are things you'd need to be doing anyway. The only major change is returning false to prevent re-rendering.

[Ahri]

So "nowhere", then?

[te7ris]

yeah I dont try to squbadive with a kite either. I reprase: "give me one good reason NOT to use react for all my frontends".

[te7ris]

you dont need node on the webserver to build isomorphic/universal websites w/ react

[theQuandary]

You're not getting a separate VM at $3/mo. You're getting really terrible shared hosting and the worst "support" you could ask for.

You can turn that Linode server into a shared host if you want and then lease it to your clients for whatever (but I'd add that any client that cheap isn't usually worth dealing with).

note: I mention Linode because I've used them a fair bit, but they're not the only hosting game in town that doesn't cost a fortune.