11 ms·

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

184 points by trueadm 10y ago

amelius 10y ago
But does it have something similar to React Native?
- formula1 10y ago
  This was a problem I was trying to solve as well and theres a pretty elegent solution that this project has implemented partly already. The "render to string" is also a proof of concept that the indicates "unknown" types can be fullfilled by a "renderer". So long as he allows generic "renderers". Within a more free form environment like nativescript[ 1], this library can be one of any that can be used. I was planning to implement blessed and nativescript uis but these can often be very painstaking tasks. If the developers on this project are committed, the sky is the limit! [1] https://www.nativescript.org https://www.nativescript.org
  - Drdrdrq 10y ago
    I didn't know about nativescript before, thanks for bringing it to my attention! That said, it looks like nativescript promotes single code for multiple platform, which means the app won't look awesome in any of them (examples from history: phonegap, java awt). I would be much more comfortable with it if I could just use JS to access native controls and style them using the established (platform specific) methods. I am guessing css will never support each and every widget property... Is this approach possible with nativescript?
    - formula1 10y ago
      Tbh, Im very early in my nativescript experiences (though I do believe in the project). But I believe these are some examples you are looking for http://docs.nativescript.org/ui/placeholder http://docs.nativescript.org/ui/placeholder http://docs.nativescript.org/core-concepts/accessing-native-apis-with-javascript http://docs.nativescript.org/core-concepts/accessing-native-... http://docs.nativescript.org/runtimes/ios/marshalling/Marshalling-Overview.html http://docs.nativescript.org/runtimes/ios/marshalling/Marsha... http://docs.nativescript.org/runtimes/android/marshalling/overview.html http://docs.nativescript.org/runtimes/android/marshalling/ov... http://docs.nativescript.org/plugins/plugins http://docs.nativescript.org/plugins/plugins
formula1 10y ago
https://github.com/formula1/tEmbO?files=1 https://github.com/formula1/tEmbO?files=1 Was doing something similar for a while. Very cool stuff! Excited to see where you take it!
hackim 10y ago
Interesting...
padseeker 10y ago
Respect for building something on your own. It's just that I don't know if what the world needs is another javascript framework.
- elliotec 10y ago
  Critical mass has to be coming soon with JS churn, right?
  - gedy 10y ago
    Thing is, that's the equivalent to saying "Critical mass _has_ to be coming soon with graphics rendering" - what exactly do we expect from critical mass, something like Xcode for iOS? The Browser is a multitude of runtime UI/network environments with rapidly increasing capabilities. The "frameworks" are basically different abstractions of their capabilities. They are easy to make, and match whatever abstraction the writer's prefer. I personally dislike React, so am glad it's not "the one" and glad that their are options.
- formula1 10y ago
  The fact is that React is extrodinaitilly bloated, you can only have one instance in a single environment and you are highly dependent on using libraries that are forks in order to target new environments (like native, blessed or rbg). React isnt some God given wheel that needs no fixing. Competition is a great thing to have
Keats 10y ago
It's still in progress but it gets better on each release. Even better that the new version is using TypeScript!
- trueadm 10y ago
  TypeScript not only helped improve Inferno's with quality and read-ability of code. It can potentially help produce highly optimal output (bundles) with Google's Closure Compiler. In the future it may even help created optimised WebAssembly output. It's an exciting time :)
  - nippur72 10y ago
    I've just opened the GitHub repo and I see no trace of TypeScript, no .ts files anywhere
    - deleted 10y ago
      [deleted]
    - timdorr 10y ago
      Wrong branch. Check 0.8-dev: https://github.com/trueadm/inferno/tree/0.8-dev/src https://github.com/trueadm/inferno/tree/0.8-dev/src
      - nippur72 10y ago
        fine, thanks. TypeScript makes it even more interesting. I am going to make some tests to see if Inferno can replace React when working with react-templates.
elliotec 10y ago
What is this solving?
- trueadm 10y ago
  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.
  - spriggan3 10y ago
    > 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 ?
    - Keats 10y ago
      React can be fast but is the slowest amongst pretty much every virtualdom libraries
    - dangoor 10y ago
      Performance is not the point of React. Predictability is. Bunches of bugs are eliminated and others are easier to find.
      - deckard1 10y ago
        > 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.
        10y ago
marshalltony 10y ago
Someone's ego
- bastijn 10y ago
  If you have nothing to say then don't. @original question. Did you read the github? It is clearly stated what the intentions are. Mainly performance related achieved through being able to only diff renders that have dynamic values. So if you are having trouble with performance and are pretty sure it's not your code but the framework, inferno might solve it.
- dang 10y ago
  Please don't comment like this here! HN comments need to be civil and substantive—especially in response to new work, which is so easy to dismiss. And personal attacks are right out. We detached this from https://news.ycombinator.com/item?id=11837303 https://news.ycombinator.com/item?id=11837303 and marked it off-topic.
edoceo 10y ago
Would like to see comparison to RiotJS
sedeki 10y ago
This is the second time trueadm posted this. Not sure what you're trying to prove? Mind answering this?
- elliotec 10y ago
  Trying to prove that you can get on the top of Hacker News with yet another flavor du jour JavaScript framework, even if it takes two tries?
- trueadm 10y ago
  Trying to prove? I'm trying to get feedback and input on this project. Any feedback is good :)
  - tptacek 10y ago
    The vitriol on this thread is surprising and disappointing, but I can reassure you that it's also uninformed: re-posting things that have received little or no discussion, after some decent interval, is a norm on HN and is encouraged. It would be a bad idea to post this story again in another month, but your last post got no comments at all, so this is presumably totally legit.
  - hartpuff 10y ago
    It's somewhat ironic that your comment was also posted twice. :) FWIW, I don't disapprove of you submitting this twice. I, like most people, did not see the original submission, so why not.
  - dang 10y ago
    tptacek is right: totally legit. From https://news.ycombinator.com/newsfaq.html https://news.ycombinator.com/newsfaq.html: Are reposts ok? If a story has had significant attention in the last year or so, we kill reposts as duplicates. If not, a small number of reposts is ok. The reason is that there's so much randomness in what gets seen on /newest and thus gets a chance at the front page. Allowing a few rolls of the dice is a way of mitigating that randomness and increasing the best posts' chance at getting attention, which is a top priority here. So we don't penalize reposts as dupes until that happens. Edit: please don't take the pushback personally. JavaScript fatigue and framework fatigue have become trends over the last year or so. That's probably why the discussion is a bit more cranky than the median. Criticisms like 'ego' are totally out of line; neutral questions like "What problem does this solve" are of course fine.
Renner1 10y ago
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.
- shados 10y ago
  API compatible or near compatible drop in replacements are a good thing though. The way we can have new things without needing to rewrite everything. The only issue with this one is the lack of context API, which is needed for a lot of third party integrations, like react-redux. If it wasn't for that, it wouldn't be a problem at all.
  - merrywhether 10y ago
    > it wouldn't be a problem at all I have trouble believing this is true in the long-run. There are several examples that seem contrary to this idea. Lodash was supposed to be a drop-in replacement for underscore, and that was fine and all until contributors felt like they had to duplicate any new features into both libraries. On the bright side, this lead to their upcoming merger, but not without years of wasted effort duplicating work and ink spilled arguing over which was better. You could argue that underscore could have been more willing to merge in more-performant implementations (though I think they preferred readability over speed), but it seems like this fork-first mentality in the JS world somehow makes that almost looked down upon. Others like Zepto or other jQuery-alikes seem to reach moderate uptake at best but don't necessarily move the community forward either. Ultimately it seems like the best you can hope for is to get enough attention / stir up enough of a hornet's nest / make dual-contributors lives hard enough to then get merged back in to the original library, and it seems like this is much more pronounced in the JS community[0]. But looking at Node vs IO, CoffeeScript vs JS, or other like-X-but-better situations[1], it sure seems like more community input into and improvement of the already existing frameworks would go a long way. 0: I'm totally willing to admit that JS is one of the things I spend more time doing so I just might notice it more. 1: I know there are nuances to these situations, but I'm being a little reductionist, and they were still stand up to the point.
  - 10y ago
Ghostium 10y ago
"Non-performant features have been removed or replaced where an alternative solution is easy to adopt without too many changes." Sound for me like preact (https://github.com/developit/preact https://github.com/developit/preact)
- k__ 10y ago
  Same API as react? sounds nice. What did they left out?
  - thiswasprobably 10y ago
    "but only the modern (ES6 Classes and stateless functional components) interfaces"
    - k__ 10y ago
      Seems nice. Cut down my JS size by 50%
jyriand 10y ago
Any specific reason it is called Inferno? Somehow I can't stop thinking that after Inferno comes Purgatorio and Paradiso.
- ajro 10y ago
  And the name is already taken: https://en.wikipedia.org/wiki/Inferno_(operating_system) https://en.wikipedia.org/wiki/Inferno_(operating_system)
  - trueadm 10y ago
    React was also taken before Facebook used it. It's not an issue in my eyes. Inferno was used to emphasise performance and power.
Harry101 10y ago
Still 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 translating that into the actual UI pieces. If you've got {likes : 42}, React has no idea what a "like" is, what it means to have 42 of them, or what it should do with that information. Your code has to tell it what that means in terms of something to actually draw.
- acemarke 10y ago
  Erm. That... is a comment that _I_ made, a couple days ago, in a Reddit thread where someone was asking about trying to diff data instead of the VDOM. Why are you pasting it here? https://www.reddit.com/r/javascript/comments/4m1w6a/an_extremely_fast_reactlike_javascript_library/d3sg1v7?context=3 https://www.reddit.com/r/javascript/comments/4m1w6a/an_extre...
  - paulddraper 10y ago
    ...sincerest form of flattery?
- ipsum2 10y ago
  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://news.ycombinator.com/item?id=11837249 https://www.reddit.com/r/climateskeptics/comments/4kc1m8/portland_school_board_bans_climate_changedenying/d3ecqrc https://www.reddit.com/r/climateskeptics/comments/4kc1m8/por...
  - acemarke 10y ago
    I guess? What's weird is that while my comment is decently written, it's not like it particularly racked up much karma on Reddit to begin with (a whopping 3 points atm), the topic of VDOM management is not likely to be a huge hotbed of upvotes anyway, and the fact that I was replying to someone else to begin with means that just dropping it in here obviously makes it read very awkwardly. Strange.
Havunen 10y ago
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) -es2015 syntax with JSX and inheritance -Intellisense support in IDEs (webstorm) no custom riot syntax - Future proof syntax without worrying low level API changes Negative things: -It took for a while to recode all our components in JSX --Havunen
- leeoniya 10y ago
  > 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?
  - sangnoir 10y ago
    > 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.
- Roritharr 10y ago
  What do you consider huge? Maybe we're just slow, but we recently estimated that rewriting and launching our whole frontend in another js Framework would take a dedicated 3 Person Team atleast a year, how do you explain this cost to someone with financial responsibility, I mean the benefits are probably great, but THAT great?
  - shados 10y ago
    The alternative, depending on your market segment, is your competitor do it and you don't, they fall behind for a little bit, your sales grow. Then their version comes out, faster and better, and their dev team iterates faster, eventually catching up and leaves you in the dust. I've seen it happen...very recently, in a situation that ended up in large layoffs. It doesn't have to be all or nothing though. These libs are easy to keep around side by side, so you can slowly rewrite stuff as you add new features until the transition is complete.
ewittern 10y ago
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 https://github.com/ErikWittern/TODOit
- leeoniya 10y ago
  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 https://github.com/leeoniya/domvm [2] https://leeoniya.github.io/domvm/demos/todo-alt.html https://leeoniya.github.io/domvm/demos/todo-alt.html
  - ewittern 10y ago
    Everything is relative. Like 60 lines of code (especially as compared to a single one). Or humor.
  - claymullis 10y ago
    Gotta be a joke, right?
ausjke 10y ago
What is the difference comparing to vuejs?
- JSQuagmire 10y ago
  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 https://github.com/vuejs/vue/issues/478 [2]: https://github.com/trueadm/t7 https://github.com/trueadm/t7 [3]: https://github.com/joelrich/citojs https://github.com/joelrich/citojs
  - ausjke 10y ago
    Thanks and this is very insightful. Yes it looks like typescript will be an essential part of the js-ecosystem sooner than expected.
  - rpwverheij 10y ago
    ah thank you for the summary of the licences. that moves inferno off the table for me too. sadly though, cause I was really getting interested with it being written in typescript.
z3t4 10y ago
I'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.
- dangoor 10y ago
  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.
  - pygy_ 10y ago
    You also want to batch your DOM manipulations as much as possible, and you get it automatically by using vDOM libraries.
  - z3t4 10y ago
    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 whole app! Like when the next JS fashion/framework comes. grin
    - dangoor 10y ago
      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.
    - davidpatrick 10y ago
psibi 10y ago
What does isomorphic library mean in the context of Javascript ecosystem ?
- deleted 10y ago
  [deleted]
- ghh 10y ago
  Being able to run the same code both on the server side (nodejs) and the client side (browsers).
- spyder 10y ago
  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.
tacone 10y ago
Quite honestly my problem with react is the gzipped size, not the performance. What's the size of the browser bundle of this library?
- leeoniya 10y ago
  it's quite small (20k min). i think the two main deps needed are: https://github.com/trueadm/inferno/blob/master/packages/inferno/dist/inferno.min.js https://github.com/trueadm/inferno/blob/master/packages/infe... https://github.com/trueadm/inferno/blob/master/packages/inferno/dist/inferno-dom.min.js https://github.com/trueadm/inferno/blob/master/packages/infe...
- xaduha 10y ago
  Look into preact + buble ES2015 compiler then, should be small enough https://github.com/developit/preact https://github.com/developit/preact https://gitlab.com/Rich-Harris/buble https://gitlab.com/Rich-Harris/buble my app.min.js.gz is 6.2K for some basic stuff including preact-router https://github.com/developit/preact-router https://github.com/developit/preact-router
dyscrete 10y ago
I like how javascripters use `const` everywhere they can except actual constants! https://github.com/trueadm/inferno/blob/master/src/DOM/mounting.js#L65 https://github.com/trueadm/inferno/blob/master/src/DOM/mount...
aeosynth 10y ago
> Inferno uses intelligent techniques to separate static and dynamic content. This allows Inferno to only "diff" renders that have dynamic values. Can this be expanded? If/when the intelligent diffing fails, I'd like to know how to fix it.
ben_jones 10y ago
React, so great people are already re-writing it.
CognitiveLens 10y ago
Events + callbacks are great for keeping with the conventions of the existing (ancient) DOM APIs, but I was hoping that a new, 'modern' framework would be a little more ambitious by making everything promise-based.
shiftoutbox 10y ago
So who will be the ass hat who makes plan9 the js library , that like inferno but with ....
FLGMwt 10y ago
As a curiosity, how do we feel about changing the names of the lifecycle methods from "lifeCycleEvent" to "onLifecycleEvent"? Looks like a lot of stuff is pretty transparently portable from React code, I think it's curious this got changed.

184 points by trueadm 10y ago

amelius 10y ago

But does it have something similar to React Native?

formula1 10y ago
This was a problem I was trying to solve as well and theres a pretty elegent solution that this project has implemented partly already. The "render to string" is also a proof of concept that the indicates "unknown" types can be fullfilled by a "renderer". So long as he allows generic "renderers". Within a more free form environment like nativescript[ 1], this library can be one of any that can be used. I was planning to implement blessed and nativescript uis but these can often be very painstaking tasks. If the developers on this project are committed, the sky is the limit! [1] https://www.nativescript.org https://www.nativescript.org
- Drdrdrq 10y ago
  I didn't know about nativescript before, thanks for bringing it to my attention! That said, it looks like nativescript promotes single code for multiple platform, which means the app won't look awesome in any of them (examples from history: phonegap, java awt). I would be much more comfortable with it if I could just use JS to access native controls and style them using the established (platform specific) methods. I am guessing css will never support each and every widget property... Is this approach possible with nativescript?
  - formula1 10y ago
    Tbh, Im very early in my nativescript experiences (though I do believe in the project). But I believe these are some examples you are looking for http://docs.nativescript.org/ui/placeholder http://docs.nativescript.org/ui/placeholder http://docs.nativescript.org/core-concepts/accessing-native-apis-with-javascript http://docs.nativescript.org/core-concepts/accessing-native-... http://docs.nativescript.org/runtimes/ios/marshalling/Marshalling-Overview.html http://docs.nativescript.org/runtimes/ios/marshalling/Marsha... http://docs.nativescript.org/runtimes/android/marshalling/overview.html http://docs.nativescript.org/runtimes/android/marshalling/ov... http://docs.nativescript.org/plugins/plugins http://docs.nativescript.org/plugins/plugins

formula1 10y ago

https://github.com/formula1/tEmbO?files=1 https://github.com/formula1/tEmbO?files=1 Was doing something similar for a while. Very cool stuff! Excited to see where you take it!

hackim 10y ago

Interesting...

padseeker 10y ago

Respect for building something on your own. It's just that I don't know if what the world needs is another javascript framework.

elliotec 10y ago
Critical mass has to be coming soon with JS churn, right?
- gedy 10y ago
  Thing is, that's the equivalent to saying "Critical mass _has_ to be coming soon with graphics rendering" - what exactly do we expect from critical mass, something like Xcode for iOS? The Browser is a multitude of runtime UI/network environments with rapidly increasing capabilities. The "frameworks" are basically different abstractions of their capabilities. They are easy to make, and match whatever abstraction the writer's prefer. I personally dislike React, so am glad it's not "the one" and glad that their are options.
formula1 10y ago
The fact is that React is extrodinaitilly bloated, you can only have one instance in a single environment and you are highly dependent on using libraries that are forks in order to target new environments (like native, blessed or rbg). React isnt some God given wheel that needs no fixing. Competition is a great thing to have

Keats 10y ago

It's still in progress but it gets better on each release. Even better that the new version is using TypeScript!

trueadm 10y ago
TypeScript not only helped improve Inferno's with quality and read-ability of code. It can potentially help produce highly optimal output (bundles) with Google's Closure Compiler. In the future it may even help created optimised WebAssembly output. It's an exciting time :)
- nippur72 10y ago
  I've just opened the GitHub repo and I see no trace of TypeScript, no .ts files anywhere
  - deleted 10y ago
    [deleted]
  - timdorr 10y ago
    Wrong branch. Check 0.8-dev: https://github.com/trueadm/inferno/tree/0.8-dev/src https://github.com/trueadm/inferno/tree/0.8-dev/src
    - nippur72 10y ago
      fine, thanks. TypeScript makes it even more interesting. I am going to make some tests to see if Inferno can replace React when working with react-templates.

elliotec 10y ago

What is this solving?

trueadm 10y ago
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.
- spriggan3 10y ago
  > 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 ?
  - Keats 10y ago
    React can be fast but is the slowest amongst pretty much every virtualdom libraries
  - dangoor 10y ago
    Performance is not the point of React. Predictability is. Bunches of bugs are eliminated and others are easier to find.
    - deckard1 10y ago
      > 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.
      - 10y ago

marshalltony 10y ago

Someone's ego

bastijn 10y ago
If you have nothing to say then don't. @original question. Did you read the github? It is clearly stated what the intentions are. Mainly performance related achieved through being able to only diff renders that have dynamic values. So if you are having trouble with performance and are pretty sure it's not your code but the framework, inferno might solve it.
dang 10y ago
Please don't comment like this here! HN comments need to be civil and substantive—especially in response to new work, which is so easy to dismiss. And personal attacks are right out. We detached this from https://news.ycombinator.com/item?id=11837303 https://news.ycombinator.com/item?id=11837303 and marked it off-topic.

edoceo 10y ago

Would like to see comparison to RiotJS

sedeki 10y ago

This is the second time trueadm posted this. Not sure what you're trying to prove? Mind answering this?

elliotec 10y ago
Trying to prove that you can get on the top of Hacker News with yet another flavor du jour JavaScript framework, even if it takes two tries?
trueadm 10y ago
Trying to prove? I'm trying to get feedback and input on this project. Any feedback is good :)
- tptacek 10y ago
  The vitriol on this thread is surprising and disappointing, but I can reassure you that it's also uninformed: re-posting things that have received little or no discussion, after some decent interval, is a norm on HN and is encouraged. It would be a bad idea to post this story again in another month, but your last post got no comments at all, so this is presumably totally legit.
- hartpuff 10y ago
  It's somewhat ironic that your comment was also posted twice. :) FWIW, I don't disapprove of you submitting this twice. I, like most people, did not see the original submission, so why not.
- dang 10y ago
  tptacek is right: totally legit. From https://news.ycombinator.com/newsfaq.html https://news.ycombinator.com/newsfaq.html: Are reposts ok? If a story has had significant attention in the last year or so, we kill reposts as duplicates. If not, a small number of reposts is ok. The reason is that there's so much randomness in what gets seen on /newest and thus gets a chance at the front page. Allowing a few rolls of the dice is a way of mitigating that randomness and increasing the best posts' chance at getting attention, which is a top priority here. So we don't penalize reposts as dupes until that happens. Edit: please don't take the pushback personally. JavaScript fatigue and framework fatigue have become trends over the last year or so. That's probably why the discussion is a bit more cranky than the median. Criticisms like 'ego' are totally out of line; neutral questions like "What problem does this solve" are of course fine.

Renner1 10y ago

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.

shados 10y ago
API compatible or near compatible drop in replacements are a good thing though. The way we can have new things without needing to rewrite everything. The only issue with this one is the lack of context API, which is needed for a lot of third party integrations, like react-redux. If it wasn't for that, it wouldn't be a problem at all.
- merrywhether 10y ago
  > it wouldn't be a problem at all I have trouble believing this is true in the long-run. There are several examples that seem contrary to this idea. Lodash was supposed to be a drop-in replacement for underscore, and that was fine and all until contributors felt like they had to duplicate any new features into both libraries. On the bright side, this lead to their upcoming merger, but not without years of wasted effort duplicating work and ink spilled arguing over which was better. You could argue that underscore could have been more willing to merge in more-performant implementations (though I think they preferred readability over speed), but it seems like this fork-first mentality in the JS world somehow makes that almost looked down upon. Others like Zepto or other jQuery-alikes seem to reach moderate uptake at best but don't necessarily move the community forward either. Ultimately it seems like the best you can hope for is to get enough attention / stir up enough of a hornet's nest / make dual-contributors lives hard enough to then get merged back in to the original library, and it seems like this is much more pronounced in the JS community[0]. But looking at Node vs IO, CoffeeScript vs JS, or other like-X-but-better situations[1], it sure seems like more community input into and improvement of the already existing frameworks would go a long way. 0: I'm totally willing to admit that JS is one of the things I spend more time doing so I just might notice it more. 1: I know there are nuances to these situations, but I'm being a little reductionist, and they were still stand up to the point.
- 10y ago

Ghostium 10y ago

"Non-performant features have been removed or replaced where an alternative solution is easy to adopt without too many changes." Sound for me like preact (https://github.com/developit/preact https://github.com/developit/preact)

k__ 10y ago
Same API as react? sounds nice. What did they left out?
- thiswasprobably 10y ago
  "but only the modern (ES6 Classes and stateless functional components) interfaces"
  - k__ 10y ago
    Seems nice. Cut down my JS size by 50%

jyriand 10y ago

Any specific reason it is called Inferno? Somehow I can't stop thinking that after Inferno comes Purgatorio and Paradiso.

ajro 10y ago
And the name is already taken: https://en.wikipedia.org/wiki/Inferno_(operating_system) https://en.wikipedia.org/wiki/Inferno_(operating_system)
- trueadm 10y ago
  React was also taken before Facebook used it. It's not an issue in my eyes. Inferno was used to emphasise performance and power.

Harry101 10y ago

Still 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 translating that into the actual UI pieces. If you've got {likes : 42}, React has no idea what a "like" is, what it means to have 42 of them, or what it should do with that information. Your code has to tell it what that means in terms of something to actually draw.

acemarke 10y ago
Erm. That... is a comment that _I_ made, a couple days ago, in a Reddit thread where someone was asking about trying to diff data instead of the VDOM. Why are you pasting it here? https://www.reddit.com/r/javascript/comments/4m1w6a/an_extremely_fast_reactlike_javascript_library/d3sg1v7?context=3 https://www.reddit.com/r/javascript/comments/4m1w6a/an_extre...
- paulddraper 10y ago
  ...sincerest form of flattery?
ipsum2 10y ago
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://news.ycombinator.com/item?id=11837249 https://www.reddit.com/r/climateskeptics/comments/4kc1m8/portland_school_board_bans_climate_changedenying/d3ecqrc https://www.reddit.com/r/climateskeptics/comments/4kc1m8/por...
- acemarke 10y ago
  I guess? What's weird is that while my comment is decently written, it's not like it particularly racked up much karma on Reddit to begin with (a whopping 3 points atm), the topic of VDOM management is not likely to be a huge hotbed of upvotes anyway, and the fact that I was replying to someone else to begin with means that just dropping it in here obviously makes it read very awkwardly. Strange.

Havunen 10y ago

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) -es2015 syntax with JSX and inheritance -Intellisense support in IDEs (webstorm) no custom riot syntax - Future proof syntax without worrying low level API changes Negative things: -It took for a while to recode all our components in JSX --Havunen

leeoniya 10y ago
> 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?
- sangnoir 10y ago
  > 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.
Roritharr 10y ago
What do you consider huge? Maybe we're just slow, but we recently estimated that rewriting and launching our whole frontend in another js Framework would take a dedicated 3 Person Team atleast a year, how do you explain this cost to someone with financial responsibility, I mean the benefits are probably great, but THAT great?
- shados 10y ago
  The alternative, depending on your market segment, is your competitor do it and you don't, they fall behind for a little bit, your sales grow. Then their version comes out, faster and better, and their dev team iterates faster, eventually catching up and leaves you in the dust. I've seen it happen...very recently, in a situation that ended up in large layoffs. It doesn't have to be all or nothing though. These libs are easy to keep around side by side, so you can slowly rewrite stuff as you add new features until the transition is complete.

ewittern 10y ago

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 https://github.com/ErikWittern/TODOit

leeoniya 10y ago
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 https://github.com/leeoniya/domvm [2] https://leeoniya.github.io/domvm/demos/todo-alt.html https://leeoniya.github.io/domvm/demos/todo-alt.html
- ewittern 10y ago
  Everything is relative. Like 60 lines of code (especially as compared to a single one). Or humor.
- claymullis 10y ago
  Gotta be a joke, right?

ausjke 10y ago

What is the difference comparing to vuejs?

JSQuagmire 10y ago
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 https://github.com/vuejs/vue/issues/478 [2]: https://github.com/trueadm/t7 https://github.com/trueadm/t7 [3]: https://github.com/joelrich/citojs https://github.com/joelrich/citojs
- ausjke 10y ago
  Thanks and this is very insightful. Yes it looks like typescript will be an essential part of the js-ecosystem sooner than expected.
- rpwverheij 10y ago
  ah thank you for the summary of the licences. that moves inferno off the table for me too. sadly though, cause I was really getting interested with it being written in typescript.

z3t4 10y ago

I'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.

dangoor 10y ago
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.
- pygy_ 10y ago
  You also want to batch your DOM manipulations as much as possible, and you get it automatically by using vDOM libraries.
- z3t4 10y ago
  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 whole app! Like when the next JS fashion/framework comes. grin
  - dangoor 10y ago
    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.
  - davidpatrick 10y ago

psibi 10y ago

What does isomorphic library mean in the context of Javascript ecosystem ?

deleted 10y ago
[deleted]
ghh 10y ago
Being able to run the same code both on the server side (nodejs) and the client side (browsers).
spyder 10y ago
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.

tacone 10y ago

Quite honestly my problem with react is the gzipped size, not the performance. What's the size of the browser bundle of this library?

leeoniya 10y ago
it's quite small (20k min). i think the two main deps needed are: https://github.com/trueadm/inferno/blob/master/packages/inferno/dist/inferno.min.js https://github.com/trueadm/inferno/blob/master/packages/infe... https://github.com/trueadm/inferno/blob/master/packages/inferno/dist/inferno-dom.min.js https://github.com/trueadm/inferno/blob/master/packages/infe...
xaduha 10y ago
Look into preact + buble ES2015 compiler then, should be small enough https://github.com/developit/preact https://github.com/developit/preact https://gitlab.com/Rich-Harris/buble https://gitlab.com/Rich-Harris/buble my app.min.js.gz is 6.2K for some basic stuff including preact-router https://github.com/developit/preact-router https://github.com/developit/preact-router

dyscrete 10y ago

I like how javascripters use `const` everywhere they can except actual constants! https://github.com/trueadm/inferno/blob/master/src/DOM/mounting.js#L65 https://github.com/trueadm/inferno/blob/master/src/DOM/mount...

aeosynth 10y ago

> Inferno uses intelligent techniques to separate static and dynamic content. This allows Inferno to only "diff" renders that have dynamic values. Can this be expanded? If/when the intelligent diffing fails, I'd like to know how to fix it.

ben_jones 10y ago

React, so great people are already re-writing it.

CognitiveLens 10y ago

Events + callbacks are great for keeping with the conventions of the existing (ancient) DOM APIs, but I was hoping that a new, 'modern' framework would be a little more ambitious by making everything promise-based.

shiftoutbox 10y ago

So who will be the ass hat who makes plan9 the js library , that like inferno but with ....

FLGMwt 10y ago

As a curiosity, how do we feel about changing the names of the lifecycle methods from "lifeCycleEvent" to "onLifecycleEvent"? Looks like a lot of stuff is pretty transparently portable from React code, I think it's curious this got changed.