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.
> 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.
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.
Alternatively we need to start making optional frameworks. Essentially a way to do many of the usual things you use a framework for (like model binding) but will work, without changing the code, when using just about any framework.
I hate taking the basic things that are not hugely different in concept and workflow but end up using very different code so I can't port it between frameworks. Working on the start of this in my msngr.js library (shameless plug) because I would like to use it but also because I think it's important.
A new framework every couple of weeks is daunting but okay. Not being able to reuse code between them is awful.
We 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)
-es2015 syntax with JSX and inheritance
-Intellisense support in IDEs (webstorm) no custom riot syntax
- Future proof syntax without worrying low level API changes
Negative things:
-It took for a while to recode all our components in JSX
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?
Benefit I saw to Riot was that my app's minimized size was one third what it was with React. And not to mention RiotJS was so much simpler than React...
Shameless plug, I know, but I bet Inferno doesn't come close to my latest framework when it comes to the notorious task of writing a TODO app: https://github.com/ErikWittern/TODOit
"Non-performant features have been removed or replaced where an alternative solution is easy to adopt without too many changes." Sound for me like preact (https://github.com/developit/preact)
Same code can run on the server too (node.js) not just in the browser, so it's possible to make search engine friendly page that can work even without client-side JavaScript.
Events + callbacks are great for keeping with the conventions of the existing (ancient) DOM APIs, but I was hoping that a new, 'modern' framework would be a little more ambitious by making everything promise-based.
I'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.
Why? In a large part, it's because writing reusable components in React makes a world of difference AND is a lot more readable. The jQuery code was a mess of accessing DOM elements and was liable to break without warning when updating the HTML.
The other thing is that it's much easier to write a functional, complex UI. React will attach and detach listeners for you, will create and delete elements, etc. You are not going to be writing lots of hard-to-read boilerplate in onClick handlers. Finally, combined with something like Redux, you get a single-source-of-truth backing the UX, which avoids a lot of the issues I've seen in other jQuery codebases, where there are race conditions between various components during initialization.
It's a completely different way of writing a UI, but I don't see myself going back to the traditional paradigm.
> The only thing I can think of is that appendChild is a bit tedious, but createClass seems even more boilerplate.
You can't compare the two. A component is made of any number of HTML elements and other components, it's not like you are going to use createClass every time you need to want to display a span.
> 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 reason is politics. You work with 50 engineers. You decide to write your own toolkit. I'm pretty sure you'll end up having endless debates about what is the right architecture. Now if you tell the rest of your team or the management "Facebook/Google is using that, they can't be wrong", It can save a lot of time.
The third reason is "laziness". Many "engineers" using React or AngularJS actually don't know how the DOM really work, like many people only know jQuery and not standard DOM API in order to perform a task, or many "engineers" don't know how to write CSS so they use Bootstrap. Yet the same engineers are writing 1 million dollars SPA for Fortune 500 companies ...
Frameworks are a trade-off. By learning one, you expect the investment to save you time, maintenance cost and not to be leaky(i.e. not having to understand the internals of a framework in order to use it). In an era where engineers are asked to be backend engineers, front end engineers, DBA, UX/UI specialist,data analysts, statisticians, server administrators, to know the OSI model from top to bottom,to know 10 languages with 5 years of professional experience in each of them and what not, some engineers don't consider learning the fundamentals of the DOM a worthy investment.
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.
One major difference being that Vue.js doesn't really quite support TypeScript even with d.ts files provided. It will work only to a point until things fail to typecheck due to generative aspects of Vue's API.[1]
I think a useful comparison is taking a look at t7[2], trueadm's template library. Last I knew, it wasn't ready for use with Inferno yet, but that is a peek at the direction it is heading. It's rather similar to Vue's templates minus the v-directives magic in favor of leveraging JS for things like control flow.
I'm not 100% sure I'm sold on it, myself, as I rather like beating out Vue templates in Jade rather than doing everything in JavaScript with template strings. That being said, I haven't directly tried to implement anything with Inferno or t7 yet to turn in an informed opinion on working with it.
Inferno is one of the few other library than Vue I'd even bother looking at, however, at this point in time. They both aren't horribly bloated, are rather quick and have a mostly sane model to work with. Cito.js[3] is also interesting and works with t7, if you're looking for even less frills.
It is also worth noting that if you care about licenses, Vue is MIT and Cito.js and Inferno are using a much more heavily restrictive license, MPL 2.0, which will matter if you're a commercial developer doing standalone apps. For this reason alone I have to throw Inferno and Cito.js into the trash at work.
This was a problem I was trying to solve as well and theres a pretty elegent solution that this project has implemented partly already. The "render to string" is also a proof of concept that the indicates "unknown" types can be fullfilled by a "renderer". So long as he allows generic "renderers". Within a more free form environment like nativescript[
1], this library can be one of any that can be used. I was planning to implement blessed and nativescript uis but these can often be very painstaking tasks. If the developers on this project are committed, the sky is the limit!
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.
As a curiosity, how do we feel about changing the names of the lifecycle methods from "lifeCycleEvent" to "onLifecycleEvent"? Looks like a lot of stuff is pretty transparently portable from React code, I think it's curious this got changed.
TypeScript not only helped improve Inferno's with quality and read-ability of code. It can potentially help produce highly optimal output (bundles) with Google's Closure Compiler. In the future it may even help created optimised WebAssembly output. It's an exciting time :)
The fact is that React is extrodinaitilly bloated, you can only have one instance in a single environment and you are highly dependent on using libraries that are forks in order to target new environments (like native, blessed or rbg).
React isnt some God given wheel that needs no fixing. Competition is a great thing to have
Please don't comment like this here! HN comments need to be civil and substantive—especially in response to new work, which is so easy to dismiss. And personal attacks are right out.
@original question. Did you read the github? It is clearly stated what the intentions are. Mainly performance related achieved through being able to only diff renders that have dynamic values. So if you are having trouble with performance and are pretty sure it's not your code but the framework, inferno might solve it.
[+] [-] Renner1|9 years ago|reply
[+] [-] sangnoir|9 years ago|reply
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.
[+] [-] SkyMarshal|9 years ago|reply
[+] [-] shados|9 years ago|reply
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.
[+] [-] BinaryIdiot|9 years ago|reply
I hate taking the basic things that are not hugely different in concept and workflow but end up using very different code so I can't port it between frameworks. Working on the start of this in my msngr.js library (shameless plug) because I would like to use it but also because I think it's important.
A new framework every couple of weeks is daunting but okay. Not being able to reuse code between them is awful.
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] Havunen|9 years ago|reply
After moving to Inferno following things have improved:
-We are unit testing components -Performance!!! (No delays/lagging anymore) -es2015 syntax with JSX and inheritance -Intellisense support in IDEs (webstorm) no custom riot syntax - Future proof syntax without worrying low level API changes
Negative things: -It took for a while to recode all our components in JSX
--Havunen
[+] [-] Roritharr|9 years ago|reply
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?
[+] [-] leeoniya|9 years ago|reply
Can you elaborate?
Do you mean 3000 simultaneously in the DOM? Is this a grid/table where each cell is a component or something else?
[+] [-] gedy|9 years ago|reply
[+] [-] ewittern|9 years ago|reply
[+] [-] leeoniya|9 years ago|reply
I'm asking this as the author of domvm [1] and a 60 LOC todo implementation [2] that also exposes a usable API.
[1] https://github.com/leeoniya/domvm
[2] https://leeoniya.github.io/domvm/demos/todo-alt.html
[+] [-] Ghostium|9 years ago|reply
[+] [-] k__|9 years ago|reply
What did they left out?
[+] [-] psibi|9 years ago|reply
[+] [-] ghh|9 years ago|reply
[+] [-] spyder|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] CognitiveLens|9 years ago|reply
[+] [-] z3t4|9 years ago|reply
[+] [-] mercurial|9 years ago|reply
Why? In a large part, it's because writing reusable components in React makes a world of difference AND is a lot more readable. The jQuery code was a mess of accessing DOM elements and was liable to break without warning when updating the HTML.
The other thing is that it's much easier to write a functional, complex UI. React will attach and detach listeners for you, will create and delete elements, etc. You are not going to be writing lots of hard-to-read boilerplate in onClick handlers. Finally, combined with something like Redux, you get a single-source-of-truth backing the UX, which avoids a lot of the issues I've seen in other jQuery codebases, where there are race conditions between various components during initialization.
It's a completely different way of writing a UI, but I don't see myself going back to the traditional paradigm.
> The only thing I can think of is that appendChild is a bit tedious, but createClass seems even more boilerplate.
You can't compare the two. A component is made of any number of HTML elements and other components, it's not like you are going to use createClass every time you need to want to display a span.
[+] [-] spriggan3|9 years ago|reply
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 reason is politics. You work with 50 engineers. You decide to write your own toolkit. I'm pretty sure you'll end up having endless debates about what is the right architecture. Now if you tell the rest of your team or the management "Facebook/Google is using that, they can't be wrong", It can save a lot of time.
The third reason is "laziness". Many "engineers" using React or AngularJS actually don't know how the DOM really work, like many people only know jQuery and not standard DOM API in order to perform a task, or many "engineers" don't know how to write CSS so they use Bootstrap. Yet the same engineers are writing 1 million dollars SPA for Fortune 500 companies ...
Frameworks are a trade-off. By learning one, you expect the investment to save you time, maintenance cost and not to be leaky(i.e. not having to understand the internals of a framework in order to use it). In an era where engineers are asked to be backend engineers, front end engineers, DBA, UX/UI specialist,data analysts, statisticians, server administrators, to know the OSI model from top to bottom,to know 10 languages with 5 years of professional experience in each of them and what not, some engineers don't consider learning the fundamentals of the DOM a worthy investment.
[+] [-] dangoor|9 years ago|reply
[+] [-] izym|9 years ago|reply
[+] [-] tacone|9 years ago|reply
[+] [-] xaduha|9 years ago|reply
https://github.com/developit/preact
https://gitlab.com/Rich-Harris/buble
my app.min.js.gz is 6.2K for some basic stuff including preact-router
https://github.com/developit/preact-router
[+] [-] leeoniya|9 years ago|reply
https://github.com/trueadm/inferno/blob/master/packages/infe...
https://github.com/trueadm/inferno/blob/master/packages/infe...
[+] [-] ausjke|9 years ago|reply
[+] [-] JSQuagmire|9 years ago|reply
I think a useful comparison is taking a look at t7[2], trueadm's template library. Last I knew, it wasn't ready for use with Inferno yet, but that is a peek at the direction it is heading. It's rather similar to Vue's templates minus the v-directives magic in favor of leveraging JS for things like control flow.
I'm not 100% sure I'm sold on it, myself, as I rather like beating out Vue templates in Jade rather than doing everything in JavaScript with template strings. That being said, I haven't directly tried to implement anything with Inferno or t7 yet to turn in an informed opinion on working with it.
Inferno is one of the few other library than Vue I'd even bother looking at, however, at this point in time. They both aren't horribly bloated, are rather quick and have a mostly sane model to work with. Cito.js[3] is also interesting and works with t7, if you're looking for even less frills.
It is also worth noting that if you care about licenses, Vue is MIT and Cito.js and Inferno are using a much more heavily restrictive license, MPL 2.0, which will matter if you're a commercial developer doing standalone apps. For this reason alone I have to throw Inferno and Cito.js into the trash at work.
[1]: https://github.com/vuejs/vue/issues/478
[2]: https://github.com/trueadm/t7
[3]: https://github.com/joelrich/citojs
[+] [-] amelius|9 years ago|reply
[+] [-] formula1|9 years ago|reply
[1] https://www.nativescript.org
[+] [-] elliotec|9 years ago|reply
[+] [-] trueadm|9 years ago|reply
[+] [-] drdaeman|9 years ago|reply
[+] [-] edoceo|9 years ago|reply
[+] [-] FLGMwt|9 years ago|reply
[+] [-] aeosynth|9 years ago|reply
Can this be expanded? If/when the intelligent diffing fails, I'd like to know how to fix it.
[+] [-] formula1|9 years ago|reply
Was doing something similar for a while. Very cool stuff! Excited to see where you take it!
[+] [-] Keats|9 years ago|reply
[+] [-] trueadm|9 years ago|reply
[+] [-] jyriand|9 years ago|reply
[+] [-] ajro|9 years ago|reply
[+] [-] padseeker|9 years ago|reply
[deleted]
[+] [-] formula1|9 years ago|reply
React isnt some God given wheel that needs no fixing. Competition is a great thing to have
[+] [-] elliotec|9 years ago|reply
[+] [-] marshalltony|9 years ago|reply
[deleted]
[+] [-] dang|9 years ago|reply
We detached this from https://news.ycombinator.com/item?id=11837303 and marked it off-topic.
[+] [-] bastijn|9 years ago|reply
@original question. Did you read the github? It is clearly stated what the intentions are. Mainly performance related achieved through being able to only diff renders that have dynamic values. So if you are having trouble with performance and are pretty sure it's not your code but the framework, inferno might solve it.
[+] [-] shiftoutbox|9 years ago|reply
[deleted]