So who will be the ass hat who makes plan9 the js library , that like inferno but with ....
Inferno: A fast, React-like JavaScript library for building UIs
91–100 of 128 posts
Re: Inferno: A fast, React-like JavaScript library for building UIs
#92Earlier quoted context omitted.
> 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…
That whole goal was performance driven...
Re: Inferno: A fast, React-like JavaScript library for building UIs
#93Earlier quoted context omitted.
Performance is not the point of React. Predictability is. Bunches of bugs are eliminated and others are easier to find.
> Bunches of bugs are eliminated and others are easier to find. Got a link to the research for that? My pet peeve is unsubstantiated bullshit claims. We let sooooo much nonsense fly, especially in JS land.
You can ask for research and proof sure, but it should be very intuitive that a delcarative, "re-render everything from props and state with a call to setState()" system is less error prone than the two way binding digest mess that is angular, or manual dom manipulations for that matter.
Reminder: VirtualDOM is just an optimization of the rerender everything problem.
Re: Inferno: A fast, React-like JavaScript library for building UIs
#94At 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…
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 catching up to do. It feels like the JS landscape is changing so fast that keeping up with things is a full-time job.
Re: Inferno: A fast, React-like JavaScript library for building UIs
#95Earlier 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…
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…
This situation is way better than everyone having an in-house "library" that you have to learn, which is what it seemed like what happened a few years ago (it would be something in house, layered on top of jQuery or whatever).
Re: Inferno: A fast, React-like JavaScript library for building UIs
#96Earlier 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…
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…
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 of these instances, while there was some library and language churn, it was pretty easy to pick up. C++ lambdas are just cleaner syntax for functors, and the better optimizers and reworked libraries mean they're more widely usable, but no big deal. Java has a streaming library now and lambdas of its own, but it's largely syntax sugar, and even if Grade has largely replaced Maven, the concepts and issues are roughly identical. Bundler was new to me, but why it existed was transparent and its relationship to gems was clear, so only an hour or so of work was enough to get me up to speed. I assumed web work would be similar.
I felt like I was relearning from scratch. jQuery was gone; use anything else. There are several different build systems, all slightly incompatible with each other, to replace YUI compressor and Closure. Prototypes are gone, classes are in. Underscore is gone, and a richer class library is in, but it's not widely supported, so you have to cross compile, for which you need source maps. Some best practices became worst (shove all the JS into one file is the new hotness), but apparently may go to worst (fracturing is better due to HTTP/2 push).
I have actually seen this before: Windows, as it switched from the 3.1/95 series to the COM-heavy NTs, had churn like this. So did Carbon to Cocoa, and arguably Cocoa prior to 10.3 and after, and again once ARC was introduced. But those were single events, whereas this seems, from where I sit, to be a sustained burn.
Re: Inferno: A fast, React-like JavaScript library for building UIs
#97Earlier 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…
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 value, but the value is greatly overhyped for projects that are not Facebook or Google sized. Virtual dom, Promises, rAF, Canvas, CSS3, new web APIs are definitely worth learning because they provide huge value and will be around for a long time. There has certainly been a shift towards declarative/functional/immutable paradigms in JS but that doesnt mean it works better for all cases.
Might as well do a shameless plug here. If you don't want to learn the current hotness-of-the-month. I've written domvm [1] to be small, fast, fully free from dependencies and build/tooling requirements. It uses virtual dom concepts under the hood, so you get the benefits of both declarative templates and imperative views in pure JS and a very small learning curve.
Believe me when I tell you that you can still write complex-yet-maintainable, performant web-apps with just your browser and vim/notepad w/syntax coloring.
If you're looking to be employable, though, you'll probably need to learn Angular/React/Vue and everything that comes with them ;)
Re: Inferno: A fast, React-like JavaScript library for building UIs
#98Earlier 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…
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 see the problem here.
Re: Inferno: A fast, React-like JavaScript library for building UIs
#99What is the difference comparing to vuejs?
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.
Re: Inferno: A fast, React-like JavaScript library for building UIs
#100At 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…
>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 greatest - which you shouldn't do.
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.
Case in point, it's only 5 years since Backbone came out. Backbone! And if feels like we've had 3-5 transitions already (Angular. No wait, Ember. No React. Oh, and add Flux. Actually, go Redux.). In Python or Ruby I could still use the Rails and Django I learned in 2006 -- not so much with JS.
>If you do not experience have "cereal fatigue" at the supermarket, you shouldn't get Javascript fatigue either.
Only people have (cereal fatigue). Too much choice leads to fatigue and stress in itself -- and this is backed by science...