InfernoJS – A JavaScript library for building powerful user interfaces
infernojs.org
infernojs.org
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?
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.
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'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.
Then your stack is good enough.
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.
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.
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.
> 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.
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
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
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.
> 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?
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.
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.
I chuckled.
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'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.
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.
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?
> 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?
https://nolanlawson.com/2016/08/15/the-cost-of-small-modules...
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.
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).
Furthermore, if anyone has any questions feel free to ask away (I'm the author of Inferno). :)
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 assume they realize, yes.
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... ;)
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.
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.
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.
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.
Although I did think "ooh, don't tell me someone has compiled Inferno OS to Javascript, that would be awesome" nope.
Clearly, the authors don't have much experience in this regard to make such claims. Caveat emptor.
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.
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.
* correction: wsdl
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.
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.
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/
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
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, 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?
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.
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.