Live data from Hacker News

Inferno: A fast, React-like JavaScript library for building UIs

github.com

81–90 of 128 posts

Re: Inferno: A fast, React-like JavaScript library for building UIs

#81
post #59

Earlier quoted context omitted.

Performance is not the point of React. Predictability is. Bunches of bugs are eliminated and others are easier to find.

> Bunches of bugs are eliminated and others are easier to find. Got a link to the research for that? My pet peeve is unsubstantiated bullshit claims. We let sooooo much nonsense fly, especially in JS land.

I don't know if Facebook has done any formal studies. Here's one way to think about it: if you have a webapp and have state in JS objects that you have to synchronize with the DOM, that generally takes a fair bit of code. React provided an approach for eliminating synchronization code entirely.

My own experience and that of the many others that created webapps pre-React and then adopted it is that its model simplifies our work and removes bugs. That's why we use it. It's also why there are a bunch of other vdom libraries and Ember and Angular have both moved toward similar one-way data flow models.

There's a lot that we do day-to-day that doesn't have research to back it up. At some point, we have to try things out for ourselves to see how they work for us.

Re: Inferno: A fast, React-like JavaScript library for building UIs

#82
post #46

What is the difference comparing to vuejs?

One major difference being that Vue.js doesn't really quite support TypeScript even with d.ts files provided. It will work only to a point until things fail to typecheck due to generative aspects of Vue's API.[1]

I think a useful comparison is taking a look at t7[2], trueadm's template library. Last I knew, it wasn't ready for use with Inferno yet, but that is a peek at the direction it is heading. It's rather similar to Vue's templates minus the v-directives magic in favor of leveraging JS for things like control flow.

I'm not 100% sure I'm sold on it, myself, as I rather like beating out Vue templates in Jade rather than doing everything in JavaScript with template strings. That being said, I haven't directly tried to implement anything with Inferno or t7 yet to turn in an informed opinion on working with it.

Inferno is one of the few other library than Vue I'd even bother looking at, however, at this point in time. They both aren't horribly bloated, are rather quick and have a mostly sane model to work with. Cito.js[3] is also interesting and works with t7, if you're looking for even less frills.

It is also worth noting that if you care about licenses, Vue is MIT and Cito.js and Inferno are using a much more heavily restrictive license, MPL 2.0, which will matter if you're a commercial developer doing standalone apps. For this reason alone I have to throw Inferno and Cito.js into the trash at work.

[1]: https://github.com/vuejs/vue/issues/478

[2]: https://github.com/trueadm/t7

[3]: https://github.com/joelrich/citojs

Re: Inferno: A fast, React-like JavaScript library for building UIs

#83
post #73
post #58

Earlier quoted context omitted.

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.

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…

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.

Re: Inferno: A fast, React-like JavaScript library for building UIs

#84
post #32

We were previously using RiotJs in our company. We are building huge single page application and recently moved to InfernoJS. Results have been amazing. RiotJs used to BE lagging a lot (It simply could not handle 3000 components in same way) It had really long (50ms) delays everywhere. After moving to Inferno following things have improved: -We are unit testing components -Performance!!! (No delays/lagging anymore) -…

Benefit I saw to Riot was that my app's minimized size was one third what it was with React. And not to mention RiotJS was so much simpler than React...

Re: Inferno: A fast, React-like JavaScript library for building UIs

#85
post #46

What is the difference comparing to vuejs?

One major difference being that Vue.js doesn't really quite support TypeScript even with d.ts files provided. It will work only to a point until things fail to typecheck due to generative aspects of Vue's API.[1] I think a useful comparison is taking a look at t7[2], trueadm's template library. Last I knew, it wasn't ready for use with Inferno yet, but that is a peek at the direction it is heading. It's rather simila…

Thanks and this is very insightful. Yes it looks like typescript will be an essential part of the js-ecosystem sooner than expected.

Re: Inferno: A fast, React-like JavaScript library for building UIs

#86
post #69

At the risk of beating a dead horse, we are only fueling the flames of javascript fatigue by churning out these "It's like X, but with more/less cowbell" libraries. We need to stop fragmenting and start doubling down on existing libraries.

Alternatively we need to start making optional frameworks. Essentially a way to do many of the usual things you use a framework for (like model binding) but will work, without changing the code, when using just about any framework.

I hate taking the basic things that are not hugely different in concept and workflow but end up using very different code so I can't port it between frameworks. Working on the start of this in my msngr.js library (shameless plug) because I would like to use it but also because I think it's important.

A new framework every couple of weeks is daunting but okay. Not being able to reuse code between them is awful.

Re: Inferno: A fast, React-like JavaScript library for building UIs

#87

Shameless plug, I know, but I bet Inferno doesn't come close to my latest framework when it comes to the notorious task of writing a TODO app: https://github.com/ErikWittern/TODOit

i saw this come up yesterday on reddit and asked myself if this was joke. 70 lines of code is a lot of code? i don't get it :/ I'm asking this as the author of domvm [1] and a 60 LOC todo implementation [2] that also exposes a usable API. [1] https://github.com/leeoniya/domvm [2] https://leeoniya.github.io/domvm/demos/todo-alt.html

Gotta be a joke, right?

Re: Inferno: A fast, React-like JavaScript library for building UIs

#89
post #59

Earlier quoted context omitted.

Performance is not the point of React. Predictability is. Bunches of bugs are eliminated and others are easier to find.

> Bunches of bugs are eliminated and others are easier to find. Got a link to the research for that? My pet peeve is unsubstantiated bullshit claims. We let sooooo much nonsense fly, especially in JS land.

Anecdotally I can certainly back this up from my own experience. My React based UIs are so much easier to build and maintain than the jQuery stuff they replaced.

Re: Inferno: A fast, React-like JavaScript library for building UIs

#90
post #32

We were previously using RiotJs in our company. We are building huge single page application and recently moved to InfernoJS. Results have been amazing. RiotJs used to BE lagging a lot (It simply could not handle 3000 components in same way) It had really long (50ms) delays everywhere. After moving to Inferno following things have improved: -We are unit testing components -Performance!!! (No delays/lagging anymore) -…

> It simply could not handle 3000 components in same way Can you elaborate? Do you mean 3000 simultaneously in the DOM? Is this a grid/table where each cell is a component or something else?

> Do you mean 3000 simultaneously in the DOM?

I'm not OP, but they said "We are building huge single page application"

For SPAs, it is not uncommon to use CSS to hide multiple controls (or what would otherwise be entire pages) from the user but leave it in the DOM so you can reveal them as needed. Deciding to hide a DOM subtree vs destroying & rebuilding is a performance balancing act.

Post reply on HN