Live data from Hacker News

My Reaction to React

pseudoconcurrentthought.wordpress.com

141–147 of 147 posts

Re: My Reaction to React

#141
post #61

It's missing the most important React feature (Virtual-DOM diff.). More specifically, he's manually adding and keeping track of all DOM elements. Once elements need to be updated, he would need to go back in the DOM and manually add/remove/change elements.. welcome back to the jquery messy world. Whereas with React, the render function doesn't change because it gets smartly rerendered. Also, as far as I'm concerned,…

Let's be clear, manually updating the DOM is as optimized as you can possibly be. Virtual-DOM isn't somehow magically more efficient than direct, imperative manipulation of the DOM. Virtual-DOM diffing was created to try to emulate the effect of refreshing the entire page every time state changes like we did with stateless web applications but do it in a relatively performant way.

>Let's be clear, manually updating the DOM is as optimized as you can possibly be. Virtual-DOM isn't somehow magically more efficient than direct, imperative manipulation of the DOM.

The actual problem is how to efficiently traverse/modify DOM structure, in the end you'll just reimplement virtual dom.

Re: My Reaction to React

#142

Earlier quoted context omitted.

Let's be clear, manually updating the DOM is as optimized as you can possibly be. Virtual-DOM isn't somehow magically more efficient than direct, imperative manipulation of the DOM. Virtual-DOM diffing was created to try to emulate the effect of refreshing the entire page every time state changes like we did with stateless web applications but do it in a relatively performant way.

>Let's be clear, manually updating the DOM is as optimized as you can possibly be. Virtual-DOM isn't somehow magically more efficient than direct, imperative manipulation of the DOM. The actual problem is how to efficiently traverse/modify DOM structure, in the end you'll just reimplement virtual dom.

Well, no, not really. You will only replace/update the elements that you need to which is pretty much what vdom boils down to. It's just tedious, is all.

Re: My Reaction to React

#143

Earlier quoted context omitted.

>Let's be clear, manually updating the DOM is as optimized as you can possibly be. Virtual-DOM isn't somehow magically more efficient than direct, imperative manipulation of the DOM. The actual problem is how to efficiently traverse/modify DOM structure, in the end you'll just reimplement virtual dom.

Well, no, not really. You will only replace/update the elements that you need to which is pretty much what vdom boils down to. It's just tedious, is all.

In a real application, you'll need to deal with moving elements, document shape will be changing, etc. Trying to solve this cases is the most complicated part of vdom libraries. If you try to do naive replace/update, it will be significantly slower.

Re: My Reaction to React

#144
post #127
post #64

Am I the only one that thinks that the author is trolling? I mean, the final code has obvious flaws: a) Difficult to read and mantain. (Compare with the version below). b) Inefficient in a real world scenario as it has to recreate the DOM every time the model changes. c) Difficult to test as it requires a DOM API. d) XSS issues (Text returned from the service is not escaped in the DOM!) e) Non isomorphic (Unless we h…

Could you please point out where the XSS issues are?

Stupid me. I missread the code and did a proof of concept in jsbin just adding "alert('XSS');" as a hobby. Now I realise that I added it in the HTML view so I was just closing the original tag. So, no XSS issues, AFAIK. I am updating my original response to reflect this.

Nevertheless, using a framework like React protects you automatically from accidentally adding XSS vulnerabilities.

Re: My Reaction to React

#145
post #144
post #127

Earlier quoted context omitted.

Could you please point out where the XSS issues are?

Stupid me. I missread the code and did a proof of concept in jsbin just adding " alert('XSS'); " as a hobby. Now I realise that I added it in the HTML view so I was just closing the original tag. So, no XSS issues, AFAIK. I am updating my original response to reflect this. Nevertheless, using a framework like React protects you automatically from accidentally adding XSS vulnerabilities.

Thanks, I thought I missed some XSS unknown to me in that code. Agree with you about React and other frameworks making it hard to accidentally introduce XSS.

Re: My Reaction to React

#146
post #97
post #64

Am I the only one that thinks that the author is trolling? I mean, the final code has obvious flaws: a) Difficult to read and mantain. (Compare with the version below). b) Inefficient in a real world scenario as it has to recreate the DOM every time the model changes. c) Difficult to test as it requires a DOM API. d) XSS issues (Text returned from the service is not escaped in the DOM!) e) Non isomorphic (Unless we h…

Thanks for posting your React version and offering a bullet list of real points of critique. That said, please don't use the word "trolling" to make what is essentially an ad-hominem attack against someone whose point you disagree with. The author probably spent at least an hour, if not multiple hours, thinking through a problem and presenting a solution as a blog post. Whatever you think of his argument, this is cle…

I agree that maybe "trolling" is not the most accurate description. The author seems to be a competent coder, so I am assuming that he knows that such a solution for view components is flawed at least and that it would be a nightmare to go that way.

My biggest concern with the original post is the next sentence, "If you want to use React, fine, I am not trying to convince anyone not to. I just want to show that components in a JavaScript application are quite simple to do and do not require any framework at all to do so." (The author has updated the post to clarify that "I am a proponent of using libraries and frameworks." I think that this was missing in the original post, I think that it would have been nice to add at the end of the post "Crazy, isn't it? Don't do it! Don't reinvent the wheel and tada-tada-tada...)

Not sure about the intentions of the author, but I think that the original post makes a great case to support the use of these frameworks and not the opposite.

Re: My Reaction to React

#147

Earlier quoted context omitted.

Let's be clear, manually updating the DOM is as optimized as you can possibly be. Virtual-DOM isn't somehow magically more efficient than direct, imperative manipulation of the DOM. Virtual-DOM diffing was created to try to emulate the effect of refreshing the entire page every time state changes like we did with stateless web applications but do it in a relatively performant way.

> manually updating the DOM is as optimized as you can possibly be. Optimized in the sense that it uses less memory and cpu. But the code isn't optimized for humans to reason about (not to mention changing it.) React was never about performance, it's about maintainability, readability and reasonability. For me readable and maintainable code is (almost always) more important than fast code.

On big project, it becomes impossible to optimize the DOM interaction yourself, so you start to do very inefficient operations for sanity's sake. React on the other hand abstract that for you.

I had a project with Angular where one page was really slow. I re-implemented it with backbone / jquery, it was a bit faster but really hard to read and maintain. With React, the code was simpler AND faster, which I was really surprised about.

Post reply on HN