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

Facebook Announces React Fiber, a Rewrite of Its React Framework

techcrunch.com

Post reply on HN
Print view View original

361–370 of 422 posts

Re: Facebook Announces React Fiber, a Rewrite of Its React Framework

#361

Post by ThePhysicist »

metalliqaz wrote: post #36
acemarke wrote: post #11

I'll repeat the comment I made in the "React 15.5" thread a couple weeks ago ( https://news.ycombinator.com/item?id=14063818 ): For those who are interested in some of the details of the work that's going on, Lin Clark's recent talk on "A Cartoon Intro to Fiber" at ReactConf 2017 is excellent [0]. There's a number of other existing writeups and resources on how Fiber works [1] as well. The roadmap for 15.5 and 16.0 m…

I admire your exceptional work cataloguing these resources. However, just one look at that giant horde of links is, to me, a perfect demonstration of why the front-end development ecosystem is way out of control. Its amazing to me that the autoconf/automake/libtool system for making write-once-run-everywhere *nix applications is downright simple by today's standards. Every year the hot libraries change, the build too…

There's no need to actually use all these complex tools if you don't want to. We wrote a pretty large (>20kloc) React application with a simple require.js based build flow using a Makefile that invokes a couple of tools for bundling the JS and generating assets like CSS. We used our own resource loader framework based on jquery (Redux didn't exist at the time) and a simple routing library (director.js). Still works like a charm!

In my opinion, the important thing in frontend development is to know which tools and libraries to adopt and which ones to ignore.

As a platform, I find JS+HTML5 really appealing and I'm happy that there are many ways to use and creatively remix these technologies, so I don't see the large churn in the ecosystem as a disadvantage but rather as proof that browser-based JS works very well as a platform to develop applications on.

Re: Facebook Announces React Fiber, a Rewrite of Its React Framework

#362

Post by Sacho »

douche wrote: post #304
ng12 wrote: post #301

Earlier quoted context omitted.

It's such a dumb argument that boils down to "things are changing and I don't like it!". Javascript fatigue is not real. I am completely convinced anyone who says otherwise has never had to maintain a non-trivial web application in Backbone/jQuery -- meaning they're complaining about frameworks that weren't built for their use cases.

Javascript fatigue is real. Shit in front-end land changes so fast it is impossible to keep up with. We just finished a rewrite from jQuery to Angular 1, with updates to all the tooling that goes along with it. We're now at least three years behind the curve... Hooray! Meanwhile, the backend frameworks we've been using have had one minor version Nuget package release in the same timespan.

Why did you rewrite the app from jQuery to Angular 1?

Re: Facebook Announces React Fiber, a Rewrite of Its React Framework

#363

Post by Sacho »

kerkeslager wrote: post #254
ng12 wrote: post #79

Earlier quoted context omitted.

And you are totally wrong about that. This is the most exciting time to be a web developer since jQuery first came out. I promise it only looks that way from the outside.

I am very much not looking at it from the outside. ES6 is a step backward. Prototypical inheritance was one of the few things Javascript had going for it, but because CS majors who only learned Java in undergrad couldn't be bothered to learn prototypical inheritance now we have two incompatible inheritance systems instead. Promises are minor syntactic sugar over callbacks which could be implemented as a library. Mean…

Javascript has had a Boolean type at least since ES5; I'm not sure what exactly you're trying to convey there. The lack of a Number type is pretty frustrating for many types of computation, but at least some of them are covered by typed arrays.

I'm not sure what you mean by "no decent debugger" either, there's debug tools in every browser plus quite a few for node.

"Accessing" a non-existent variable has been a ReferenceError since ES5(http://es5.github.io/#x8.7.1). Assigning to a non-existent variable has been a ReferenceError since ES5 as well, in strict mode.

What makes you dislike JavaScript so much you'd go on such a rant about it?

Re: Facebook Announces React Fiber, a Rewrite of Its React Framework

#364

Post by mlsarecmg »

mickael-kerjean wrote: post #166
andr3w321 wrote: post #57

No thanks I'll stick with plain html and jquery for the frontend of my small projects. Plain javascript works perfectly fine as long as you namespace your functions and separate them into different files. All these frameworks end up creating much more problems than they solve.

> As someone who has worked on a truly large React project, I can assure you this is not true. there's no such things as the best approach for all needs. React brings you load of advantage but it assumes stuff you might not be ok with: - spend time maintaining your project over time fixing stuff on version change that won't bring any direct value to your project - you're ok with the licence and with the company maint…

React is smaller than JQ and can go down to nothing with aliasing to react-lite, which strips off proptypes and other things.

React and Redux is the easiest debugging has ever been. While its true that stateless crashing components can cause some headaches (will be addressed in Fiber), inspecting state and flow of actions, how something rendered or changed and why --- haven't had such a experience before with no other tool or language.

Re: Facebook Announces React Fiber, a Rewrite of Its React Framework

#365

Post by danabramov »

lightblade wrote: post #352
danabramov wrote: post #346

Earlier quoted context omitted.

With the ability to pause large updates in the middle without committing them to UI, doing some higher priority updates, and then "rebasing" lower priority updates on top of them and continuing the work. So it's a bit more sophisticated.

Does Fiber yield control back to the js engine when doing the "rebasing"? Or are all of these synchronous in one frame?

Yea, it does. We are using requestIdleCallback to do the work "while we can", and then yield the control back. Again, this won't be a part of React 16, but it's part of the bigger picture we are moving towards.

Relevant code if you're curious: https://github.com/facebook/react/blob/233195cb6bc632ade61a8...

Re: Facebook Announces React Fiber, a Rewrite of Its React Framework

#366

Post by crusso »

roguecoder wrote: post #333
crusso wrote: post #213

Earlier quoted context omitted.

Elm blows me away. It's everything I saw that React was trying to do, but bound up in an actual language that has strong Haskell-ish types, is fully functional, and mind-bendingly fun to learn. Elm really could be the future of bullet-proof web development. It has everything it needs except for runaway popularity.

"Mind-bending" being presented as a feature could possibly explain the lack of popularity.

Mind-bending in a good way, like the way that Haskell lets you express constructs that you may never really have used in other languages.

Re: Facebook Announces React Fiber, a Rewrite of Its React Framework

#367

Post by bigato »

Bombthecat wrote: post #357
nightski wrote: post #50

Earlier quoted context omitted.

The benefits you acknowledge (distribution) are not because of the tech but in spite of it. At the end of the day all it would take is one of the 3 major browser vendors to offer an alternative. That alternative could be distributed to a large percentage of desktops in a relatively quick manner saving billions if not trillions of dollars in wasted productivity. It will never happen though. * EDIT: This comes from som…

Dart is shipped with chrome, or not? I don't see any huge success :)

Not anymore:

https://www.chromestatus.com/feature/6682831673622528

Re: Facebook Announces React Fiber, a Rewrite of Its React Framework

#368

Post by bigato »

nightski wrote: post #50
acemarke wrote: post #40

Earlier quoted context omitted.

Your comment seems to be a bit of a non-sequitur. Application development is complex, period. Posix development is complicated. Qt is big and complicated. Makefiles are complicated. Autotools is complicated. Big Java server apps are complicated. C++ is complicated. We've just hit the point where people are trying to do the same thing in a browser. Would you prefer to build your application using Make, Scons, Waf, CMa…

The benefits you acknowledge (distribution) are not because of the tech but in spite of it. At the end of the day all it would take is one of the 3 major browser vendors to offer an alternative. That alternative could be distributed to a large percentage of desktops in a relatively quick manner saving billions if not trillions of dollars in wasted productivity. It will never happen though. * EDIT: This comes from som…

That already happened and is called webassembly. And it is backed by not one, but all of the major browsers.

Re: Facebook Announces React Fiber, a Rewrite of Its React Framework

#369

Post by bigato »

jpk wrote: post #97
goldbeck wrote: post #61

Earlier quoted context omitted.

If this is such a good and valuable idea, why will it never happen? Seems the major internet-interface makers (Google via Chrome, FB via their app, for ex), are vying for control over the way people develop web applications too. Making an alternative that gets adopted would be invaluable to them.

It won't happen because none of them will implement the other guy's new thing. Chrome would do the Google thing, Edge would do the Microsoft thing, and Firefox would sit back and balk that none of that junk is standardized. Then webdevs would just stick with Javascript and friends because it's the only thing that mostly works everywhere. That's exactly what happened to Dart, right? It had aspirations of hopping into…

Not true, see webassembly.

Re: Facebook Announces React Fiber, a Rewrite of Its React Framework

#370

Post by wccrawford »

vrde wrote: post #349
metalliqaz wrote: post #36

Earlier quoted context omitted.

I admire your exceptional work cataloguing these resources. However, just one look at that giant horde of links is, to me, a perfect demonstration of why the front-end development ecosystem is way out of control. Its amazing to me that the autoconf/automake/libtool system for making write-once-run-everywhere *nix applications is downright simple by today's standards. Every year the hot libraries change, the build too…

The thing that backend devs don't realize is that frontend is not easy. A frontend dev builds something that will be used by a HUMAN, while a backend dev builds something that will be used by a PROGRAM. Related to the comment, things were changing a lot because there is not one single way to do things, as in iOS/Android. There is no standard imposed by a huge private company like Apple or Google. Everyone is free to…

As a fullstack dev, it amuses me when my underlings claim that backend is hard and they want to learn it. They're already doing front-end. (And yes, we're working them towards more and more backend, and even mobile.)

It's just different, IMO. Programming is programming, but different specialties have different things you need to worry about.

Post reply on HN