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

371–380 of 422 posts

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

#371

Post by kuschku »

kuschku wrote: post #156
spicyj wrote: post #29

Earlier quoted context omitted.

No final numbers yet, but we recently switched to Rollup for our own builds which will be part of 16.0, and we'll do some more work on file size in the next few months. For DCE, we've started splitting some features like createClass out of the main package ( https://facebook.github.io/react/blog/2017/04/07/react-v15.5... ) which will reduce the bundle size for anyone not using them, regardless of how they compile the…

What bundle size range can we expect? Many mobile users are on throttled connections, due to low data caps, and research has shown users stop loading a site usually after 1 second of loading time. That means with a throttled connection, less than 8KiB overall CSS, JS and HTML can be transmitted, and with a 1Mbps connection, 128KiB can be transmitted. How many minutes will users have to wait with React Fiber? And can…

Answering @vote-for-pedro: Yes, currently, a working React installation takes around 6-10 seconds to load on dialup or throttled internet, without caching. Which is pretty good.

But React Fiber is doing a lot more than legacy react, so it'd be interesting to know how much larger it will get - and if it would still be performant enough.

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

#372

Post by akerro »

b34r wrote: post #221
alcasa wrote: post #102

Earlier quoted context omitted.

> Great. I was waiting for React to stabilize before I learned it. But once it's stable, it's outdated.

It's been stable for more than a year now.

Best practices will come out in 2025!

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

#373

Post by kerkeslager »

Sacho wrote: post #363
kerkeslager wrote: post #254

Earlier quoted context omitted.

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

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

Writing it every day.

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

#374

Post by kerkeslager »

jakelazaroff wrote: post #296
kerkeslager wrote: post #254

Earlier quoted context omitted.

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…

> now we have two incompatible inheritance systems instead. JavaScript still only has prototypal inheritance; class syntax is just sugar[1]. > Meanwhile `this` still doesn't mean "this" Even with arrow functions, which don't change the binding of "this"[2]? > there's still no... boolean types typeof false === "boolean" > accessing a nonexistent variable silently fails but happily continues execution Trying to access…

> JavaScript still only has prototypal inheritance; class syntax is just sugar[1].

Sure, but the patterns you use with the class syntax are incompatible with the patterns you use when using object literals, so libraries pick one or the other, typically the class way.

> Even with arrow functions, which don't change the binding of "this"[2]?

Even with arrow functions, `function` still exists ands is more frequently used.

> Trying to access a nonexistent variable throws a ReferenceError[3].

var a = {};

var b = a.c;

Doesn't throw a ReferenceError for me.

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

#375

Post by NoGravitas »

batmansmk wrote: post #120
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…

Good troll. Ask your users to install your app and qualify as extra features (with associated budget) the capabilities of bookmarking, sharing urls, having multiple tabs, "remember me" and forms autocomplete, going back, having a history, or auto-update. Justify it to them it's because their browser is a bad frontend platform. Like this horrible, horrible mobile twitter lite ;). In my first year of programming, html…

The web is a great platform, and so are browsers. JS apps running in the browser? Not so much.

How many of those features you list are routinely broken by SPAs?

Bookmarking and sharing URLs? Almost always.

Going back and having a history? Often.

Having multiple tabs, and forms autocomplete? Sometimes.

I hate web development mainly because I love the web so much.

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

#376

Post by NoGravitas »

acjohnson55 wrote: post #144
paganel wrote: post #49

Earlier quoted context omitted.

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…

The fact is that 99% of what's done on the web is (mainly textual) document management/display. Facebook (the website responsible for React!) is 99% document display.

The truth is that "rich experiences" are mostly made by enhancing the basic experience of reading rich documents. If you want an inspiring vision of a document-centered future, look at IndieWeb.org. And/or roca-style.org. It's a vision of how the web can be knit together into a cohesive whole based on URLs, rather than segmented into a bunch of unaddressable silos.

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

#377

Post by talldan »

amelius wrote: post #321
b34r wrote: post #227

Earlier quoted context omitted.

Not at all. Fiber is a method of divvying up the work the reconciler is doing so the main thread can process higher priority updates ahead of ones that matter less. There are other benefits, but this is the central one.

UI updates seem to be only possible in the main thread

My understanding is that it's a prioritisation system. If all of the UI changes can't be completed before the next render, the lowest priority changes are deferred to the next render.

It should help with things where perceived lag is undesirable, like typing in an input field.

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

#378

Post by mxstbr »

scottmf wrote: post #239
red023 wrote: post #187

How does it compare with vue.js? I never worked with any modern JS framework like this but on paper I did not like writing CSS in javascript and vue.js had a normal way to write CSS and to me it looked superior in other ways as well.

Check out styled-components. It's 100% CSS and it's awesome. https://github.com/styled-components/styled-components Edit: for the record there's nothing stopping you from using CSS files with classnames on your tags as usual, but libraries like styled-components allow you to easily scope and collocate your CSS with your components.

Hey, that's us!

Thanks for posting this Scott, if anybody has questions about styled-components feel free ping me here or on Twitter. (@mxstbr)

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

#379

Post by fauigerzigerk »

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…

What's so unusual about the current web platform is that none of the technologies involved were actually created for the task they are being used for right now.

HTML wasn't meant to build interactive application UIs. CSS wasn't meant to do layouting (or if it was it was done so badly that the intention is unrecognisable). HTTP wasn't meant to carry fine grained API calls. JavaScript wasn't meant to do large scale application development.

It's a long list of wrong tools for the job that are being cobbled together to supposedly form the right tool for the job. It's working to some degree but it's messy.

That's not to say that creating a technology for a specific purpose guarantees that it will work well. EJB, SOAP, WS-*, there are many examples of failed purpose built technologies.

But having an entire platform built exclusively from components that are unfit for purpose isn't something that happens very often.

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

#380

Post by H1Supreme »

wccrawford wrote: post #370
vrde wrote: post #349

Earlier quoted context omitted.

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.

Absolutely. I've been doing "frontend" work before it was even a term (ie. html tables for layout), and it's still the #1 thorn in my side. Even with all the tools available, developing a functional, aesthetically pleasing GUI is not an easy task.

Plus, organizing your code so it's not a 15-nested-div mess with inline CSS just to make the damn thing look right.

It's probably why most of my personal projects have a CLI, and that's it.

Post reply on HN