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