Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Inferno: A fast, React-like JavaScript library for building UIs

github.com

Post reply on HN
Print view View original

111–120 of 128 posts

Re: Inferno: A fast, React-like JavaScript library for building UIs

#111

Post by mercurial »

zghst wrote: post #92
shados wrote: post #74

Earlier quoted context omitted.

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…

That whole goal was performance driven...

What makes you say that?

Re: Inferno: A fast, React-like JavaScript library for building UIs

#112

Post by nippur72 »

timdorr wrote: post #37
nippur72 wrote: post #25

Earlier quoted context omitted.

I've just opened the GitHub repo and I see no trace of TypeScript, no .ts files anywhere

Wrong branch. Check 0.8-dev: https://github.com/trueadm/inferno/tree/0.8-dev/src

fine, thanks. TypeScript makes it even more interesting. I am going to make some tests to see if Inferno can replace React when working with react-templates.

Re: Inferno: A fast, React-like JavaScript library for building UIs

#113

Post by marcus_holmes »

sotojuan wrote: post #98
knite wrote: post #94

Earlier quoted context omitted.

Member of the peanut gallery here, and I fully agree with Renner1. I occasionally do front end development work, and the pace of change makes life very difficult. Imagine someone who last wrote a Python/Ruby/C/Java application 5 years ago - they could hit the ground running and learn a few new best practices and tools in 1-2 new weeks. Compare that to someone who wrote a JS app 1-2 years ago - they have months of cat…

It's because the things people do in the frontend are very different now than 5 years ago. People forget SPAs and modern frontends are very new and in their infancy... of course they change quickly. > Compare that to someone who wrote a JS app 1-2 years ago - they have months of catching up to do. 1-2 years ago I'd randomly guess they were using basic jQuery, Backbone, or Angular 1.x... which still work fine. Don't s…

Visual Basic still works fine. Doesn't mean it's a practical solution to building stuff.

Re: Inferno: A fast, React-like JavaScript library for building UIs

#114

Post by davidpatrick »

z3t4 wrote: post #73
dangoor wrote: post #58

Earlier quoted context omitted.

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…

But you CAN get rid of React and not have to rewrite your whole app. Redux, for example, isn't coupled with React at all. React-Redux gives you the tools you need to tie the two together, but you could easily take your Redux code (reducers, actions creators, selectors) with you to a new framework like Angular 2.

Re: Inferno: A fast, React-like JavaScript library for building UIs

#115

Post by seang »

coldtea wrote: post #100
sangnoir wrote: post #80

Earlier quoted context omitted.

> 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 t…

> The majority of people I have seen complaining about Javascript fatigue do it from the peanut gallery. You'd be surprised. In any case, my anecdotal experience has been different: both me, and other front-end developers I know, have been frustrated with the pace of change in JS libraries and tooling. > If you are a Javascript developer: you shouldn't have javascript fatigue unless you chase after the latest and gre…

Rails and Django are back-end; a good analogy there would have been Node.js which, as a framework, has done little but expand its API, implement ES6 features, and improve performance.

Comparing back-end frameworks to front-end is silly; there are entirely different concerns on each level. Or is Rails suddenly diffing DOM elements?

Re: Inferno: A fast, React-like JavaScript library for building UIs

#116

Post by sangnoir »

coldtea wrote: post #100
sangnoir wrote: post #80

Earlier quoted context omitted.

> 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 t…

> The majority of people I have seen complaining about Javascript fatigue do it from the peanut gallery. You'd be surprised. In any case, my anecdotal experience has been different: both me, and other front-end developers I know, have been frustrated with the pace of change in JS libraries and tooling. > If you are a Javascript developer: you shouldn't have javascript fatigue unless you chase after the latest and gre…

> You don't have to chase the "latest and greatest" to feel the fatigue. Merely keeping up with what's considered "best practice" and avoiding what's considered a dead-end and people abandon is enough

Sounds like the same thing to me - you can deal with this in 2 easy steps: 1) Ignore the hype 2) Ignore the hype. Best practices for who? Facebook's "best practices" might not work for you. You can't blame external circumstances for your technology churn, especially if the "dead-end" technologies are still actively maintained. "Best practices" are just design by committee writ large. I still use Grunt rather than Gulp, for me the 'improvemements' are marginal. I still support a Dojo SPA even though it's considered ancient. These technology decisions are not considered best practices, but they work for me. The buck stops with you (or whoever makes tech decisions at your org) - you can't pass the blame to the larger JavaScript community.

My point is you can safely ignore the latest and greatest (or 'best practice' as you call it). Apply common sense and only use what you need.

Speaking of hype: aren't containerized Flask-based microservices the current 'best practice' rather than monstrous Django apps? Looks like your 2006-era technology won't cut it on the back end either - it's all about scalability now ;)

Edit: added text below this line

> Too much choice leads to fatigue and stress in itself -- and this is backed by science

This is not inherently bad in any way: it's a trade-off. The paradox of Choice states that choice decreases (present) happiness. If this is what you are optimizing for, then less choice is good. Unfortunately, large and complex systems are...complex and multifaceted. I'm willing to sacrifice a little happiness in the present for ease of maintainability (when choosing a library that better fits my needs). Nature itself seems to celebrate choice when it comes to genetics in sexually reproducing organisms. Diversity has it's benefits -- and this is also backed by science.

Re: Inferno: A fast, React-like JavaScript library for building UIs

#117

Post by trueadm »

JSQuagmire wrote: post #108
skrebbel wrote: post #105

Earlier quoted context omitted.

I dont understand. Afaict, MPL only requires you to publish the changes you make to MPL'ed libraries, not all source that uses it. Why does that stop you from using Inferno?

It is the difference between amending documentation (MIT) and producing infrastructure (MPL/LGPL) to ensure that whatever is currently in-tree and covered by the license is exactly what is available for download in the event anyone ever patches it... else you are out of compliance. It isn't just changes, either, it's the files in their entirety.[1] In a perfect world, no company would balk at having a GitHub account…

Thanks for filling me in on the details of MIT vs MPL. I'll switch over to MIT now that I know this.

Re: Inferno: A fast, React-like JavaScript library for building UIs

#118

Post by coldtea »

sangnoir wrote: post #116
coldtea wrote: post #100

Earlier quoted context omitted.

> The majority of people I have seen complaining about Javascript fatigue do it from the peanut gallery. You'd be surprised. In any case, my anecdotal experience has been different: both me, and other front-end developers I know, have been frustrated with the pace of change in JS libraries and tooling. > If you are a Javascript developer: you shouldn't have javascript fatigue unless you chase after the latest and gre…

> You don't have to chase the "latest and greatest" to feel the fatigue. Merely keeping up with what's considered "best practice" and avoiding what's considered a dead-end and people abandon is enough Sounds like the same thing to me - you can deal with this in 2 easy steps: 1) Ignore the hype 2) Ignore the hype. Best practices for who? Facebook's "best practices" might not work for you. You can't blame external circ…

>Sounds like the same thing to me - you can deal with this in 2 easy steps: 1) Ignore the hype 2) Ignore the hype.

And then you end with abandoned npm dependencies and no new development/books/blogs/tutorials after a short while.

Re: Inferno: A fast, React-like JavaScript library for building UIs

#119

Post by coldtea »

seang wrote: post #115
coldtea wrote: post #100

Earlier quoted context omitted.

> The majority of people I have seen complaining about Javascript fatigue do it from the peanut gallery. You'd be surprised. In any case, my anecdotal experience has been different: both me, and other front-end developers I know, have been frustrated with the pace of change in JS libraries and tooling. > If you are a Javascript developer: you shouldn't have javascript fatigue unless you chase after the latest and gre…

Rails and Django are back-end; a good analogy there would have been Node.js which, as a framework, has done little but expand its API, implement ES6 features, and improve performance. Comparing back-end frameworks to front-end is silly; there are entirely different concerns on each level. Or is Rails suddenly diffing DOM elements?

>Comparing back-end frameworks to front-end is silly; there are entirely different concerns on each level. Or is Rails suddenly diffing DOM elements?*

There's nothing "silly" about it. If anything, this arbitrary distinction is silly.

It's still all frameworks.

Whether they are front-end or back-end doesn't matter one iota to whether they could (or should) be stable.

There's nothing about "diffing DOM elements" (or any other thing front-end frameworks do) that necessitates tons of new and redesigned frameworks each going about it in its own way. In fact it could be retrofitted to an existing framework with care for backwards compatibility -- if only more JS frameworks were like Ember.

It's not a matter of some inherently technical concerns making the backend more stable. It's just the JS community churning out new frameworks and redesigned stuff all the time (because it's easy, and because they're many more millions that Python or Ruby programmers).

It's not even JS getting more features with ES6/7 (Python got tons of new features and syntax since early Django but you still don't get the same framework churn. Heck, Django even works with 3 -- and all only with tiny incremental changes to the same framework over many releases).

Re: Inferno: A fast, React-like JavaScript library for building UIs

#120

Post by JSQuagmire »

trueadm wrote: post #117
JSQuagmire wrote: post #108

Earlier quoted context omitted.

It is the difference between amending documentation (MIT) and producing infrastructure (MPL/LGPL) to ensure that whatever is currently in-tree and covered by the license is exactly what is available for download in the event anyone ever patches it... else you are out of compliance. It isn't just changes, either, it's the files in their entirety.[1] In a perfect world, no company would balk at having a GitHub account…

Thanks for filling me in on the details of MIT vs MPL. I'll switch over to MIT now that I know this.

Fantastic, thank you so much for the hard work!
Post reply on HN