Can someone explain to me why virtual DOM is faster than DOM implementations of browsers?
Netflix Likes React
31–40 of 60 posts
Re: Netflix Likes React
#32Earlier quoted context omitted.
I wouldn't choose Angular for a new project right now because it's in no man's land: 1.x is dead, 2.x is not available, and there's no path between the two. That said, Angular gets the job done. It scales better than people think it does (it's inefficient but modern browsers are just so fast it rarely matters) and it's a lot more complete than React. Angular is a full MVC framework while React is just about the V.
React has a better chance because it is a micro framework or component or just the V like you mentioned. Typical evolution of new tech is monolithic to micro, frameworks to components/modules/libraries. In the end micro frameworks or libraries allow more flexibility to change over time. Always bet on the micro frameworks and libraries, they can be swapped more easily and typically don't create blocks in overall archi…
React is quite large in terms of lines-of-code. I would refer to it as a mili-framework instead of a micro one :)
Re: Netflix Likes React
#33My experience says Netflix is spot on! Runtime performance, modularity, headless testing have been absolutely critical as we've thought about how to make a hyper-extendable email client on Atom Shell. Having a consistent component architecture has let us enable 3rd party applications that just seamlessly integrate with the rest of the core email client. Now with React Native, we might be able to do this with mobile s…
Any links on React Native?!
It was just announced at React.js Conf: https://news.ycombinator.com/item?id=8961551
Re: Netflix Likes React
#34Can someone explain to me why virtual DOM is faster than DOM implementations of browsers?
When I read the article I understood it to be that individual actual DOM operations are expensive compared to the virtual DOM. So, if you have N operations, if you apply them to the virtual DOM, and then do a diff, you may end up with M <= N operations one must apply to the actual DOM to do to get it to an equivalent state.
Re: Netflix Likes React
#35This is very interesting to see since I value Netflix's opinion. What's been holding me back was the pervasive JSX design. I know the react guys say that JSX is optional, but react without JSX seems cumbersome compared to, say, ember with handlebars. It'd be interesting to hear from Netflix on the topic of JSX if they are going to grow their react codebase. That being said, isomorphic javascript and using the vdom ar…
If you think React seems interesting but JSX is a turn-off (or in my team's case a total non-starter), you might want to check out Ractive, http://www.ractivejs.org/ . It uses some of the same ideas like a virtual DOM. Here's a writeup by Ractive's developer where he compares it to React: http://blog.ractivejs.org/posts/whats-the-difference-between...
I am fairly certain that Ractive templates are similar to JSX in terms of overhead.
If you don't like compiling JSX you can run it with the JSX client compiler at the cost of compiling it on every client.
Ractive templates are parsed in JS just like JSX, which is why you have ractive compilers like this
Re: Netflix Likes React
#36Earlier quoted context omitted.
Curious why JSX is a total non-starter? I've always been intrigued by things that completely invalidate ideas, regardless of how good those ideas appear to be. Is it just aesthetic (xml like)? Is it the precompiler? What is the harm with trying it out?
Boy, people never want to accept this. On my team, designers write the HTML. They own markup & styling. Designers don't want to dig through JS files to change markup, but an even bigger problem is that it's only kinda-sorta markup. For example, if you want to set a class on an element in JSX, it's not class="", it's className="". Because class is a reserved word in JS. How many other little warts like that are there,…
"How are they supposed to remember stuff like that?" Designers are never given enough credit. If they can handle all of the insanities of CSS (and various preprocessors), this will seem like cake.
Its just a single `render` method, generally living at the top or the bottom of a file; nothing complex.
Additionally, you stub out your static html markup first -- just like in a template -- and then you add interactivity. In an ideal world this always happens first.
It took our designer all of two minutes to learn the nuances of JSX -- className, that's it!
I would give it a shot, i'm sure they'll manage :)
Re: Netflix Likes React
#37This is very interesting to see since I value Netflix's opinion. What's been holding me back was the pervasive JSX design. I know the react guys say that JSX is optional, but react without JSX seems cumbersome compared to, say, ember with handlebars. It'd be interesting to hear from Netflix on the topic of JSX if they are going to grow their react codebase. That being said, isomorphic javascript and using the vdom ar…
If you think React seems interesting but JSX is a turn-off (or in my team's case a total non-starter), you might want to check out Ractive, http://www.ractivejs.org/ . It uses some of the same ideas like a virtual DOM. Here's a writeup by Ractive's developer where he compares it to React: http://blog.ractivejs.org/posts/whats-the-difference-between...
+1 for Ractive.js. The library is small and focused. It is trivial to integrate it to your application.
Re: Netflix Likes React
#38Earlier quoted context omitted.
If you think React seems interesting but JSX is a turn-off (or in my team's case a total non-starter), you might want to check out Ractive, http://www.ractivejs.org/ . It uses some of the same ideas like a virtual DOM. Here's a writeup by Ractive's developer where he compares it to React: http://blog.ractivejs.org/posts/whats-the-difference-between...
I am fairly certain that Ractive templates are similar to JSX in terms of overhead. If you don't like compiling JSX you can run it with the JSX client compiler at the cost of compiling it on every client. Ractive templates are parsed in JS just like JSX, which is why you have ractive compilers like this https://github.com/ractivejs/rv
I think the difference the OP mentioned is that Ractive templates are mustache-formatted strings, and can be stored in external files. So you have a JS file and a template file, not the combination of both you find in React.
Re: Netflix Likes React
#39Can someone explain to me why virtual DOM is faster than DOM implementations of browsers?
Actually changing the DOM has a lot of implications. Recalculating CSS, layout, possible side effects that generate events, repainting, etc, etc. It's a lot of work to go through for an intermediate state that may not even last long enough to be visible to the user. Buffering and batching those changes can save a lot of that effort. I suppose in theory the browser could optimize this as well but in practice it seems most are still optimized for rendering static pages very quickly rather than for handling rapid changes.
Re: Netflix Likes React
#40Earlier quoted context omitted.
I am fairly certain that Ractive templates are similar to JSX in terms of overhead. If you don't like compiling JSX you can run it with the JSX client compiler at the cost of compiling it on every client. Ractive templates are parsed in JS just like JSX, which is why you have ractive compilers like this https://github.com/ractivejs/rv
I think the difference the OP mentioned is that Ractive templates are mustache-formatted strings, and can be stored in external files. So you have a JS file and a template file, not the combination of both you find in React.
I don't think 16bytes said anything about any of that. React also uses mustache syntax.