Live data from Hacker News

InfernoJS – A JavaScript library for building powerful user interfaces

infernojs.org

111–120 of 135 posts

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

#111
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.

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

#112

Earlier quoted context omitted.

> 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 int…

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.

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

#113
post #6

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... ;)

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

#114
post #87
post #84

Earlier quoted context omitted.

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 f king 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 t…

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 m…

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?

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

#115
post #35

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…

> 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?

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

#116

Earlier quoted context omitted.

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…

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

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

#118
post #17

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

we move a production app from react to Svelte in a week. What are you smoking?

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

#119

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.

> wdsl

* correction: wsdl

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

#120
post #87

Earlier quoted context omitted.

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 m…

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. :)
Post reply on HN