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

141–150 of 422 posts

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

#141

Post by leeoniya »

colordrops wrote: post #134
leeoniya wrote: post #108

Earlier quoted context omitted.

> If you can run a video game engine in the browser you can run anything no

enlighten us

ok, assuming your request is not sarcastic:

- operating systems

- hardware drivers

- a networking stack

- trading algorithms

- fighter jet firmware

- ultra low latency DSP

- processing data from LHC collisions or imaging satellites.

- etc

- etc

- etc

just because webgl enables fast gpu processing (by basically writing a small subset of C that is shader code) doesnt now mean the web platform can be used for evetything.

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

#142

Post by lobster_johnson »

braveo wrote: post #60
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 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…

The problem with WSDL, at least at its inception, was that it tied in with the whole WS-* extravaganza, a set of standards that are built on top of each other and heavily based on XML. While WSDL has evolved to support RESTful services, early WSDL was closely tied to SOAP.

The XML thing is slippery slope. Suddenly your toolchain has to be aware of namespaces, XSD schemas, and so on. It's a largeish universe of a standards that sound good on paper but don't contribute meaningfully to anyone's productivity. And XML has historically been (and still is) popular with the enterprise Java crowd — J2EE, Spring and so on — there's a pretty steep divide between that and the more agile world of web devs and startups. If you're buying into the XML stack, WSDL will seem like a nuisance more than a productivity multiplier.

That said, I don't think Swagger/OpenAPI is very good, either. It's replacing XML with YAML, and introducing its own set of issues. And the community and tooling ecosystem aren't quite there.

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

#143

Post by lobster_johnson »

davnicwil wrote: post #48
vmasto wrote: post #24

Earlier quoted context omitted.

Some of the API semantics are changing, e.g. componentWillMount can't be trusted any more (it can fire many times) but they're going to be pretty small.

Whoah, hang on, really? Do you have a source on this or somewhere I can find out more details? This will completey break a lot of libraries, components, etc that rely on the React lifecycle contracts.. Certainly doesn't feel like a small change! :-/

Fortunately, componentWillMount is largely made redundant by the use of constructors.

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

#144

Post by acjohnson55 »

paganel wrote: post #49
colordrops wrote: post #43

Earlier quoted context omitted.

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…

Not the OP, but I expect the web to be a thing where documents (i.e. mainly text) don't have any issues rendering on my 5-year old phone or on my 8-year laptop (both of which work very well, still, and which I don't plan to replace anytime soon). The recent web practices (I'm talking mostly of the last 2-3 years, since more and more people have started copying Twitter with its launch of its "every website needs to be…

A web limited to textual content is a pretty quaint and uninspiring vision, IMO.

The web started that way because static documents are relatively easy to represent, but the future (and present, for that matter) is rich experiences that can be distributed in the same way.

But there are many steps left to get there, so either buckle up and help build that future, or get used to an ever-shrinking ecosystem of the purely textual Web.

I'm personally very excited by the convergence of mobile and web development, PWAs, improved functionality for layouts, self-hosted app architectures (like Tent and Sandstorm, language-agnostic runtime via Web Assembly, better serving performance via HTTP/2, low level multimedia APIs, encapsulation of rich UX via Web Components, and so on and so on.

Sure, it's bewildering right now, but in the future, this will all be knit together in a cohesive way.

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

#145

Post by DiNovi »

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.

for brochure websites, yes, For large projects, hell no.

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

#146

Post by kuschku »

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…

> Would you prefer to build your application using Make, Scons, Waf, CMake, QMake, Tup, Bash scripts, Maven, Gradle, Ant, Buck, or something else? The build tool question is _totally_ solved, right? :)

Yes.

I've worked with CMake, Gradle, Maven, Ant, with webpack, makefiles, and the entire rest. And you know what? I went back to ES5, just because it's easier than fighting the JS environment. Comparing your average build.gradle with a webpack config is downright insane.

Why does the web environment have to be so much more complicated than the native world? The web could be so much more powerful if they'd study history, and learn from it.

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

#147

Post by colordrops »

leeoniya wrote: post #141
colordrops wrote: post #134

Earlier quoted context omitted.

enlighten us

ok, assuming your request is not sarcastic: - operating systems - hardware drivers - a networking stack - trading algorithms - fighter jet firmware - ultra low latency DSP - processing data from LHC collisions or imaging satellites. - etc - etc - etc just because webgl enables fast gpu processing (by basically writing a small subset of C that is shader code) doesnt now mean the web platform can be used for evetything…

The implication was applications. But even then, everything on your list is emphatically not true:

- operating systems

Ironically Linux was one of the first things to ever be compiled to run in the browser using empscripten.

- hardware drivers

Linux doesn't run without hardware drivers. In this case, the hardware drivers were wrapping JS FFIs.

- a networking stack

Yes you can.

- trading algorithms

Why not?

- fighter jet firmware

It's not a fighter jet, but the SpaceX Dragon 2 space capsule's UI is built using Chromium.

- ultra low latency DSP

Why not?

- processing data from LHC collisions or imaging satellites.

Why not?

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

#149

Post by troncheadle »

paganel wrote: post #49
colordrops wrote: post #43

Earlier quoted context omitted.

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…

Not the OP, but I expect the web to be a thing where documents (i.e. mainly text) don't have any issues rendering on my 5-year old phone or on my 8-year laptop (both of which work very well, still, and which I don't plan to replace anytime soon). The recent web practices (I'm talking mostly of the last 2-3 years, since more and more people have started copying Twitter with its launch of its "every website needs to be…

And I would love if my 2001 Honda Accord was compatible with Tesla's autopilot, but I understand it is not a realistic expectation.

I'm not sure why you'd expect the web to be a. Mostly text and b. able to render easily on obsolete devices.

The web is becoming a robust application delivery platform. That is so, so awesome. Most people do not want to be stuck with shitty looking, text only websites. Moving the platform forwards necessitates that it will use more resources. Increased resources availability and consumption over time is fairly consistent across most aspects consumer computing.

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

#150

Post by mnutt »

ZenoArrow wrote: post #86
Tloewald wrote: post #64

Earlier quoted context omitted.

Ah and so what good monoculture can you direct us to?

Rails? Ruby isn't a monoculture, but Rails does seem pretty dominant.

If you like the Rails monoculture, you may like Ember as a front-end framework. Most of the choices are made for you, and on the whole they're very good default choices. If you choose Ember, you get: a CLI tool (ember-cli), a templating/rendering engine (Glimmer), a router, a persistence layer (ember-data), a unit testing tool (qunit), a server-side renderer (fastboot), etc. If you want to swap one of things out you can, but the default has great support. There have been some bumps along the way, but everything fits together and works.
Post reply on HN