What does isomorphic library mean in the context of Javascript ecosystem ?
Being able to run the same code both on the server side (nodejs) and the client side (browsers).
Inferno: A fast, React-like JavaScript library for building UIs
51–60 of 128 posts
Re: Inferno: A fast, React-like JavaScript library for building UIs
#52What is this solving?
It's solving performance issues that React and other virtual DOM libraries currently suffer. This is massively important for low power mobile devices. It's not an ego driven project, all research is going back into the open-source community to make better libraries and implementations inclusion React.
> It's solving performance issues that React and other virtual DOM libraries currently suffer.
But isn't "performances" the point of React? As I understand things, people were moving from AngularJS to React because the virtual DOM was supposed to be the most performant technique to handle UI mutation and rendering.
So what is the reality behind the supposed speed of React ?
Re: Inferno: A fast, React-like JavaScript library for building UIs
#53Still feel like we're talking past each other a bit here. Some portion of your UI logic is going to have to translate that data into the corresponding UI output, whether it be HTML elements or Android Views or iOS NSWhateverThingsTheyUse. With a virtual DOM, that's a two step process: your component is responsible for doing the "data -> desired UI structure" translation, and then the VDOM layer is responsible for tra…
Interesting. If you go to this user's comments, their other comments are from reddit as well. Possible way to farm karma by picking the top voted comment on reddit and reposting it onto HN? See: https://news.ycombinator.com/item?id=11837249 https://www.reddit.com/r/climateskeptics/comments/4kc1m8/por...
Strange, maybe it's a bot or something like that...
Re: Inferno: A fast, React-like JavaScript library for building UIs
#54What does isomorphic library mean in the context of Javascript ecosystem ?
Same code can run on the server too (node.js) not just in the browser, so it's possible to make search engine friendly page that can work even without client-side JavaScript.
Re: Inferno: A fast, React-like JavaScript library for building UIs
#55Quite honestly my problem with react is the gzipped size, not the performance. What's the size of the browser bundle of this library?
Re: Inferno: A fast, React-like JavaScript library for building UIs
#56Earlier quoted context omitted.
It's solving performance issues that React and other virtual DOM libraries currently suffer. This is massively important for low power mobile devices. It's not an ego driven project, all research is going back into the open-source community to make better libraries and implementations inclusion React.
> It's solving performance issues that React and other virtual DOM libraries currently suffer. But isn't "performances" the point of React? As I understand things, people were moving from AngularJS to React because the virtual DOM was supposed to be the most performant technique to handle UI mutation and rendering. So what is the reality behind the supposed speed of React ?
React can be fast but is the slowest amongst pretty much every virtualdom libraries
Re: Inferno: A fast, React-like JavaScript library for building UIs
#57I like how javascripters use `const` everywhere they can except actual constants!
https://github.com/trueadm/inferno/blob/master/src/DOM/mount...
Re: Inferno: A fast, React-like JavaScript library for building UIs
#58I'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.
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.
Re: Inferno: A fast, React-like JavaScript library for building UIs
#59Earlier quoted context omitted.
It's solving performance issues that React and other virtual DOM libraries currently suffer. This is massively important for low power mobile devices. It's not an ego driven project, all research is going back into the open-source community to make better libraries and implementations inclusion React.
> It's solving performance issues that React and other virtual DOM libraries currently suffer. But isn't "performances" the point of React? As I understand things, people were moving from AngularJS to React because the virtual DOM was supposed to be the most performant technique to handle UI mutation and rendering. So what is the reality behind the supposed speed of React ?
Performance is not the point of React. Predictability is. Bunches of bugs are eliminated and others are easier to find.
Re: Inferno: A fast, React-like JavaScript library for building UIs
#60Earlier quoted context omitted.
It's solving performance issues that React and other virtual DOM libraries currently suffer. This is massively important for low power mobile devices. It's not an ego driven project, all research is going back into the open-source community to make better libraries and implementations inclusion React.
> It's solving performance issues that React and other virtual DOM libraries currently suffer. But isn't "performances" the point of React? As I understand things, people were moving from AngularJS to React because the virtual DOM was supposed to be the most performant technique to handle UI mutation and rendering. So what is the reality behind the supposed speed of React ?
I can't make comparisons to Angular as I've never used that library. However, the point of React and the many virtual DOM libraries like it is to simplify UI code.
You write a function that takes the current model state and returns the DOM tree that should be displayed in that state. If you want to change something on the UI, you swap in a new state and the whole thing is re-rendered -- at least that's the abstraction.
It's a programming model that's easy to understand and hard to get wrong. That's the great thing about it! The bad thing about it is that if you implemented it naively, by actually re-rendering all the HTML for your single-page app on every state change, the performance would be awful.
Virtual DOM diffing is a solution to that performance problem, and it makes applications written this way perform adequately. You can't read about React without the DOM diffing being mentioned, and library authors love to compare benchmarks, so it's easy to see virtual DOM as the feature. It's just a means to an end though.