Echo JS 0.11.0

<~>

aselvini 3573 days ago. link 1 point
It seems to me the author misunderstands what's behind React: it's not a framework but just a library, focused on a functional approach (versus an imperative one) older than  "the pattern survived in decades", sentence which doesn't prove there could not be something better. 
The author has a lots of experience, because of this I would have expected more technical criticism about React flaws, avoiding illations about companies; he seems more frightened to leave his comfort zone than to understand how you can do something different without coupling, without the MVC pattern and explain why React is doing it in the wrong way.
ben 3574 days ago. link 1 point
I'm almost certain that React will evolve with the native APIs. Or maybe that's wishful thinking, but Facebook has been pretty on the ball with these things. React's greatest advantage at present, in my mind, is React Native.
qbert 3573 days ago. link 1 point
React Native? Have you seen or tried it?
ben 3573 days ago. link 2 points
Not yet, but I find the theory enticing. The author's major complaint - with which I sympathize - concerns standard implementations vs. frameworks like React. With React native, the point is rendered moot as there is ostensibly no comparable solution. Let's see if it lives up to the hype.
ksmithut 3574 days ago. link 1 point
I've recently begun building some pretty complex web apps with React and Flux, and personally, it's been a breath of fresh air. I do agree very strongly, however, that the more we make use of the APIs built into the browsers, there will be more effort put into building out what we already have, at least you would hope. Although I really enjoy working in React, I think that I will start to utilize those APIs that can do basically the same thing without having to bring in 3rd-parties (besides shims).
sylvainpv 3573 days ago. link -1 point
Both React and Web Components are overrated in my opinion. React is 127KB, Web Components polyfill is 105KB. This is a huge overhead for clients just to solve problems that can be dealt with build tools on the developper side. I have seen many benchmarks on DOM manipulation here, but never heard a client complaining "Oh, this DOM is slow". The number one problem in web performance has always been network latency.
nickdima 3573 days ago. link 2 points
The point of React is not to speed up the DOM
sylvainpv 3570 days ago. link 1 point
what is the purpose of virtual DOM if not to speed up DOM manipulation ?
nickdima 3562 days ago. link 1 point
The virtual DOM is an implementation detail needed for performing render on every state change. The main feature of React is re-rendering everything when the state changes. Which would be impossible without a virtual DOM.
sylvainpv 3562 days ago. link 0 point
You don't need a virtual DOM to re-render everything when state changes. We did not wait for React nor Angular to write change detection algorithms. Virtual DOM is one of the techniques of data-binding, and presumed the best performing. A few milliseconds saved at rendering, tenths of a second lost at initial loading. Is it really worth it ?