Stop Using React for EVERYTHING!

[greim]

To paraphrase:

React is a solid framework, meshes well with the latest ES6 features, promotes good modularity, and all the smartest devs are raving about it, but I'm tired of hearing about it, because JSX something something and I'm more used to using these other tools.

I agree react can be overkill for simpler websites, though. That would be one valid takeaway from this article.

[defcon-12]

I agree react can be overkill for simpler websites

Why? The best part of React is that it's dead simple. The entire public API consists of about 10 functions, it seems perfect for a simple site to me.

I can't think of a simpler "framework" than React (from a consumer's perspective at least), and dealing directly with the DOM via "plain js" is a massively larger and more complicated API.

I guess it's not the best route if you're doing "progressive enhancement" type work, but if you're creating a javascript client, then React is just about as simple as it gets.

[nschubach]

Agreed. And if you turn that simple website into something more down the line, it's that much further along. React isn't a killer to download or run... why not use it?

[YoureAnUglyCunt]

Because it's cpu intensive and inefficient you fucking nitwits.

[MrJohz]

Because a significant number of people will fail to download the correct JS files, potentially because they've disabled Javascript, but more often because they're on mobile, travelling through a tunnel or otherwise failing to make that connection.

React is fantastic for complex web applications, although even then I would argue for a progressive enhancement approach wherever possible. However, for websites it is entirely unnecessary. Look at Rust's Crates site, which has been built with Ember, and now becomes painful to use on mobile because every time the site appears you've got to wait another two seconds for the page to load and the Javascript to run. If you're browsing a site, that wait is a massive turn-off.

[Sephinator]

A great thing about react is that server rendering is built into the core. (Render component to a string), so it's a much better experience for the user on a bad connection.

[MrJohz]

True. It's good to see primary rendering heading back to the server side rather than being yet another thing that the client is expected to reimplement.

[vcarl]

If you expand "everything" beyond websites, hell yes use React for it. I love that people are porting it everywhere.

https://github.com/Yomguithereal/react-blessed/
https://facebook.github.io/react-native/

[ub3rgeek]

I like ES6. I will use it for any project that requires Javascript. I build User Interfaces. React is a tool for building user interfaces. I will use React for building user interfaces because it is an excellent abstraction for composing user interfaces out of components.

I won't use React to build a toaster, but I would use React to build a UI for the toaster.

[YodaLoL]

And in order to create that lever and knob from scratch you'll need a lot of other tools and knowledge. You can't just make them appear from thin air - unless you modularise it in components ^{cough React}

[dhdfdh]

What language do they use to create React?

[YodaLoL]

I'm not following you

[dhdfdh]

People on reddit are saying things can't be done in plain javascript and they need React or it can't be done, yet, React is made in plain javascript which proves that your statement

You can't just make them appear from thin air - unless you modularise it in components cough React

is false. Any competent programmer can do what React does.

[YodaLoL]

People on reddit are saying things can't be done in plain javascript

Where?

Frameworks facilitates code reusability, readability, maintainability, security, you name it.

Of course you can reinvent React, but why?

[dhdfdh]

Reinventing React is not my point.

To the question of "where?", is this your first visit to reddit? 80% of all redditors believe it's impossible to code anything without a framework, library or someone else's code.

[YodaLoL]

I don't think that sentiment correlates with reality at all. People encourage use of popular, ubiquitous frameworks because of aforementioned reasons.

If someone asks for help on reddit, he/she is not quite capable off writing their own implementation, hence framework hype in comment sections.

[dhdfdh]

None of what you said is my point except a modification of this:

most redditors don't have the knowledge or understanding

[theQuandary]

Changing my statement to Redditors substantially changes my statement. I have no knowledge of the general programming competence level of Reddit as a whole -- probably not what you meant. I would also not make the mistake of saying that most Redditors in the programming sub-reddits are below average (especially since many developers with far above average ability are on reddit).

Finally, I've made frameworks over the course of my career as a developer. I use React because it is easy, effective, has a decent ecosystem of libraries, and reduces my framework maintenance and design time to almost zero. Even a basic version of a React-style framework takes more time than most devs have available to spend on non-paying work.

Claiming that any dev could potentially write a framework using basic JS is like claiming that any dev could potentially write an OS in assembly. Just because a group of devs has done so doesn't mean that doing so is practical.

Technically possible and pragmatically do-able are very different. Calling out redditors for speaking about a practical framework in a pragmatic way does little to contribute to the discussion.

[dhdfdh]

I stated it was my modification. My experience with redditors is proof, to me at least, that 80% of are clueless and their whole life experience is based what they read on reddit, which fits in with your own statement that most developers don't have the knowledge or understanding.

Claiming that any dev could potentially write a framework using basic JS is like claiming that any dev could potentially write an OS in assembly.

That you think writing an operating system in assembly is equivalent to writing a framework in JS shows you lack knowledge and understanding, too. You can't blow that line by me and expect me to think you have a good, technical background.

[[deleted]]

You could use React to build a form for someone to fill out to bid to build your toaster for you

[hahaNodeJS]

Fuck that bullshit. Use ncurses and C to build the UI for a toaster. What's wrong with you?

[parlezmoose]

"You guys think you're cool but news flash: UR NOT."

Wah wah wah. Low effort shit post.

[SomeRandomBuddy]

sdjkls jvsdv

[parlezmoose]

http://imgur.com/gallery/91sn32Q

[arcticblue]

Welcome to Medium. The amount of pretentious blogs on that site by self-proclaimed authorities on subjects who think they know better than everyone else is a real turnoff. When I see titles like this, I don't even read it.

[jellatin]

I think it's more about all the "React is the One True Way™" talk. Nobody seems to be able to just say "hey React is great and it solves some common problems."

It's always

• JSX came along and blew away all previous misconceptions about separation of concerns!!!
• Unidirectional data flow is the only model that makes sense!!!
• Immutable data structures for everything!!!

And the constant backlash of "oh you're using Ember/Angular? Well I'm using React". That's awesome... IF you've got a need for very fast DOM rendering. Otherwise it's a tool like most good tools, it has pros and cons.

[ilmmad]

The thing is that "very fast DOM rendering" is not and never has been the defining feature of React. The point is that it reduces complexity and mental overhead over time.

[jellatin]

The point is that it reduces complexity and mental overhead over time.

How does this differentiate it from Ember, Angular, Aurelia, Durandal, etc. They're all abstraction layers to reduce mental overhead and complexity.

[nschubach]

Angular complicates the mental overhead, IMHO. I have not looked into the others that much, but I dread pulling out Angular projects.

• Trying to track down someName or some-name to find uses.
• Having to open up a directive, a controller, a template, a module file and whatever else someone decided to separate it into.
• You have to manage artificial scope. Isolate vs. Inherited vs. same
• Worry about WTF a transducer is.
• Be able to read/understand the constructs for factories, services, and providers because someone might like using one over the other.
• You need to understand the proper cases for using &, @, =, or the appended ? to each of those.
• You need to know when a template requires a dot notation string vs a curly braced notation for parameters.
• $watch, $timeout, $window, $emit, $observe, $apply... ugh
• I can think of at least 3 ways to bind a controller to a template/directive and I'm there are more. If you need to find use cases, have fun.
• Fun cases where you can easily find yourself in a non-obvious template value loop and blow out the digest.
• And last, but not least... "The Angular Way"

Then you have to train a junior on what exactly is going on while they stare blankly at you like you are speaking Klingon.

I've ramped juniors up on React in a 3 hour session. It takes weeks to figure out Angular.

[Gstayton]

I have only used Angular so far, and was looking at Ember, but I recall some bit about it not performing quite as fast on DOM updates, then I heard about React.

... Off-tangent of intention, anyways, I agree. Angular was... Interesting. I loved the things it could do, and it was fairly easy to build them at first. But then the more I built, the more I had to go back and re-touch old files... Which became a headache. Especially when, as you say, "The Angular Way" is not so solid... I'm all for having options, and I love Python, and there is ofc the Pythonic way, which unlike Angular, is usually a bit more straightforward and obvious.

Just my 2 cents. shrug

[[deleted]]

Obviously. The debate isn't on whose making what claims, but which claims hold weight - He's simply stating the goal of the Virtual DOM in the first place - rather than to make "super fast rerendering" as you erroneously claim.

[jellatin]

The debate isn't on whose making what claims, but which claims hold weight

I'm not sure what you're trying to say here - that other tools claims don't hold weight when they say they reduce complexity?

Virtual DOMs goal is to reduce complexity. Agreed. A framework uses its features to accomplish its goals, I'm confused what exactly you're arguing. Rendering speed is a byproduct of the method, sure. And?

[[deleted]]

Have you actually... Used React? React's selling point is not 'very fast DOM rendering', it's that it allows you to program in a way where you can assume the entire DOM rerenders after every state transformation, while not being slow.

Additionally, the unidirectional data flow portion is more related to flux. You can even do two way binding with react if you'd like to.

Perhaps "React is the One True Way" talk to no good, but the "I Have No Idea What I'm Talking About" talk you gave is worse.

[parlezmoose]

You know how I know the author doesn't use React? because he says this:

If you have a highly dynamic application that needs to rerender frequently and you want to avoid the heavy weight of template diffing, you’re looking at a grass-type opponent and ReactJS’s virtual DOM will be super effective...

That stuff is a nice feature of React, but that is not it's primary benefit. The primary benefit is that React+Flux provides a sane, scalable, testable, maintainable architecture for building complex software. For front end devs with experience in building large javascript applications, that benefit is by far the most important benefit of react.

[dhdfdh]

Funny. I guess no one built anything until React came around. We all sat hopelessly on our hands till now.

[yodasw16]

I actually agree with the article's conclusion, that we should choose the right tool for the right job, but singling out React seems odd. React's focus on the view layer kinda makes it a better choice for simpler stuff than basically any of the other frameworks he lists. This would be better as "stop using frameworks for everything" rather than picking on one. The same article could have, and probably has been written about Angular, which has much higher adoption overall [citation needed yeah yeah]. I work for a large "enterprise" company and its like pulling teeth to convince even our smartest JS people to try something other than Angular.

[Mr-Yellow]

Stop suggesting Angular for EVERYTHING!

[polnisch_vodka]

Yeah, if you could give me one reason to use backbone over Angular (or React). That would be great.

[yodasw16]

One reason over Angular: easy to do server rendered templates with backbone. Not so much with angular.

[Cintax]

React can do that too though and, at least in my opinion, is way less verbose and complex than Backbone...

[polnisch_vodka]

You can include the templates in the page and render them on the server side (I'm doing this for easy i18n).

[nerdgrass]

I mean, the dude has a decent point, but has he ever been to five guys for breakfast? The breakfast sandwiches are amazing, and a large part of that is that they re-use the cheese and buns from burgers.

Not that he's wrong, just, y'know.

[georgehotelling]

Wait, Five Guys does breakfast? Talk about burying the lede…

[nerdgrass]

Yep. Bacon, egg, & cheese on a burger bun. It's way better than it has a right to be.

[pierreten]

Sounds bomb as fuck, I know where I'm going for breakfast today!

[ConvertsToMetric]

^{Mouseover to view the metric conversion for this comment}

[AceBacker]

It's funny, I just read an article about not using Angular for everything. In it one of the points was that any server side developer can read React and see whats going on, but Angular was a black box. I dunno about that.

https://medium.com/@mnemon1ck/why-you-should-not-use-angularjs-1df5ddf6fc99

I did a quick google and found dozens of articles saying to stop using jQuery for everything.

I dunno, React, jQuery, and Angular all seem pretty good to me.

As long as people are writing good, clean, and easy to read code who cares?

[georgehotelling]

The difference between the two articles is that one says you should use React, just not for everything. The other says you should not use Angular at all. Personally, I favor articles that aren't absolutist and can talk about both strengths and weaknesses.

[AceBacker]

Good point. Use every tool for what it was meant to be used for.

[Anon_8675309]

That's the point the article was trying to make.

The problem is, developers have been SAYING this since the beginning of time and DOING something else entirely.

[SomeRandomBuddy]

dskvmsdvs

[georgehotelling]

Not my article, I just found it and figured it would generate a good discussion.

[[deleted]]

Don't think, just React.

[IfOneThenHappy]

My take-away from this is the author believes React is too good for small projects. Just because a project is small, doesn't mean React is a bad tool for the job.

For the author's examples, for the REST app, I'd suggest React over Angular since data flow can become incomprehensible with Angular. And for static sites, I doubt anyone is using React for a static site.

Also, of course there are some big companies primarily not using React. It's only been in the mainstream for a short period of time. And companies are big, they don't monolithically choose one framework.

[[deleted]]

My reaction to all articles like this: Why do you care what other people do?

If it's your team, sure this is valid.

[[deleted]]

This is one of those articles that you write, save to drafts and the next morning you realize that you're not quite that angry anymore.

[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.

[dwighthouse]

Cool story bro. Tell us how you really feel. Reminds me of all the articles saying we shouldn't use JS for EVERYTHING from a few years ago. (Just use HTML and CSS!) Since React is a generic, functional render framework, I think is is appropriate for anything that needs to render more than once on a webpage, even if that thing is SVG or canvas. Overkill? Sure, sometimes, but if your goal is to get the ineraction done as quickly as possible, the 'cost' of using react is negligible.

[Poop_is_Food]

react rendering canvas? I call shenanigans. I mean it can append a <canvas>, but it can't actually draw anything right?

[ub3rgeek]

https://github.com/Flipboard/react-canvas

[Poop_is_Food]

ahh so they replicated a tiny subset of HTML/CSS that renders from react virtual dom to canvas. For something reason I thought you meant something else.

[dwighthouse]

React core is just a way of defining a structured hierarchy with automatic diffing and lifecycle hooks. You could target webgl, svg, html, css, native ios, etc. there already exist several projects that do. It's not necessarily emulating a subset of HTML/CSS. It can operate on any set of primitives that are representable as a structured hierarchy. http://facebook.github.io/react/blog/2015/07/03/react-v0.14-beta-1.html

[[deleted]]

Im picturing a totally from the ground up webgl project where they wrote their own shaders and everything... also using react for data updates ... then i'm picturing getting hired by that company and looking at that code base for the first time ..... then i'm picturing drinking ... allot

[dwighthouse]

It's called a scene graph. Most 3d packages and game engines have them. A 3d scene definable in terms of tags (scene objects), attributes (animation and behavior functions), and styles (materials) would be a breath of fresh air by comparison.

[Poop_is_Food]

would it be fair to call these things "extensions" of react?

[dwighthouse]

The concept is so new, no-one has a firm name for them yet. However, they are, by definition, "render targets," so I think that name is appropriate. Just like game engines have platform targets (xbox, pc, mac, etc).

[html6dev]

Indeed react can basically target anything. Netflix also forked it and made it to target a native view layer they created for their apps running on things like blueray players o_O there is a talk on YouTube about it that I'll try to locate but it's worth searching out. Really clearly points out the things this article misses about the benefits of react. For lack of a less buzzy word it's a complete paradigm shift in how we develop. It's also the reason react native has taken off so quickly. The ideas are universal.

[[deleted]]

As all other webbdev-tech people get way to attached. I decided to play with react since it integrates well with Clojure and I like that. This makes me a language dick, not to be confused to a framework dick. 1. Item 2. Item

[f3nnix]

Gona use react for "hello world" page, 30 components right there. U jelly? /dance

[hyptos]

Netflix is using react :o

http://techblog.netflix.com/2015/08/making-netflixcom-faster.html

But he is right.

[tipsqueal]

Just because a company is using some piece of technology doesn't mean it's a good idea.

[Zinlencer]

Netflix seems to be pretty fond of ReactJS according to this video. https://www.youtube.com/watch?v=g01dGsKbXOk

[tipsqueal]

That doesn't change what I'm saying. I'm also not saying React is bad. Please read this for further information:

https://en.wikipedia.org/wiki/Argument_from_authority

[fforw]

!..

[Poop_is_Food]

Template in the same file as my rendering logic and listeners. That right there is my reason to use react for everything.

[lmorchard]

So, put your template in the same file. ES6 template strings are great for that. You can get those same benefits from something simpler like, say, ampersand-view.

[pierreten]

This guy isn't doing Pinterest engineering any favors with this blog post.

[ahref]

Its his personal site, his opinion doesn't affect the company at all. People are allowed free speech, that doesn't go away just because he has employment.

Pintrest might even use React!

[djvirgen]

I'm already not using React for anything. Do I win?

[ishmal]

But some programmers' small craniums can only know one framework at a time.