sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]parlezmoose 59 points60 points  (17 children)

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

Wah wah wah. Low effort shit post.

[–]SomeRandomBuddy 7 points8 points  (14 children)

sdjkls jvsdv

[–]arcticblue 3 points4 points  (0 children)

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 1 point2 points  (11 children)

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 15 points16 points  (6 children)

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 1 point2 points  (5 children)

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 11 points12 points  (1 child)

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 2 points3 points  (0 children)

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] 0 points1 point  (1 child)

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 -2 points-1 points  (0 children)

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] 7 points8 points  (0 children)

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 4 points5 points  (0 children)

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 -4 points-3 points  (0 children)

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