InfernoJS – A JavaScript library for building powerful user interfaces(infernojs.org)
infernojs.org
InfernoJS – A JavaScript library for building powerful user interfaces
http://infernojs.org/
134 comments
Previous discussion: https://news.ycombinator.com/item?id=11837082
Here we go again.
I click the link. Get to an under construction page. Click the link, get to Github, think "this is interesting" to myself. Read on. Find there's a project called Cerebral, which is a state management library for React/Inferno/Whatever. Start thinking there's something wrong with my app, that's "just" about to launch, and is "just" using plain old Redux. And now I'm thinking it's not good enough any more (while remembering I haven't even given a try to redux-saga), and maybe I should try another stack with Inferno/Cerebral?
Why are you doing this to me, JavaScript?
I click the link. Get to an under construction page. Click the link, get to Github, think "this is interesting" to myself. Read on. Find there's a project called Cerebral, which is a state management library for React/Inferno/Whatever. Start thinking there's something wrong with my app, that's "just" about to launch, and is "just" using plain old Redux. And now I'm thinking it's not good enough any more (while remembering I haven't even given a try to redux-saga), and maybe I should try another stack with Inferno/Cerebral?
Why are you doing this to me, JavaScript?
Every OS project README needs 2 sections: Purpose, where it explains what it is and why, and Prior Art, where it explains what came before, and how the project improves on / differs from them.
With time at such a premium, that is by far the most valuable information you could possibly communicate. I wouldn't even be bothered by having to read comments/unit tests to figure out how the thing works if you just tell me why I should care in the first place.
With time at such a premium, that is by far the most valuable information you could possibly communicate. I wouldn't even be bothered by having to read comments/unit tests to figure out how the thing works if you just tell me why I should care in the first place.
Exactly. Without all explaining all of this, the rest of the documentation is completely worthless.
> To quote a member of the React core team at Facebook: > Inferno 1.0 is really well written. It's how I would've rewritten React. I'd recommend reading its source to learn.
So fking what? You want me to read the source to try to decypher why I would want to use your new immature library? Another question is 'who is the target audience?'. It appears to be current react developers. However, I see no compelling reason why a react developer would want to switch. There are some cool benchmark numbers and file size stats, but so what? That's not affecting me.
The only thing that pops out as maybe being the "killer" feature is the isomorphic rendering. But I see no examples of this and have no idea how much of a pain it is to set up. The README for it is utterly worthless https://www.npmjs.com/package/inferno-server.
In summary, all I want to know is: Why as a current web developer who is comfortable with my relatively mature stack and ecosystem around it would I even consider your immature, non-battle tested project?
> To quote a member of the React core team at Facebook: > Inferno 1.0 is really well written. It's how I would've rewritten React. I'd recommend reading its source to learn.
So fking what? You want me to read the source to try to decypher why I would want to use your new immature library? Another question is 'who is the target audience?'. It appears to be current react developers. However, I see no compelling reason why a react developer would want to switch. There are some cool benchmark numbers and file size stats, but so what? That's not affecting me.
The only thing that pops out as maybe being the "killer" feature is the isomorphic rendering. But I see no examples of this and have no idea how much of a pain it is to set up. The README for it is utterly worthless https://www.npmjs.com/package/inferno-server.
In summary, all I want to know is: Why as a current web developer who is comfortable with my relatively mature stack and ecosystem around it would I even consider your immature, non-battle tested project?
note: I'm the author of Inferno.
If you're comfortable with what you have right now. I don't expect you to switch to Inferno. If you're happy with your app, it works great, it's performance is where you want it and your team/company love it – you'd be mad to switch to something because you saw it posted on Hacker News.
Inferno isn't here to make your life hard, it's giving you an opportunity to use it when the time might be right – like when you may have issues with performance on mobile (the primary reason why I created Inferno in the first place).
I also wrote Inferno so other authors of other libraries and tools could borrow the ideas in Inferno and further improve what they're trying to do. Open-source is great in that it allows us to share ideas in that way and I'd love to see other frameworks like React, Vue, Angular etc push the boundaries of performance even further.
If you're comfortable with what you have right now. I don't expect you to switch to Inferno. If you're happy with your app, it works great, it's performance is where you want it and your team/company love it – you'd be mad to switch to something because you saw it posted on Hacker News.
Inferno isn't here to make your life hard, it's giving you an opportunity to use it when the time might be right – like when you may have issues with performance on mobile (the primary reason why I created Inferno in the first place).
I also wrote Inferno so other authors of other libraries and tools could borrow the ideas in Inferno and further improve what they're trying to do. Open-source is great in that it allows us to share ideas in that way and I'd love to see other frameworks like React, Vue, Angular etc push the boundaries of performance even further.
> like when you may have issues with performance on mobile (the primary reason why I created Inferno in the first place)
That's exactly what I was looking for. The motivation. I only see mobile mentioned once in the README and it's regarding file size. I didn't understand that was the main reason for this project. Maybe you could make that more clear.
That's exactly what I was looking for. The motivation. I only see mobile mentioned once in the README and it's regarding file size. I didn't understand that was the main reason for this project. Maybe you could make that more clear.
Will definitely do that. README writing is like an entirely different skill in itself to be honest. I'm not great at it :/
I switched to Inferno recently after 2 years on React. Congrats for the amazing project, it truly makes a difference in mobile and even on pcs.
It seems with webpack you could alias inferno to react and start using it without many code changes, especially for projects that made a focus of using functional components. Am I wrong here? What are the main hurdles you see in doing this? What React features and common libraries would we have to forgo? Would recompose continue to work with it?
You can use ES2015 classes too and `inferno-compat` will try to support everything that React 15.4 currently supports. Recompose should work fine too, as should most common libraries. If you run into issues, please let the Inferno team know and we can investigate why. :)
> Here we go again.
This type of rhetoric really irritates me. Here we go again, someone wrote some code and released it on the internet for free! How could someone do this to you? Excuse the caps, I'm not trying to be hostile, but this attitude really makes me want to scream:
DON'T USE IT!
> And now I'm thinking it's not good enough any more
This is your mistake. The fact that someone released their code on the internet for free has absolutely no bearing on the engineering quality of your existing code. You're suffering from a case of programmer vanity, it has nothing to do with JavaScript, it has to do with the fact that you're looking for problems to solve with this shiny new tool instead of looking for tools to solve a specific problem.
This type of rhetoric really irritates me. Here we go again, someone wrote some code and released it on the internet for free! How could someone do this to you? Excuse the caps, I'm not trying to be hostile, but this attitude really makes me want to scream:
DON'T USE IT!
> And now I'm thinking it's not good enough any more
This is your mistake. The fact that someone released their code on the internet for free has absolutely no bearing on the engineering quality of your existing code. You're suffering from a case of programmer vanity, it has nothing to do with JavaScript, it has to do with the fact that you're looking for problems to solve with this shiny new tool instead of looking for tools to solve a specific problem.
Someone's rant was only 4 words (and then continued with decent criticism) and it inspired you to write an even longer rant instead of adding value to the project at hand.
¯\_(ツ)_/¯
The value they added was to try and teach people that they don't have to react negatively each time a new open source project is released or recommended.
Focus on the product, not the technology used to build it. If your tech decisions (vanilla Redux) makes you productive, then use that. Otherwise, you'll be stuck in a never-ending loop of upgrading your stack all the time.
I just downgraded my stack because state of the art kept breaking too much and slowing me down big time. Comfortably a step behind the cutting edge now and it feels great. Credit to Dan Abramov (creator of Redux) for writing "You Might Not Need Redux" and showing me the light... I needed just about nothing on his list of why Redux can be a critical help.
Remember when Rails + JQuery + HTML + CSS just worked and you didn't have to deal with thousands of fucking JS dependencies just to render a single page. Yeah, I do too.
Wait, you're not seriously going to bring up Ruby on Rails and try to say something about not having to deal with thousands of dependencies?
Yes, but Ruby on Rails dependencies aren't a fucking headache to manage.
I've only had one issue with Rails dependencies. They work fucking great if you just want to drop them and leave in the default configuration but the moment you try to customize them... holy shit balls.
I've only had one issue with Rails dependencies. They work fucking great if you just want to drop them and leave in the default configuration but the moment you try to customize them... holy shit balls.
Remember when server side rendering plus some Nginx load balancing/port forwarding was all that was needed to show off to other technologists?
With respect, friend, you do it to yourself... If a mention of a new library on HN is enough to shake your confidence and make you think your entire app stack is wrong - that's not a Javascript problem. I understand feeling overwhelmed with all the new libraries, but get confident with a JS stack that you like, and stop worrying about all the hype.
Inferno is basically React, so instead of contributing to react to make it better they made a new project instead. Hipster hype is a PROBLEM in the JS community.
That is so far from the truth that it's unbelievable. Inferno has the same surface API as React – the public endpoints. Everything under the hood is different though and it's different for many good reasons which I'll cover in a blog post in the coming weeks for the official 1.0 release of Inferno (and its website).
If there's nothing wrong with your app and you're using React – keep using it. If you are experiencing performance issues on mobile, maybe Inferno is an option with its compatibility layer until future versions of React can fix your issues.
Note: I'm the author of Inferno
If there's nothing wrong with your app and you're using React – keep using it. If you are experiencing performance issues on mobile, maybe Inferno is an option with its compatibility layer until future versions of React can fix your issues.
Note: I'm the author of Inferno
Inferno is very similar to React, but with enough differences in implementation that the contributors decided to make it its own project. Competition is good. Cars weren't invented by everyone focusing their effort on building the same car. Instead, many teams built many cars with similar, overlapping functionality, and over time, the good parts stuck around, and the bad parts came out in the wash. JS UI libraries are no different. I don't understand everyone's apparent obsession with uniting around "one true JS framework". Use what works for you. Build what you want to build. But don't complain that someone built this library that you don't want to use.
Think of a professional vehicle driving. Be it race cars, trucks, etc... Sure, maybe in the early days those cars and trucks looked and worked way different from each other but over time the available ones largely overlap, work similarly, and work well in almost all situations. If every time a new car came out you had to spend several days/weeks trying to figure out how to drive it that would be incredibly annoying. Now just think if you needed to purchase a vehicle and stake your business on it. You look at the options and some come without wheels, some without seats, some had designers that said brakes aren't neccessary, oh and there is an upcoming one that is getting a lot of attention the can also fly... some take gas, others run off vegetable oil. Experimentation is good but there are way too many options parading around as serious contenders.
The problem with your analogy is that, in it, we are the consumers, the people who buy the car. I would agree with some of your points if you were speaking from an end-user's point of view.
But as developers, we're the engineers. We build the car. It is explicitly our job to do all the hard work of picking out the appropriate parts and assembling them in a way that provides a seamless experience for the end user. IMHO complaining about "way too many options" is like a Ford engineer complaining that there are too many (let's say) turbochargers available with varying levels of quality, and it's unclear which one should go in the new car she's designing. It's supposed to be hard, these are precisely the hard problems we are getting paid lots of money to solve.
But as developers, we're the engineers. We build the car. It is explicitly our job to do all the hard work of picking out the appropriate parts and assembling them in a way that provides a seamless experience for the end user. IMHO complaining about "way too many options" is like a Ford engineer complaining that there are too many (let's say) turbochargers available with varying levels of quality, and it's unclear which one should go in the new car she's designing. It's supposed to be hard, these are precisely the hard problems we are getting paid lots of money to solve.
The relation of consumption is transitive. End-users consume our products. We consume libraries and frameworks we use to build this tools. Just like in the analogy buyers would be annoyed by the plethora of choices, many developers are getting annoyed at constantly changing "best library" ecosystem.
> It's supposed to be hard, these are precisely the hard problems we are getting paid lots of money to solve.
And quite a lot of those problems - including this situation - are instances of the so-called accidental complexity. I.e. difficulties we inflict on ourselves, not parts of the problem that's being solved.
Anyway, the problem seems to be more profound in software than elsewhere, and I think it's because of the medium - code is very malleable; it's easier to rewrite a program than to redesign a car that's already being manufactured. So it makes it tempting to consider changing frameworks, instead of picking one that's good enough and sticking with it.
> It's supposed to be hard, these are precisely the hard problems we are getting paid lots of money to solve.
And quite a lot of those problems - including this situation - are instances of the so-called accidental complexity. I.e. difficulties we inflict on ourselves, not parts of the problem that's being solved.
Anyway, the problem seems to be more profound in software than elsewhere, and I think it's because of the medium - code is very malleable; it's easier to rewrite a program than to redesign a car that's already being manufactured. So it makes it tempting to consider changing frameworks, instead of picking one that's good enough and sticking with it.
>there are way too many options parading around as serious contenders.
Its early days for some of these concepts on the web (I mean, discounting some stuff that happened years ago at Xerox Parc which got beat out by worse technology). So by what objective measure are there too many options? There are a few very well established options: React, Angular, and Ember. If you need standards and heavyweight support and reliability, use one of those things. I'm sure in a few years, things will have coalesced and standardized a bit further.
Why should someone not be able to create whatever project they want and try to make something useful or just for an experiment?
It also seems:
1). You criticize quickly without knowing all the benefits of what he's trying to accomplish
2). He never mentioned hipsters but your own personal projects actually advertise hipster in the name
It also seems:
1). You criticize quickly without knowing all the benefits of what he's trying to accomplish
2). He never mentioned hipsters but your own personal projects actually advertise hipster in the name
Can you build something that'll make your customers happy?
Then your stack is good enough.
Then your stack is good enough.
I like this a lot.
Your customers have no idea what a stack is, they, as well as the rest of the internet, just see the finished product.
Thats what matters most.
Your customers have no idea what a stack is, they, as well as the rest of the internet, just see the finished product.
Thats what matters most.
I'm a software engineer turned self-funded founder. The amount of stuff that's critical to early success and has absolutely nothing to do with technology really puts decisions like what stack to use into perspective.
Rewriting using another stack is N weeks/months that I'm not spending on writing, distribution, iterating on paid marketing, cold emails, calls with customers etc. I used tech that I knew I could scale into 1k users, likely more around 50k but we'll see. I've had zero technology based regrets aside for attempting to use Firebase for something that it wasn't suited for early on.
Rewriting using another stack is N weeks/months that I'm not spending on writing, distribution, iterating on paid marketing, cold emails, calls with customers etc. I used tech that I knew I could scale into 1k users, likely more around 50k but we'll see. I've had zero technology based regrets aside for attempting to use Firebase for something that it wasn't suited for early on.
bingo
It's going to happen AGAIN, AGAIN and AGAIN. I give you a piece of a advice : only use something that has been there for at least 2 years and is still maintained actively, preferably corporate backed. So React for instance. Because in 2 month there will be yet another hot thing that will be maintained for 5 months then its creator will get hired somewhere with a nice salary, then he will write a blog post about how kids and wife make him unable to maintain his project anymore.
>then he will write a blog post about how kids and wife make him unable to maintain his project anymore
I chuckled.
I chuckled.
I'm sympathetic, but:
1. Does your existing code have any problems that are bothering you?
2. Does this new library explicitly claim to solve any of the specific problems you identified in step 1?
Unless both answers are true, it's absurd to start down this path. Even if they are true the switching costs likely outweigh the benefit, but if you can't even articulate what benefit their might be, why are you starting to think your code isn't good enough.
> I haven't even given a try to redux-saga
I took a look at it a few months back; it's ridiculously complex. I passed. You mention the library like it's obviously something you should try. Why?
> maybe I should try another stack with Inferno/Cerebral?
And maybe you shouldn't? Your default answer should always be to stick with what you have. You're asking all these questions, but the answer to all of them is "no" unless you have a good reason to think otherwise.
Edit: Here's an example. A while back I was looking through our app code and I realized all the redux code we were using is too complicated. We've got too much boilerplate and too many abstractions layered on each other in order to solve what are actually some very simple problems. Some people might need redux; we don't. So I looked around, identified mobx as a way of simplifying our stack without necessitating a major rewrite, and as modules get updated or added we're now migrating from redux to mobx. It's working well, because I identified a problem, then identified a solution, and then implemented it. And while mobx may be a lot less cool and hip than redux (it doesn't even have immutable data structures!), it also is really simple and easy to reason about.
1. Does your existing code have any problems that are bothering you?
2. Does this new library explicitly claim to solve any of the specific problems you identified in step 1?
Unless both answers are true, it's absurd to start down this path. Even if they are true the switching costs likely outweigh the benefit, but if you can't even articulate what benefit their might be, why are you starting to think your code isn't good enough.
> I haven't even given a try to redux-saga
I took a look at it a few months back; it's ridiculously complex. I passed. You mention the library like it's obviously something you should try. Why?
> maybe I should try another stack with Inferno/Cerebral?
And maybe you shouldn't? Your default answer should always be to stick with what you have. You're asking all these questions, but the answer to all of them is "no" unless you have a good reason to think otherwise.
Edit: Here's an example. A while back I was looking through our app code and I realized all the redux code we were using is too complicated. We've got too much boilerplate and too many abstractions layered on each other in order to solve what are actually some very simple problems. Some people might need redux; we don't. So I looked around, identified mobx as a way of simplifying our stack without necessitating a major rewrite, and as modules get updated or added we're now migrating from redux to mobx. It's working well, because I identified a problem, then identified a solution, and then implemented it. And while mobx may be a lot less cool and hip than redux (it doesn't even have immutable data structures!), it also is really simple and easy to reason about.
I completely agree and I wrote Inferno. I really do think people jump on Hacker News stories in the wrong way at times. Inferno isn't meant to make you abandon months of work because it's shiny and new – or whatever reason someone has.
I'm all for starting a conversation though. People should evaluate Inferno and see if it solves a particular problem they're having. If it doesn't and they're in a good place with what they have, then they probably shouldn't be doing it.
If anything, I hope Inferno makes other library authors realise that there is a demand for performance when it comes to PWAs on the mobile platform and, in my opinion, what we have right now in terms of options isn't necessarily great – especially on low-end mobile devices in developing regions of the world.
I'm all for starting a conversation though. People should evaluate Inferno and see if it solves a particular problem they're having. If it doesn't and they're in a good place with what they have, then they probably shouldn't be doing it.
If anything, I hope Inferno makes other library authors realise that there is a demand for performance when it comes to PWAs on the mobile platform and, in my opinion, what we have right now in terms of options isn't necessarily great – especially on low-end mobile devices in developing regions of the world.
Don't try to surf the tech wave. Learn to swim.
Is it JavaScript that is doing this to you? I think it's you doing this to you.
Failed attempt of being funny aside. The struggle is real for many developers. Many (if not most) of us are self-taught and we like to explore how deep the rabbit hole goes, which inflicts many episodes of analysis paralysis upon us, and it takes a lot of willpower to stay on course. The fear then becomes what if any given choice will be obsolete once we launch our products, given how fast the technologies move forward, especially JavaScript ecosystem.
So in my opinion and all honesty, I still prefer React+Redux (and Angular for some of our apps) because it's the safest bet that they are in for the long run and won't be obsoleted by shiny new library of tomorrow.
So in my opinion and all honesty, I still prefer React+Redux (and Angular for some of our apps) because it's the safest bet that they are in for the long run and won't be obsoleted by shiny new library of tomorrow.
"explore how deep the rabbit hole goes, which inflicts many episodes of analysis paralysis upon us"
Again, this isn't JavaScript's fault. Go to Java, Python, or Ruby (incidentally, with JavaScript, they're all languages that came out in the mid-90s) and you'll find a similar breadth of library options.
The problem is, where there is breadth, you think you see depth. Just because there are dozens of frameworks doesn't mean there are dozens of new things to learn. Functional-reactive programming isn't a new concept. Virtual DOM diffing isn't a new concept, and it's also not one that is difficult to understand.
Perfect is the enemy of good. What you're talking about is just being inexperienced. It's just being a junior programmer and has nothing to do with JS.
Again, this isn't JavaScript's fault. Go to Java, Python, or Ruby (incidentally, with JavaScript, they're all languages that came out in the mid-90s) and you'll find a similar breadth of library options.
The problem is, where there is breadth, you think you see depth. Just because there are dozens of frameworks doesn't mean there are dozens of new things to learn. Functional-reactive programming isn't a new concept. Virtual DOM diffing isn't a new concept, and it's also not one that is difficult to understand.
Perfect is the enemy of good. What you're talking about is just being inexperienced. It's just being a junior programmer and has nothing to do with JS.
I think this is spot on. And is hard to understand while working for yourself and thinking your knowledge may become obsolete if you don't know the latest trending tech.
If your knowledge is becoming obsolete, then you weren't really, actually learning the concepts, you were just copy-pasting recipes.
You might have misinterpreted what I tried to say. I was talking about languages/frameworks, not the theory behind them. I don't think is feasible to go to a interview for a job that asks for node expertise saying you know the concepts behind node but you haven't used it yourself in a project.
I think it is reasonable, and I've actually gotten jobs that way.
> Start thinking there's something wrong with my app, that's "just" about to launch, and is "just" using plain old Redux
Why would you think this? What problem are you having? What is your app supposed to be delivering that your current technology choice is preventing?
Why would you think this? What problem are you having? What is your app supposed to be delivering that your current technology choice is preventing?
Idk, I just try to be reasonably fluent in the language...frameworks tend to play to one ideology or another and it seems just as important to pick one you understand as it is to pick one that purports to solve your problems better/faster/etc.
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 react asynchronously?
> 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 react asynchronously?
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...
https://nolanlawson.com/2016/08/15/the-cost-of-small-modules...
That's one of the most solid articles I've seen on front-end development in a while -- not a think piece, tons of practical information, relies on examining information, but also does get around to a deep-seated problem with JS right now ("I hope that our community will eventually realize the pickle we’re in – advocating for a “small modules” philosophy that’s good for developers but bad for users").
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.
If you're bundling it into one payload it does not. If you're code splitting, it's 38k of download time and ~120k of parse time you're not paying on time to first meaningful paint. It's a couple dozen ms on desktops but can be several hundred on mobile.
If you're going that route, then server side rendering may be a better option.
Probably not. The rest of your app aside, in the vast majority of cases, if you care about the file size you're optimizing the wrong thing (barring certain extremes of course).
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.
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.
There's also preact + preact-compat which provides a compatibility shim... Works as pretty much a drop-in replacement for React for your prod builds.
However, that "extra" isn't all just junk, it's a LOT of REALLY nice error reporting that I've not seen in ANY other framework. Dealing with errors in React applications is far, far, far easier than some other frameworks have been (ahem, ng1/ng2).
However, that "extra" isn't all just junk, it's a LOT of REALLY nice error reporting that I've not seen in ANY other framework. Dealing with errors in React applications is far, far, far easier than some other frameworks have been (ahem, ng1/ng2).
But that is stripped out in production builds, so is not contributing to the size everyone is talking about.
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.
Frankly, everyone I know insisting on isomorphic rendering is doing it for SEO not for improved first display on mobile. Not that it isn't worth it... what WalmartLabs has done is incredibly impressive in this space.
It is not the 38KB size, but that much lines of code will take browser x amount of time more to decipher, keep track of...etc.
Just a note to people expecting an actual website – we are in the process of building one and you can see what it will look like here: https://twitter.com/trueadm/status/802675565421625344
Furthermore, if anyone has any questions feel free to ask away (I'm the author of Inferno). :)
Furthermore, if anyone has any questions feel free to ask away (I'm the author of Inferno). :)
Vuejs site in red? :)
I dont want to bash, just thinking maybe there should be some universal jsframework theme (even playing field). I feel like one of the big reasons vue became popular is because it had proffesionaly looking design from v0.01. Compare that to for example mithrill and many people will just pick vue straight away.
Its good idea to have nice page.
I dont want to bash, just thinking maybe there should be some universal jsframework theme (even playing field). I feel like one of the big reasons vue became popular is because it had proffesionaly looking design from v0.01. Compare that to for example mithrill and many people will just pick vue straight away.
Its good idea to have nice page.
I think it looks great. We've been designing this site for a while now and there comes a point where you need to stop designing it and start building it – which is why we still don't have a site :D
I don't know if it's been spotted but the logo looks a lot like Code Igniter's one.
It's React-like with CodeIgniter-like logo, what's not to love?
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.
> Frankly I think this posting of github pages instead of the authorative source is inappropriate
The website is the authorative source of... what, exactly? Not the codebase, not the documentation - neither of those things are on there. The only piece of content is a stealth link - and I'm not alone in having missed it, and only found out about it via the comments. "Did it get HNed...?" I wonder if the link would've been more obvious on desktop, where I might've hovered over the icon with my cursor.
I see linking github pages as more along the lines of e.g. deep linking specific developer.apple.com pages. This has always been how the web was designed to work - link directly to the useful information. If you want the authoritative source readily available, link back to your authoritative website via your readme.md, so everything's nice and cross-referenced (as I note they have.)
> 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.
Ahh - just because you're on an official-looking website doesn't mean you're on the official website. You could easily be looking at e.g. a community fork of a project, possibly renamed, instead. Linking to a website doesn't actually solve this problem. That github links encourage you to look at the wider ecosystem might even be a feature... ;)
The website is the authorative source of... what, exactly? Not the codebase, not the documentation - neither of those things are on there. The only piece of content is a stealth link - and I'm not alone in having missed it, and only found out about it via the comments. "Did it get HNed...?" I wonder if the link would've been more obvious on desktop, where I might've hovered over the icon with my cursor.
I see linking github pages as more along the lines of e.g. deep linking specific developer.apple.com pages. This has always been how the web was designed to work - link directly to the useful information. If you want the authoritative source readily available, link back to your authoritative website via your readme.md, so everything's nice and cross-referenced (as I note they have.)
> 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.
Ahh - just because you're on an official-looking website doesn't mean you're on the official website. You could easily be looking at e.g. a community fork of a project, possibly renamed, instead. Linking to a website doesn't actually solve this problem. That github links encourage you to look at the wider ecosystem might even be a feature... ;)
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.
Considering the lifetime of JS frameworks nowadays, the website has been "coming soon" for ages.
http://web.archive.org/web/*/http://infernojs.org/
http://web.archive.org/web/*/http://infernojs.org/
Doesn't mean much. I purchase domains for rainy day ideas all the time.
Go back to the original check-in to this repository it was clear this project wasn't planned out from jump street.
They just went through a big github discussion about the design that finished last Saturday. It should be actually pretty soon instead of "soon".
I don't understand the negativity. This isn't buzzfeed or reddit, the target audience is supposed to be people who are already devs and not need handholding.
So there's no website. So what? The github page clearly explains what it is, who its for and how it works. Focus on the product, talk about its pros/cons without trying to distract from the core issues.
e.g. the size complaint - almost every article about React/Angular/Vue will compare the lib sizes and impact on loading etc - Inferno is faster and smaller. Why complain?
The focus of the library seems to be speed, a minimal implementation that is still fully API compatible with React, which is no mean feat. And on top of that it happens to be the fastest UI framework. Give some credit to the author, FB has already said they might be incorporating ideas from it.
So there's no website. So what? The github page clearly explains what it is, who its for and how it works. Focus on the product, talk about its pros/cons without trying to distract from the core issues.
e.g. the size complaint - almost every article about React/Angular/Vue will compare the lib sizes and impact on loading etc - Inferno is faster and smaller. Why complain?
The focus of the library seems to be speed, a minimal implementation that is still fully API compatible with React, which is no mean feat. And on top of that it happens to be the fastest UI framework. Give some credit to the author, FB has already said they might be incorporating ideas from it.
If anyone has any further questions/queries/ideas/rants you can jump on the Inferno Slack - https://inferno-slack.herokuapp.com/.
The team and I would love to hear from you. We want to make Inferno better and we believe in doing so, we can start a shift in the community that starts to realise that performance on mobile with the current state of libraries and tools is not good enough. This was always the primary goal for why I began Inferno – about 2 years ago.
The team and I would love to hear from you. We want to make Inferno better and we believe in doing so, we can start a shift in the community that starts to realise that performance on mobile with the current state of libraries and tools is not good enough. This was always the primary goal for why I began Inferno – about 2 years ago.
Minor note: the linked url brings to a placeholder page.
Should probably link here: https://github.com/trueadm/inferno
Cx widgets mostly work with inferno-compat. There are still some issues to iron out, but hopefully that will be fixed with 1.0. Performance improvement over React is clearly visible, especially on large unbuffered grids:
http://cx.codaxy.com/v/inferno/docs/examples/grid/dynamic-gr...
http://cx.codaxy.com/v/master/docs/examples/grid/dynamic-gro...
I think that inferno-compat parity with React should be Inferno's top priority now. The performance is already great.
http://cx.codaxy.com/v/inferno/docs/examples/grid/dynamic-gr...
http://cx.codaxy.com/v/master/docs/examples/grid/dynamic-gro...
I think that inferno-compat parity with React should be Inferno's top priority now. The performance is already great.
Inferno seems to be very comparable to Riot.js, only Riot is more mature, has event delegation and a router, and is only 9.5k vs Inferno's 7k. And riot has an actual web page.
http://riotjs.com/
http://riotjs.com/
last I checked, Inferno was a React "near drop-in" replacement. So not the same at all, unless you look at it in a vacuum.
Nowhere does the inferno docs say only people who already use react should use it. As a library for creating "modern user interfaces", it is in direct competition with riot.
Ahhh, you know riot is bad performance wise?
I am sure riot's performance is not bad many real world apps. but the devs would certainly prefer the faster one so they won't run into problems later.
I am sure riot's performance is not bad many real world apps. but the devs would certainly prefer the faster one so they won't run into problems later.
[deleted]
no one is going to comment on how a library for powerful UI's has an under construction landing page that only links to github?
Unfortunately unrelated to Inferno the operating system, which was warped into running in a browser, many moons ago.
http://www.vitanuova.com/inferno/
http://www.vitanuova.com/inferno/
It's disingenuous for the authors to claim this is a near "drop-in" replacement for React. Just because it works now for (likely) some limited surface area test app doesn't mean it will work in all of React's weird nooks and cranes, or its constantly changing APIs or huge stack of dependent behaviors it has inherited from its ever-changing dependencies.
Clearly, the authors don't have much experience in this regard to make such claims. Caveat emptor.
Clearly, the authors don't have much experience in this regard to make such claims. Caveat emptor.
That's why I claim near rather than perfect. It's a constant work in progress, that's the challenge :)
[deleted]
Man I can't keep up with all of these. Is there a list that anyone is keeping track of for javascript UI frameworks? I suppose it would require daily updating.
I like to refer to http://stateofjs.com/ and http://todomvc.com.
[deleted]
[deleted]
if you don't have the site ready, it'd make more sense to just link to the repo
Where is this being used?
There are many reasons why Web Components are important and framework proliferation is just one of them.
Don't forget there are many unpopular (wdsl) and dead (xhtml, e4x) standards out there already. There is absolutely no reason to believe that web components will have a better track record.
Of course there're reasons to believe it: Web Components solve some critical problems, All the browsers are in support of the standards and implementing them, we've had very good uptake with Polymer, other Web Component frameworks are popping up at places like Atlassian, and many large companies like ING, IBM, GE, Bloomberg, Salesforce, and of course Google - with YouTube and more - moving to Web Components.
Relevant to this discussion, Web Components will make it possible for less mainstream frameworks to get a foothold in real applications by not being locked out by proprietary silos.
Relevant to this discussion, Web Components will make it possible for less mainstream frameworks to get a foothold in real applications by not being locked out by proprietary silos.
> browsers are in support of the standards
Well, realistically speaking, web components consist of a bunch of different specs and each specification should really be considered on its own merits. Shadow DOM and Custom Elements are mostly ok. HTML Imports spec looks like it was created with the simple "include jQuery widget on the page" use case in mind and doesn't consider anything else. Node.js/npm/CommonJS ecosystem, es6 modules — it's like nothing of this even exist. This is obviously not good enough and that's why Mozilla decided to not support this thing.
> being locked out by proprietary silos
That's a really mean thing to say about an open-source javascript library. Especially considering that Inferno is a reimplementation of React API. I actually think Fb should make React API into its own mini-spec (like JSX or GraphQL) if only for trolling "muh web standards!" people.
Well, realistically speaking, web components consist of a bunch of different specs and each specification should really be considered on its own merits. Shadow DOM and Custom Elements are mostly ok. HTML Imports spec looks like it was created with the simple "include jQuery widget on the page" use case in mind and doesn't consider anything else. Node.js/npm/CommonJS ecosystem, es6 modules — it's like nothing of this even exist. This is obviously not good enough and that's why Mozilla decided to not support this thing.
> being locked out by proprietary silos
That's a really mean thing to say about an open-source javascript library. Especially considering that Inferno is a reimplementation of React API. I actually think Fb should make React API into its own mini-spec (like JSX or GraphQL) if only for trolling "muh web standards!" people.
> wdsl
* correction: wsdl
* correction: wsdl
Is there any place where the community usually hangs ? Some chat room or forum ? Thanks
Now, it's all about Svelte vs Inferno. I like Svelte more than Inferno.
It's all about a Svelte, a framework that came to light a week ago and isn't in production anywhere that matters? Come on...
A week is about 6 months in JS-years.
No it's not, I hate when people spread this shit.
Inferno JS is probably one of the newest "frameworks"/large-libraries that I would even consider using, and it's over a year old already.
React has been around in some fashion since 2011, and was open sourced in 2013.
Angular 1 has been since around 2010 IIRC. Angular 2 since around mid-late 2015.
Ember since before mid 2014.
Yes, some terrible developers like to chase the "new cool thing" every few weeks, but that doesn't mean that you need to, and it doesn't mean that there aren't stable, powerful, good choices that have been around for years.
Inferno JS is probably one of the newest "frameworks"/large-libraries that I would even consider using, and it's over a year old already.
React has been around in some fashion since 2011, and was open sourced in 2013.
Angular 1 has been since around 2010 IIRC. Angular 2 since around mid-late 2015.
Ember since before mid 2014.
Yes, some terrible developers like to chase the "new cool thing" every few weeks, but that doesn't mean that you need to, and it doesn't mean that there aren't stable, powerful, good choices that have been around for years.
Only if your training was a "coding bootcamp".
we move a production app from react to Svelte in a week. What are you smoking?
No need comparison, they help each other is greater than the sum of all parts.
[deleted]
Sorry, can someone do a ELI5?
What does it mean to be React-like? Is it a drop-in replacement? Are React components compatible? Or it just looks like React (it does)?
I'm going absolutely crazy trying to keep up-to-date with all frameworks coming out nowadays.
Yesterday it was Svelte, today it's Inferno.
What's good about using this instead of React? 3k of parsing instead of 40k is a huge improvement, but can we still using stuff that was made for React?
I'm lost.
What does it mean to be React-like? Is it a drop-in replacement? Are React components compatible? Or it just looks like React (it does)?
I'm going absolutely crazy trying to keep up-to-date with all frameworks coming out nowadays.
Yesterday it was Svelte, today it's Inferno.
What's good about using this instead of React? 3k of parsing instead of 40k is a huge improvement, but can we still using stuff that was made for React?
I'm lost.
You totally can use Inferno. You can use a package on NPM called "inferno-compat" to alias out React to Inferno via Webpack/Babel/Browserify if you want to. Alternatively, you can use Inferno as is and it has JSX Babel plugin, all the same top-level APIs and has the same ES2015 components as React (although we've put them in their own package called "inferno-component", as some people don't use them).
I hope that helped – I'd recommend jumping on the Inferno Slack if you'd like to know/understand more: https://inferno-slack.herokuapp.com/
I hope that helped – I'd recommend jumping on the Inferno Slack if you'd like to know/understand more: https://inferno-slack.herokuapp.com/
Thanks.
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.
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.
What do you think the extra 38kb of code is for? My point of view is, you've got a company with thousands of employees who work with a library every day and core teams dedicated to its improvement. Their requirements for speed and bandwidth far exceed our own as they reach further into the nth percentile of users, so you know things like speed and bloat are important for them to cut out.
What, if anything, is actually gained from a business perspective by reducing a single library by 38kb? My guess is exactly nothing. And the benefit of sticking to React is not only the community, but the fact that they actually own their virtual DOM implementation and actively work to improve it (the forthcoming fiber rendering engine is a great example of that.)
I'm not hating on new technology, but this isn't actually new. It's a clone that isn't really bringing anything new to the table, and just muddies the water for developers. It's like if every few weeks there was a new take on Git that did practically the same thing but wasn't Git.
We'd be much better off if these people were contributing to React core. Because if it truly has the same capability as React, you should be able to shave the 38k off right?
What, if anything, is actually gained from a business perspective by reducing a single library by 38kb? My guess is exactly nothing. And the benefit of sticking to React is not only the community, but the fact that they actually own their virtual DOM implementation and actively work to improve it (the forthcoming fiber rendering engine is a great example of that.)
I'm not hating on new technology, but this isn't actually new. It's a clone that isn't really bringing anything new to the table, and just muddies the water for developers. It's like if every few weeks there was a new take on Git that did practically the same thing but wasn't Git.
We'd be much better off if these people were contributing to React core. Because if it truly has the same capability as React, you should be able to shave the 38k off right?
There's far more to Inferno than just file size. The internal implementation is completely different. Furthermore, React Fiber and Inferno are very different in terms of internal approach.
Thanks for your reply Dominic. As an end user, what should compel me to use Inferno for any production purposes? Bearing in mind React has the support of multiple billion dollar companies, several targets (web, native mobile/desktop, console) and a community of what is sure to be tens if not hundreds of thousands of developers. I just don't see the benefit of incremental improvements when they're not being integrated into that community. You lose all the benefit. I have no doubt Inferno is faster, but I suspect you're being disingenuous when you say all the same features are available.
The trouble I have is not specific to Inferno, but rather the idea that less and new is better. Eventually, your users will want something that Inferno doesn't offer, and eventually it will be implemented. And this will happen more than once, probably to the point where your library, too, is 45kb. So is all this work and fragmentation and confusion and comparing of benchmarks really worth it? I think not, unless the technology stands to bring something vastly different to the table.
The trouble with competing with React in its own space right now, stems from the vast amount of resources many of companies are putting behind it. You just can't make a Inferno Native, etc. I think we'd be much better off all working together on new ideas, not rehashing innovation in order to win benchmark tests.
All that said, I applaud the effort, as I'm sure this took a lot.
The trouble I have is not specific to Inferno, but rather the idea that less and new is better. Eventually, your users will want something that Inferno doesn't offer, and eventually it will be implemented. And this will happen more than once, probably to the point where your library, too, is 45kb. So is all this work and fragmentation and confusion and comparing of benchmarks really worth it? I think not, unless the technology stands to bring something vastly different to the table.
The trouble with competing with React in its own space right now, stems from the vast amount of resources many of companies are putting behind it. You just can't make a Inferno Native, etc. I think we'd be much better off all working together on new ideas, not rehashing innovation in order to win benchmark tests.
All that said, I applaud the effort, as I'm sure this took a lot.
You don't need to necessarily use Inferno in production all at all. If you're happy with React, stick with it. Inferno can serve to help other authors and the React team to further improve their tools. This is open source after all, we can all learn and improve from one another and make even better software.
Personally, I was actually looking for an alternative to react some time ago, on the grounds of that "BSD License" + "Patents" that facebook has got on it. From what I know no, nothing has happened yet, but for peace of mind, having an alternative would help.
FYI, What I found was preactjs which is a 3kb with most new es6 features of react which I've started using in my project. Unfortunately, I haven't found an alternative to react-native yet.
FYI, What I found was preactjs which is a 3kb with most new es6 features of react which I've started using in my project. Unfortunately, I haven't found an alternative to react-native yet.
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
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
So basically, as the platform matures beyond a fun experiment, it'll grow in size. Got it. ;)