[tzaman]

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?

[nateabele]

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.

[choward]

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?

[trueadm]

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.

[choward]

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

[trueadm]

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

[HugoDaniel]

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.

[faceyspacey]

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?

[trueadm]

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

[vectorpush]

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

[TheOneTrueKyle]

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. ¯\_(ツ)_/¯

[iamjfu]

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.

[hobonumber1]

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.

[arcticfox]

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.

[AtheistOfFail]

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.

[moron4hire]

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?

[AtheistOfFail]

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.

[dabockster]

Remember when server side rendering plus some Nginx load balancing/port forwarding was all that was needed to show off to other technologists?

[dandelany]

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.

[chrshawkes]

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.

[trueadm]

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

[dandelany]

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.

[ohfunkyeah]

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.

[dandelany]

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.

[TeMPOraL]

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.

[ch4s3]

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

[WhitneyLand]

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

[wwalser]

Can you build something that'll make your customers happy?

Then your stack is good enough.

[kennysmoothx]

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.

[wwalser]

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.

[ravenstine]

bingo

[aikah]

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.

[dabockster]

>then he will write a blog post about how kids and wife make him unable to maintain his project anymore

I chuckled.

[Lazare]

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.

[trueadm]

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.

[tomascot]

Don't try to surf the tech wave. Learn to swim.

[moron4hire]

Is it JavaScript that is doing this to you? I think it's you doing this to you.

[tzaman]

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.

[moron4hire]

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

[tomascot]

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.

[moron4hire]

If your knowledge is becoming obsolete, then you weren't really, actually learning the concepts, you were just copy-pasting recipes.

[tomascot]

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.

[moron4hire]

I think it is reasonable, and I've actually gotten jobs that way.

[mambodog]

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

[jasoncchild]

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.