r/javascript • u/georgehotelling • Aug 27 '15
Stop Using React for EVERYTHING!
https://medium.com/@zackargyle/stop-using-react-for-everything-c8297ac1a64410
u/AceBacker Aug 27 '15
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?
1
u/georgehotelling Aug 27 '15
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.
1
u/SomeRandomBuddy Aug 27 '15 edited May 08 '23
dskvmsdvs
1
u/georgehotelling Aug 27 '15
Not my article, I just found it and figured it would generate a good discussion.
2
u/AceBacker Aug 27 '15
Good point. Use every tool for what it was meant to be used for.
1
u/Anon_8675309 Aug 28 '15
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.
24
u/greim Aug 27 '15
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.
5
u/defcon-12 Aug 28 '15 edited Aug 28 '15
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.
3
u/nschubach Aug 28 '15
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?
-3
-1
u/MrJohz Aug 28 '15
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.
3
u/Sephinator Aug 28 '15
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.
1
u/MrJohz Aug 28 '15
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.
1
u/vcarl Aug 28 '15
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/
41
u/ub3rgeek Aug 27 '15
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.
3
Aug 28 '15
You could use React to build a form for someone to fill out to bid to build your toaster for you
2
u/hahaNodeJS Aug 28 '15
Fuck that bullshit. Use ncurses and C to build the UI for a toaster. What's wrong with you?
0
Aug 27 '15
[deleted]
3
u/YodaLoL Aug 28 '15
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
2
u/dhdfdh Aug 28 '15
What language do they use to create React?
1
u/YodaLoL Aug 28 '15
I'm not following you
1
u/dhdfdh Aug 28 '15
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.
2
u/YodaLoL Aug 28 '15
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?
0
u/dhdfdh Aug 28 '15
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.
2
u/YodaLoL Aug 28 '15
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.
0
Aug 28 '15
[deleted]
-1
u/dhdfdh Aug 28 '15
None of what you said is my point except a modification of this:
most redditors don't have the knowledge or understanding
1
u/theQuandary Aug 28 '15
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.
-2
u/dhdfdh Aug 28 '15
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.
62
u/parlezmoose Aug 27 '15
"You guys think you're cool but news flash: UR NOT."
Wah wah wah. Low effort shit post.
9
u/SomeRandomBuddy Aug 27 '15 edited May 08 '23
sdjkls jvsdv
3
u/arcticblue Aug 28 '15
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.
2
u/jellatin Aug 27 '15
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.
14
u/ilmmad Aug 27 '15
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.
2
u/jellatin Aug 27 '15
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.
10
u/nschubach Aug 28 '15
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
someNameorsome-nameto 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.
3
u/Gstayton Aug 28 '15
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
1
Aug 28 '15
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.
-1
u/jellatin Aug 28 '15
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?
10
Aug 28 '15
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.
4
u/parlezmoose Aug 28 '15
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.
-3
u/dhdfdh Aug 28 '15
Funny. I guess no one built anything until React came around. We all sat hopelessly on our hands till now.
8
u/yodasw16 Aug 28 '15
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.
10
4
u/polnisch_vodka Aug 27 '15
Yeah, if you could give me one reason to use backbone over Angular (or React). That would be great.
3
u/yodasw16 Aug 28 '15
One reason over Angular: easy to do server rendered templates with backbone. Not so much with angular.
2
u/Cintax Aug 28 '15
React can do that too though and, at least in my opinion, is way less verbose and complex than Backbone...
2
u/polnisch_vodka Aug 28 '15
You can include the templates in the page and render them on the server side (I'm doing this for easy i18n).
6
4
u/IfOneThenHappy Aug 27 '15
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.
2
Aug 28 '15
My reaction to all articles like this: Why do you care what other people do?
If it's your team, sure this is valid.
2
Aug 28 '15
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.
7
u/te7ris Aug 27 '15
give me one good reason NOT to use react for everything.
7
Aug 27 '15
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.
4
u/Shaper_pmp Aug 27 '15
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.
3
u/dardotardo Aug 27 '15
It's a bit heavy if you're just writing a form with validation. jQuery would easily suffice and have a lot less overhead.
0
Aug 27 '15
[deleted]
3
u/dardotardo Aug 28 '15
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.
-1
u/geuis Aug 27 '15
search engine reachable content
content intended to be embedded in other sites
non-js browsers
That's 3.
14
u/daedius Web Components fanboy Aug 27 '15
Isomorphic react libraries?
iframes?
React native?
5
u/KhalilRavanna Aug 27 '15
Also per the first one you can also render react on the server and serve the rendered HTML. No libraries (outside of react) required.
3
u/Poop_is_Food Aug 27 '15
that's what isomorphic means. (yeah it's a pretentious word)
2
u/KhalilRavanna Aug 27 '15
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.
1
1
u/xxxabc123 Aug 28 '15
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.
1
u/theQuandary Aug 28 '15
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.
2
u/rq60 Aug 27 '15
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.
1
Aug 28 '15
I like how you conveniently leave out making a snide remark about sever side rendering of react components.
4
u/te7ris Aug 27 '15
they are all invalid. You can achieve all 3 w/ react.
1
0
u/geuis Aug 27 '15
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.
4
u/te7ris Aug 27 '15
define overkill. If you think size in kb, think again.
-2
u/MisterSticks Aug 27 '15
Just curious, where are you employed that is using React in production?
7
u/nathanjd Aug 27 '15
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.
1
u/MisterSticks Aug 28 '15
Fantastic, what was it built with before?
1
u/nathanjd Aug 28 '15
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.
1
u/MisterSticks Aug 28 '15
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?
→ More replies (0)5
u/misc_ent Aug 27 '15
Facebook uses it production. They don't open source any project unless its in production.
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.
0
u/MisterSticks Aug 28 '15
I sincerely doubt that u/te7ris works for Facebook.
2
u/misc_ent Aug 28 '15
Why does that matter? Production ready is production ready especially with battle harden apps from Facebook.
0
u/MisterSticks Aug 28 '15
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.
3
u/te7ris Aug 27 '15
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.
1
u/MisterSticks Aug 28 '15
React hasn't been in the wild for more than a year, do you have any personal projects that predate React?
2
u/te7ris Aug 28 '15
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?
1
u/theQuandary Aug 28 '15
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.
→ More replies (0)-2
0
Aug 27 '15
[deleted]
4
u/te7ris Aug 27 '15
What makes you say it is overkill?
0
Aug 27 '15
[deleted]
3
u/te7ris Aug 27 '15
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).
0
Aug 27 '15
[deleted]
2
u/te7ris Aug 27 '15
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".
0
Aug 27 '15
[deleted]
0
Aug 27 '15
[deleted]
2
u/te7ris Aug 27 '15
you dont need node on the webserver to build isomorphic/universal websites w/ react
0
Aug 27 '15
[deleted]
0
Aug 27 '15
[deleted]
2
u/theQuandary Aug 27 '15
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.
0
Aug 27 '15
[deleted]
7
u/WishCow Aug 27 '15
5 years ago YUI2/3, and Prototype had tons of popularity, now they are both dead. It's a terrible argument.
0
Aug 27 '15
[deleted]
3
u/WishCow Aug 28 '15
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?
0
9
u/KhalilRavanna Aug 27 '15 edited Aug 27 '15
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?
-19
2
u/parlezmoose Aug 28 '15
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.
0
Aug 27 '15
[deleted]
0
u/Jafit Aug 27 '15
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
3
u/dwighthouse Aug 27 '15
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.
2
u/Poop_is_Food Aug 27 '15
react rendering canvas? I call shenanigans. I mean it can append a <canvas>, but it can't actually draw anything right?
4
u/ub3rgeek Aug 27 '15
2
u/Poop_is_Food Aug 27 '15
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.
2
u/dwighthouse Aug 28 '15
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
2
Aug 28 '15
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
3
u/dwighthouse Aug 28 '15
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.
1
u/Poop_is_Food Aug 28 '15
would it be fair to call these things "extensions" of react?
2
u/dwighthouse Aug 28 '15
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).
3
u/html6dev Aug 28 '15
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.
1
Aug 27 '15
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.
Item
Item
1
u/f3nnix Aug 28 '15
Gona use react for "hello world" page, 30 components right there. U jelly? /dance
1
u/hyptos Aug 27 '15
Netflix is using react :o
http://techblog.netflix.com/2015/08/making-netflixcom-faster.html
But he is right.
0
u/tipsqueal Aug 27 '15
Just because a company is using some piece of technology doesn't mean it's a good idea.
1
u/Zinlencer Aug 27 '15
Netflix seems to be pretty fond of ReactJS according to this video. https://www.youtube.com/watch?v=g01dGsKbXOk
4
u/tipsqueal Aug 28 '15
That doesn't change what I'm saying. I'm also not saying React is bad. Please read this for further information:
1
u/Poop_is_Food Aug 27 '15
Template in the same file as my rendering logic and listeners. That right there is my reason to use react for everything.
3
u/lmorchard Aug 28 '15
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.
1
u/pierreten Aug 28 '15
This guy isn't doing Pinterest engineering any favors with this blog post.
1
u/ahref Aug 29 '15
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!
-1
-10
4
u/nerdgrass Aug 28 '15
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.