Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

InfernoJS – A JavaScript library for building powerful user interfaces

infernojs.org

Post reply on HN
Print view View original

21–30 of 135 posts

Re: InfernoJS – A JavaScript library for building powerful user interfaces

#21

Post by mhd »

epmatsw wrote: post #14
chickenfries wrote: post #13

From the README > Inferno is much smaller in size, 7kb vs 45kb gzip. Given that you're building the kind of app that is complicated enough to require a state management library, a virtual dom implementation, etc... does this 38kb really matter? Is anyone really shipping commercial apps where 38kb on page load would be that meaningful of a performance gain? Especially if you're doing serverside rendering and requiring…

I assume the argument is going to be that on mobile the parsing time for 7kb of JS vs 45kb of JS is going to be significant.

And you might be able to avoid simultaneous client- and server-side rendering and all the horrors this brings with it in the first place.

Re: InfernoJS – A JavaScript library for building powerful user interfaces

#22

Post by untog »

chickenfries wrote: post #13

From the README > Inferno is much smaller in size, 7kb vs 45kb gzip. Given that you're building the kind of app that is complicated enough to require a state management library, a virtual dom implementation, etc... does this 38kb really matter? Is anyone really shipping commercial apps where 38kb on page load would be that meaningful of a performance gain? Especially if you're doing serverside rendering and requiring…

These days, JS parse time on mobile devices is more important than file size. And that isn't even necessarily file size specific - Nolan Lawson did a comparison of the different methods used to bundle JS to show how they can have a huge impact:

https://nolanlawson.com/2016/08/15/the-cost-of-small-modules...

Re: InfernoJS – A JavaScript library for building powerful user interfaces

#23

Post by _uhtu »

chickenfries wrote: post #13

From the README > Inferno is much smaller in size, 7kb vs 45kb gzip. Given that you're building the kind of app that is complicated enough to require a state management library, a virtual dom implementation, etc... does this 38kb really matter? Is anyone really shipping commercial apps where 38kb on page load would be that meaningful of a performance gain? Especially if you're doing serverside rendering and requiring…

I use React currently and yes, this is an important argument.

Faster load times are better. And if Inferno accomplishes better rendering speed while also being smaller, it is basically universally more performant than React.

I evaluated both thoroughly and chose React over Inferno because of the massive community around React, but numbers like this are intriguing.

Re: InfernoJS – A JavaScript library for building powerful user interfaces

#25

Post by masklinn »

iLoch wrote: post #18

Cool, so it's React but presumably they've stripped out many of the things that make React enjoyable to use in order to satisfy some arbitrary file size metric. Why isn't this library 1kb, like LatestHotFramework.js?

Reading the list of react differences, the biggest con is the lack of synthetic events, they plan on adding one but IME[0] that is pretty inconvenient as that means you need to handroll event delegation and dispatching, which means you need DOM access (via refs or componentDidMount) or will have to do all event dispatching from the root; and their devtools debugger is "still in development". They also require fairly modern ES features (maps and weakmaps).

OTOH it provides lifecycle events for functional (stateless) components which is nice.

[0] from having dealt with that when using snabbdom[1] without the event listener module

[1] which is a "raw" vdom library not a high-level components-oriented system

Re: InfernoJS – A JavaScript library for building powerful user interfaces

#26

Post by _uhtu »

iLoch wrote: post #18

Cool, so it's React but presumably they've stripped out many of the things that make React enjoyable to use in order to satisfy some arbitrary file size metric. Why isn't this library 1kb, like LatestHotFramework.js?

"but presumably they've stripped out many of the things that make React enjoyable to use in order to satisfy some arbitrary file size metric"

Why make this claim without looking yourself? You could validate that "presumably" by just looking at the docs, but instead you get sassy about it.

If you look at the docs, you'll see that the API is almost exactly the same. You really don't lose any features from switching to Inferno from React, what you lose is the React community.

I say this as an avid React user. Don't discredit something until after you've dove into it a bit.

Re: InfernoJS – A JavaScript library for building powerful user interfaces

#27

Post by bsilvereagle »

walid wrote: post #6
bsilvereagle wrote: post #3

Might as well link to the GH page (which is available by clicking the icon on the linked page): https://github.com/trueadm/inferno

Frankly I think this posting of github pages instead of the authorative source is inappropriate. I see it a lot on HN and find myself having to check that this is the official repo by going to the original website. If you know it you don't need to be told about it but if it's being posted to get it to people's attention then the canonical source is the right link even if it only has a link to github.

I can see the rationale behind linking to the original website, even if the UI isn't immediately apparent. However, the linked page is served via HTTP, so, depending on your threat vector, there isn't an authoritative source.

Re: InfernoJS – A JavaScript library for building powerful user interfaces

#28

Post by amelius »

untog wrote: post #22
chickenfries wrote: post #13

From the README > Inferno is much smaller in size, 7kb vs 45kb gzip. Given that you're building the kind of app that is complicated enough to require a state management library, a virtual dom implementation, etc... does this 38kb really matter? Is anyone really shipping commercial apps where 38kb on page load would be that meaningful of a performance gain? Especially if you're doing serverside rendering and requiring…

These days, JS parse time on mobile devices is more important than file size. And that isn't even necessarily file size specific - Nolan Lawson did a comparison of the different methods used to bundle JS to show how they can have a huge impact: https://nolanlawson.com/2016/08/15/the-cost-of-small-modules...

Still does 38kB really matter if the rest of your app requires parsing of several hundreds of kB of JS?

Re: InfernoJS – A JavaScript library for building powerful user interfaces

#29

Post by iLoch »

masklinn wrote: post #25
iLoch wrote: post #18

Cool, so it's React but presumably they've stripped out many of the things that make React enjoyable to use in order to satisfy some arbitrary file size metric. Why isn't this library 1kb, like LatestHotFramework.js?

Reading the list of react differences, the biggest con is the lack of synthetic events, they plan on adding one but IME[0] that is pretty inconvenient as that means you need to handroll event delegation and dispatching, which means you need DOM access (via refs or componentDidMount) or will have to do all event dispatching from the root; and their devtools debugger is "still in development". They also require fairly…

So basically, as the platform matures beyond a fun experiment, it'll grow in size. Got it. ;)

Re: InfernoJS – A JavaScript library for building powerful user interfaces

#30

Post by untog »

amelius wrote: post #28
untog wrote: post #22

Earlier quoted context omitted.

These days, JS parse time on mobile devices is more important than file size. And that isn't even necessarily file size specific - Nolan Lawson did a comparison of the different methods used to bundle JS to show how they can have a huge impact: https://nolanlawson.com/2016/08/15/the-cost-of-small-modules...

Still does 38kB really matter if the rest of your app requires parsing of several hundreds of kB of JS?

I think that if you're focused enough on performance to be looking at InfernoJS, the rest of your JS isn't hundreds of KB big.
Post reply on HN