81–90 of 135 posts
Earlier quoted context omitted.
But that is stripped out in production builds, so is not contributing to the size everyone is talking about.
Not all of it... there are still extras that come in the production builds of react compared to other frameworks... I'm not talking about the property checking, etc.
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…
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…
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 w…
> 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?
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.
Earlier quoted context omitted.
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 w…
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…
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.
There are many reasons why Web Components are important and framework proliferation is just one of them.
Just a note to people expecting an actual website – we are in the process of building one and you can see what it will look like here: https://twitter.com/trueadm/status/802675565421625344 Furthermore, if anyone has any questions feel free to ask away (I'm the author of Inferno). :)
Vuejs site in red? :) 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.
From the README > 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…