Live data from Hacker News

InfernoJS – A JavaScript library for building powerful user interfaces

infernojs.org

91–100 of 135 posts

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

#91
post #48
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…

Can you build something that'll make your customers happy? 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.

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

#92

Earlier quoted context omitted.

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

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

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

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

#93
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…

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

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

#94

Earlier quoted context omitted.

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.

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

#95
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…

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.

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

#96
post #93
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…

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

Will definitely do that. README writing is like an entirely different skill in itself to be honest. I'm not great at it :/

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

#97
post #52
post #51

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/

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.

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

#98

Earlier quoted context omitted.

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.

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

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

#99
post #95
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…

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…

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.

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

#100

Earlier quoted context omitted.

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

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

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.

Post reply on HN