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

51–60 of 422 posts

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

#51

Post by geon »

colordrops wrote: post #43
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…

I don't know about others but I tire of these comments chiding the "out of control" front-end ecosystem. The situation has already changed years ago. We aren't going to get off of your lawn while you continue to beat a dead horse. The web is built on open standards and there are billions of pages and apps out there. To expect web development to be a perfect monoculture is a failure of your imagination and ability to…

Javascript fatigue fatigue.

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

#52

Post by user5994461 »

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…

Let's advocate the other extreme. Get back to mainframe and Cobol. No more fuckups dealing with endless changes. No more need to deal with youngsters and their framework of the year.

Of course, it comes with its own issues, but you'll be blind to them for the first few years while you enjoy the cure of stability :D

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

#53

Post by kerkeslager »

colordrops wrote: post #43
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…

I don't know about others but I tire of these comments chiding the "out of control" front-end ecosystem. The situation has already changed years ago. We aren't going to get off of your lawn while you continue to beat a dead horse. The web is built on open standards and there are billions of pages and apps out there. To expect web development to be a perfect monoculture is a failure of your imagination and ability to…

Monocultures develop because one tool is far better than all the others.

Javascript isn't a monoculture because all the tools are bad.

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

#54

Post by user5994461 »

melq wrote: post #47
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…

Why is an active ecosystem with healthy competition a bad thing? Personally, I can't stand javascript, and why you'd ever elect to use it for backend/server side code mystifies me. So I don't use it (or work in web development), and couldn't care less about what platform the hip web devs deem acceptable.

healthy competition is robust and tested. A short fade that's gonna be abandoned within a year or so doesn't quality as healthy competition.

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

#55

Post by camus2 »

acemarke wrote: post #40
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…

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…

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

Actually, Java, C++,QT and co are going through great length to make development simpler and all the compilation pipelines easier. Let's take Java for instance, groovy, maven and war packaging considerably made Java server development easier. Java frameworks like Spring are trying very hard to make servlet development easier, by making complexity opt-in. Java is getting constructs like modules which will help with library development, C++ too, QT is streamlining its API ... So I'd totally disagree about your statement. The success of Go yet another proof of this. People are tired with unnecessary complexity and are ready to give up on "elegance" for the sake of simplicity.

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

#56

Post by adventist »

kccqzy wrote: post #46
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…

It's quite possible to use react with nothing else: no build tools, no transpilers, no fancy JSX, so in terms of tooling complexity, it can be as simple as you want or as complex as you want. Regarding the complexity of the underlying system, I think this is not a concern of the typical frontend developer. It has nothing to do with JavaScript or the web. If you are writing a "simple" C program on Linux, would you be…

Any resources you can provide about how to use React without JSX? JSX is a blocker for me.

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

#57

Post by andr3w321 »

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.

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

#59

Post by truncate »

acemarke wrote: post #21
danappelxx wrote: post #20

Sorry, it wasn't entirely clear to me from the article. Is React Fiber going to be a completely new project, or is it just a name for the new release? It seems like the latter to me since there's no API changes...

It's a rewrite of the internals, particularly the diffing/reconciliation algorithm. React Fiber involves effectively re-implementing the JS call stack using a data structure called "fibers" to track work that needs to be done.

It seems like what HopJS does to handle tail calls[1]. It is essentially a trampoline if I understood the docs correctly.

[1] https://pdfs.semanticscholar.org/d10d/aba5df8b4c563b62fd01a3...

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

#60

Post by braveo »

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…

I was having a similar discussion just today.

I was told I should be using swagger, and upon learning more about I started asking why they didn't just build tooling around WSDL. I couldn't see anything enabled by Swagger that isn't enabled by WSDL.

About the only thing I could think of was simplicity due to it being more specialized than WSDL.

I was told javascript can consume swagger easier, which may be true, but I don't know why that's a significant problem with WSDL seeing as how you could autogenerate the javascript interfaces anyway.

I still can't really wrap my head around what problem Swagger is solving that wasn't already solved by WSDL.

Post reply on HN