Hacker News Reader

Comment by z3t4 | Hacker News Reader

I'm trying hard to figure out why someone want to use something like this or React, when vanilla HTML, CSS and JavaScript seems much easier and more performant. The only thing I can think of is that appendChild is a bit tedious, but createClass seems even more boilerplate.

View on HN

We moved from HTML + jQuery to React.

Why? In a large part, it's because writing reusable components in React makes a world of difference AND is a lot more readable. The jQuery code was a mess of accessing DOM elements and was liable to break without warning when updating the HTML.

The other thing is that it's much easier to write a functional, complex UI. React will attach and detach listeners for you, will create and delete elements, etc. You are not going to be writing lots of hard-to-read boilerplate in onClick handlers. Finally, combined with something like Redux, you get a single-source-of-truth backing the UX, which avoids a lot of the issues I've seen in other jQuery codebases, where there are race conditions between various components during initialization.

It's a completely different way of writing a UI, but I don't see myself going back to the traditional paradigm.

> The only thing I can think of is that appendChild is a bit tedious, but createClass seems even more boilerplate.

You can't compare the two. A component is made of any number of HTML elements and other components, it's not like you are going to use createClass every time you need to want to display a span.

> I'm trying hard to figure out why someone want to use something like this or React

There are many reason why one would want to use framework X,Y,Z instead of writing his own (because at the end of the day, any large application will need some form of framework/toolkit to be maintainable).

The first reason I guess is that in practice the code you depend on is the code you don't have to maintain and test.

The second reason is politics. You work with 50 engineers. You decide to write your own toolkit. I'm pretty sure you'll end up having endless debates about what is the right architecture. Now if you tell the rest of your team or the management "Facebook/Google is using that, they can't be wrong", It can save a lot of time.

The third reason is "laziness". Many "engineers" using React or AngularJS actually don't know how the DOM really work, like many people only know jQuery and not standard DOM API in order to perform a task, or many "engineers" don't know how to write CSS so they use Bootstrap. Yet the same engineers are writing 1 million dollars SPA for Fortune 500 companies ...

Frameworks are a trade-off. By learning one, you expect the investment to save you time, maintenance cost and not to be leaky(i.e. not having to understand the internals of a framework in order to use it). In an era where engineers are asked to be backend engineers, front end engineers, DBA, UX/UI specialist,data analysts, statisticians, server administrators, to know the OSI model from top to bottom,to know 10 languages with 5 years of professional experience in each of them and what not, some engineers don't consider learning the fundamentals of the DOM a worthy investment.

> Many "engineers" using React or AngularJS actually don't know how the DOM really work, like many people only know jQuery and not standard DOM API in order to perform a task, or many "engineers" don't know how to write CSS so they use Bootstrap.

Many know how all these things work but prioritise your first reason "code you don't have to maintain and test".

I think you are on to something. When you have hundreds of (front end) developers working on the same UI, refactoring becomes more of a people management problem then a programming problem. And something like React would help in such circumstances. So I can imagine how it would be useful for Facebook. But not the average small team or solo dev.

I would be surprised if there was a even one single example of "hundreds of (front-end) developers working on the same UI".

Maybe not simultaneously, but over time?

The vanilla way tends to result in state spread out throughout your JS and DOM. React UIs act like predictable functions: you describe the UI you want with your current state as the input and React makes the visible UI match that.

You also want to batch your DOM manipulations as much as possible, and you get it automatically by using vDOM libraries.

I think this is a JQuery problem, as it makes complexing state the path of least resistance. i.e. modifying the DOM directly instead of via functions. Resulting in code that is hard to test or debug. React seems to fix this, witch makes it a good argument on why to use it. My counterargument for "vanilla" JS/HTML is that you can refactor the bad parts. But you can't get rid of React, or you would have to rewrite your whole app! Like when the next JS fashion/framework comes. grin

React itself is just the view. You can replace your template language without redoing everything if you want. Khan Academy, for example, still has some Backbone views that render with React. We also have some Handlebars templates that we haven't converted over yet. That's all peacefully coexisting, though we'd love it if all of our views were React and more of our data handling was just pure functions.

But you CAN get rid of React and not have to rewrite your whole app. Redux, for example, isn't coupled with React at all. React-Redux gives you the tools you need to tie the two together, but you could easily take your Redux code (reducers, actions creators, selectors) with you to a new framework like Angular 2.

"Current state as the input" sounds like a big caveat. I'm having trouble distinguishing this from "you describe the UI you want with your current document as the input and jQuery/JS/whatevs makes the visible UI match that."

Do you happen to have any benchmarks to back this up?

Reply on news.ycombinator.com