At the risk of beating a dead horse, we are only fueling the flames of javascript fatigue by churning out these "It's like X, but with more/less cowbell" libraries. We need to stop fragmenting and start doubling down on existing libraries.
[deleted]
Inferno: A fast, React-like JavaScript library for building UIs
71–80 of 128 posts
Re: Inferno: A fast, React-like JavaScript library for building UIs
#72We were previously using RiotJs in our company. We are building huge single page application and recently moved to InfernoJS. Results have been amazing. RiotJs used to BE lagging a lot (It simply could not handle 3000 components in same way) It had really long (50ms) delays everywhere. After moving to Inferno following things have improved: -We are unit testing components -Performance!!! (No delays/lagging anymore) -…
What do you consider huge? Maybe we're just slow, but we recently estimated that rewriting and launching our whole frontend in another js Framework would take a dedicated 3 Person Team atleast a year, how do you explain this cost to someone with financial responsibility, I mean the benefits are probably great, but THAT great?
The alternative, depending on your market segment, is your competitor do it and you don't, they fall behind for a little bit, your sales grow.
Then their version comes out, faster and better, and their dev team iterates faster, eventually catching up and leaves you in the dust. I've seen it happen...very recently, in a situation that ended up in large layoffs.
It doesn't have to be all or nothing though. These libs are easy to keep around side by side, so you can slowly rewrite stuff as you add new features until the transition is complete.
Re: Inferno: A fast, React-like JavaScript library for building UIs
#73I'm trying hard to figure out why someone want to use something like this or React, when vanilla HTML, CSS and JavaScript seems much easier and more performant. The only thing I can think of is that appendChild is a bit tedious, but createClass seems even more boilerplate.
The vanilla way tends to result in state spread out throughout your JS and DOM. React UIs act like predictable functions: you describe the UI you want with your current state as the input and React makes the visible UI match that.
I think this is a JQuery problem, as it makes complexing state the path of least resistance. i.e. modifying the DOM directly instead of via functions. Resulting in code that is hard to test or debug. React seems to fix this, witch makes it a good argument on why to use it. My counterargument for "vanilla" JS/HTML is that you can refactor the bad parts. But you can't get rid of React, or you would have to rewrite your whole app! Like when the next JS fashion/framework comes. grin
Re: Inferno: A fast, React-like JavaScript library for building UIs
#74Earlier quoted context omitted.
It's solving performance issues that React and other virtual DOM libraries currently suffer. This is massively important for low power mobile devices. It's not an ego driven project, all research is going back into the open-source community to make better libraries and implementations inclusion React.
> It's solving performance issues that React and other virtual DOM libraries currently suffer. But isn't "performances" the point of React? As I understand things, people were moving from AngularJS to React because the virtual DOM was supposed to be the most performant technique to handle UI mutation and rendering. So what is the reality behind the supposed speed of React ?
Performance was never the point of React.
The point is to be able to (from a developer's point of view) re-render "everything", with every change, top down, without having to worry about the details. Doing that normally would be horribly slow, so React makes it adequately fast.
So it's not "super mega high speed lib". It's "Gives you the ability to have a function which, given argument, renders an entire app, and can be called over and over and over" at pragmatic speed, allowing for easier code to reason about.
If your primary goal is performance above all else, it's actually not that great a library.
Re: Inferno: A fast, React-like JavaScript library for building UIs
#75At the risk of beating a dead horse, we are only fueling the flames of javascript fatigue by churning out these "It's like X, but with more/less cowbell" libraries. We need to stop fragmenting and start doubling down on existing libraries.
Creating new things is sometimes the only or most efficient way of experimenting with new ideas, features and techniques. And if they're really good, other libraries or frameworks can consider implementing them. The beauty of open source.
Re: Inferno: A fast, React-like JavaScript library for building UIs
#76React, so great people are already re-writing it.
Re: Inferno: A fast, React-like JavaScript library for building UIs
#77At the risk of beating a dead horse, we are only fueling the flames of javascript fatigue by churning out these "It's like X, but with more/less cowbell" libraries. We need to stop fragmenting and start doubling down on existing libraries.
API compatible or near compatible drop in replacements are a good thing though. The way we can have new things without needing to rewrite everything. The only issue with this one is the lack of context API, which is needed for a lot of third party integrations, like react-redux. If it wasn't for that, it wouldn't be a problem at all.
> it wouldn't be a problem at all
I have trouble believing this is true in the long-run. There are several examples that seem contrary to this idea.
Lodash was supposed to be a drop-in replacement for underscore, and that was fine and all until contributors felt like they had to duplicate any new features into both libraries. On the bright side, this lead to their upcoming merger, but not without years of wasted effort duplicating work and ink spilled arguing over which was better. You could argue that underscore could have been more willing to merge in more-performant implementations (though I think they preferred readability over speed), but it seems like this fork-first mentality in the JS world somehow makes that almost looked down upon.
Others like Zepto or other jQuery-alikes seem to reach moderate uptake at best but don't necessarily move the community forward either.
Ultimately it seems like the best you can hope for is to get enough attention / stir up enough of a hornet's nest / make dual-contributors lives hard enough to then get merged back in to the original library, and it seems like this is much more pronounced in the JS community[0]. But looking at Node vs IO, CoffeeScript vs JS, or other like-X-but-better situations[1], it sure seems like more community input into and improvement of the already existing frameworks would go a long way.
0: I'm totally willing to admit that JS is one of the things I spend more time doing so I just might notice it more. 1: I know there are nuances to these situations, but I'm being a little reductionist, and they were still stand up to the point.
Re: Inferno: A fast, React-like JavaScript library for building UIs
#78I'm trying hard to figure out why someone want to use something like this or React, when vanilla HTML, CSS and JavaScript seems much easier and more performant. The only thing I can think of is that appendChild is a bit tedious, but createClass seems even more boilerplate.
> I'm trying hard to figure out why someone want to use something like this or React There are many reason why one would want to use framework X,Y,Z instead of writing his own (because at the end of the day, any large application will need some form of framework/toolkit to be maintainable). The first reason I guess is that in practice the code you depend on is the code you don't have to maintain and test. The second…
I think you are on to something. When you have hundreds of (front end) developers working on the same UI, refactoring becomes more of a people management problem then a programming problem. And something like React would help in such circumstances. So I can imagine how it would be useful for Facebook. But not the average small team or solo dev.
Re: Inferno: A fast, React-like JavaScript library for building UIs
#79At the risk of beating a dead horse, we are only fueling the flames of javascript fatigue by churning out these "It's like X, but with more/less cowbell" libraries. We need to stop fragmenting and start doubling down on existing libraries.
API compatible or near compatible drop in replacements are a good thing though. The way we can have new things without needing to rewrite everything. The only issue with this one is the lack of context API, which is needed for a lot of third party integrations, like react-redux. If it wasn't for that, it wouldn't be a problem at all.
A naive question: how often are replacements ever dropped in?
Re: Inferno: A fast, React-like JavaScript library for building UIs
#80At the risk of beating a dead horse, we are only fueling the flames of javascript fatigue by churning out these "It's like X, but with more/less cowbell" libraries. We need to stop fragmenting and start doubling down on existing libraries.
> we are only fueling the flames of javascript fatigue
The majority of people I have seen complaining about Javascript fatigue do it from the peanut gallery. If you are a Javascript developer: you shouldn't have javascript fatigue unless you chase after the latest and greatest - which you shouldn't do. If you do not experience have "cereal fatigue" at the supermarket, you shouldn't get Javascript fatigue either.
It took me all of 30 seconds to skim the home page and to conclude "hmm, I don't need this now", but I've filed it at the back of my mind should I require it some day (I might not remember the name then, but I'll be able to figure out the search keywords).
> We need to stop fragmenting and start doubling down on existing libraries.
I reject this sentiment. You can't force people to contribute to projects they have no passion for. You also can't prevent people from scratching their own itch and registering a domain for their slightly different flavor-of-the-week JS project. Best you can do is ignore them or support them. The undeserving will wither eventually, you do not owe any project your attention.