Live data from Hacker News

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

github.com

101–110 of 128 posts

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

#101
post #96

Earlier quoted context omitted.

I actually just went through this myself. I had last done frontend work in about 2010, maybe a little in 2011, and realized my skill set was probably getting stale, so I asked my boss if I could do frontend for a bit, with the understanding that I'd underperform. He said sure. I've left and returned to C++ a couple of times. Same for Java. Most recently, I did some Ruby dev in 2015 after last doing it in 2006. In all…

It really depends on what your goal is. You don't need to buy into any of it and still write high quality software. Concat & minify is still there like it always was (what tools you use to get this done is really irrelevant). You don't need to use Node, NPM, webpack, rollup, babel/buble or classes because today that means you're obligated to use all the tooling and compilation. Not to say that these things dont add v…

>It really depends on what your goal is. You don't need to buy into any of it and still write high quality software.

Unless you also make the decisions at the company you work for, no you really can't.

What you said only applies to people making those decisions for their teams or working alone. Others are at the mercy of whatever BS du jour they'll be asked to code in.

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

#102

Earlier quoted context omitted.

It really depends on what your goal is. You don't need to buy into any of it and still write high quality software. Concat & minify is still there like it always was (what tools you use to get this done is really irrelevant). You don't need to use Node, NPM, webpack, rollup, babel/buble or classes because today that means you're obligated to use all the tooling and compilation. Not to say that these things dont add v…

> It really depends on what your goal is. You don't need to buy into any of it and still write high quality software. Unless you also make the decisions at the company you work for, no you really can't. What you said only applies to people making those decisions for their teams or working alone. Others are at the mercy of whatever BS du jour they'll be asked to code in.

Good point. But if you come to a team where the environment is already set up for you, then at least you avoid the headache of choosing/debugging every nut and bolt of the system just to begin writing code.

If you're in a position to define the stack, you have to weigh the benefits vs churn very carefully.

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

#103
post #69

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

OP's not forcing anyone to do anything. Just suggesting that contributing to an existing project with traction might be more useful.

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

#104
post #78

Earlier quoted context omitted.

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

I would be surprised if there was a even one single example of "hundreds of (front-end) developers working on the same UI".

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

#105

Earlier quoted context omitted.

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

ah thank you for the summary of the licences. that moves inferno off the table for me too. sadly though, cause I was really getting interested with it being written in typescript.

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?

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

#106
post #47

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.

We moved from HTML + jQuery to React.

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.

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

#107
post #104
post #78

Earlier quoted context omitted.

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.

I would be surprised if there was a even one single example of "hundreds of (front-end) developers working on the same UI".

Maybe not simultaneously, but over time?

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

#108

Earlier quoted context omitted.

ah thank you for the summary of the licences. that moves inferno off the table for me too. sadly though, cause I was really getting interested with it being written in typescript.

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 and having a public fork available, but many companies out there right now are still rather conservative about these things. Some barely use source control. MIT is simply one of the easiest licenses for these places to comply with. In my personal experience working at unglamorous places like these, they're fine returning patches as long as they never have to think about the legal implications or feel like there's a burden for using the code in the first place.

The MPL is a poor choice for this sort of code because it makes the assumption that distribution is a given and will happen automatically, but if you're doing application development rather than web development that simply is not true that the code will always be a 'View Source' away. There are certainly applications where this license would be more appropriate, but I do not think an isomorphic vDOM library would be one of them, since this is rather foundational glue.

It would be rather nice if trueadm would reconsider, if possible.

[1]: https://www.mozilla.org/en-US/MPL/2.0/

[1a]: https://tldrlegal.com/license/mozilla-public-license-2.0-%28...

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

#109
post #55

Quite honestly my problem with react is the gzipped size, not the performance. What's the size of the browser bundle of this library?

Look into preact + buble ES2015 compiler then, should be small enough

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

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

#110

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…

Yes, and even within a framework... investing in using for example React for a project and some plugs, come back to project a couple of months later to add some library for let's say graphs, and face need to upgrade every lib/plug and lots of version mismatches. Not all libraries you opted to use might be compatible with new version of React.
Post reply on HN