Live data from Hacker News

Facebook Announces React Fiber, a Rewrite of Its React Framework

techcrunch.com

291–300 of 422 posts

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

#291
post #71

Earlier quoted context omitted.

Browsers and JavaScript are what we have, we can't magically replace every browser and JS implementation in the world. We have to figure out where we want to go and slowly get there. That is exactly what is happening in the frontend world and that is why there is so much churn. Browser apps have to work across 4 major browsers with versions going back almost 10 years, an infinite amount of screen sizes, and a near in…

> And the other great thing about these tools is you can add/remove them as needed. In order to get that freedom, you need to build the tooling in such a way that it aligns with the web standards, so that when the standards catch up you can drop what you don't actually need anymore. We all switched from coffescript to ES6 and Babel because ES6, being standards-based, will eventually be supported in browsers, right? A…

Browsers catching up won't be the end of transpilers. If you want to write modern JS and have it support old Android phones or safari, you're stuck transpiling. And, browsers well never catch up, there will always be new features to be trying. It's really beautiful: we get to try different possible future versions of JS and make an informed decision on what and what not to bring into the language.

Also I have a feeling we'll be seeing a lot more to-JS languages, not to mention apps written in Rust, etc that target webassembly.

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

#292
post #263

Earlier quoted context omitted.

Might be more Firefox than your macbook or the web. I've noticed (while developing an extension) that Firefox feels noticeably more sluggish than Chrome. Safari somehow feels even faster than Chrome, but I'm too tied to the extension ecosystem of Chrome to switch.

Safari is definitely faster than Chrome on Mac.

It also uses significantly less power.

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

#294
post #127

Earlier quoted context omitted.

Is it that absurd? Building Java applications using Undertow with a build setup in gradle is not _that_ different from a node.js service using Express and package.json for dependencies, or a Ruby, Sinatra and Rake stack. After having tried all three, I ended up going back to the JVM. It's not a perfect ecosystem, but it's damned good one.

If you're on gradle you're already pretty cutting edge compared to most enterprise java setups. Probably most projects are still using maven. Also there's definitely been some cross pollination of ideas from at least the Ruby world to the Java (Rails inspiring Grails and probably Play too), so it's getting better. Add java8 lambdas, and it's quite nice.

> Probably most projects are still using maven.

Aren't you optimistic.

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

#295

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…

And thus, yet another insipid "hey let's argue about JS fatigue!" comment clobbers another HN comment page, with 100+ replies not one of which has anything to do with TFA .

If it wasn't a problem, it wouldn't be upvoted. That is how voting works. I'm not a JavaScript programmer, although I have dabbled extensively in the past. My impression of this thread is that not much has changed in that world. Sencha, titanium, and Phonegap were super hot back in the day, along with jQuery, SproutCore, Knockout and Backbone. Now it is all different for JS. That fuckng sucks.

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

#296
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…

> 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 a nonexistent variable throws a ReferenceError[3].

> no decent debugger

I disagree, but regardless — doesn't the fault here lie with browsers, not the language itself?

We also get a module system, object and array destructuring, async/await, template strings, generators… it's pretty difficult to say the new ES features are "a step backward".

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [3] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

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

#297
post #172

Earlier quoted context omitted.

I have serious doubts that WebAssembly is really going to come to dominate the web the way many people here seem to believe it will. The idea that all of sudden there is going to be a rush to push compiled/closed sites after so many very successful years of using free-and-open stacks seems rather non-logical to me. Time will tell.

The success of the JavaScript stack was not dependent on source being shipped to the browser, and the push for WebAssembly​ is not motivated by keeping source away from the browser.

What? It absolutely was. Whole generations of today's JS people trained themselves with View Source.

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

#298
Building your project upon an framework means abstraction, idoms on top of the programming language one has to learn and the pending migration-horror when the framework changes the API or gets deprecated.

Often it makes sense to think at least about alternative solutions like using libraries instead of a framework. Libraries are a different concept that is more flexible. In any case stable API is prefered to moving targets. A real probem is when project move so fast that one has to update to every new minor version of the framework/library, if he skips one he might be left out of the supported upgrade path (frameworks) - lot's of maintanance work that could be spent elsewhere (coding new features, etc).

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

#299
post #172

Earlier quoted context omitted.

>"At the end of the day all it would take is one of the 3 major browser vendors to offer an alternative." You mean like Dart? Besides, languages that target WebAssembly are almost certainly going to evolve to fit that space.

I have serious doubts that WebAssembly is really going to come to dominate the web the way many people here seem to believe it will. The idea that all of sudden there is going to be a rush to push compiled/closed sites after so many very successful years of using free-and-open stacks seems rather non-logical to me. Time will tell.

I see your point. But I'm more optimistic. We devs like to jump on hype trains. We only need one good reason to do so.

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

#300
post #92

Earlier quoted context omitted.

Rust, PHP had simple af builds/packaging. So no, not everything is complex, just old dinosaurs AND web.

PHP's packaging was only "simple af" until you had a binary dependency that wasn't part of your operating system. Complicated things exist.

But now you're hitting on one of the main points that was always criticized in PHP: the fact that it came with a lot of batteries included. The upside of this is that it makes PHP applications very easy to deploy, because often, you either don't need to resort to binary dependencies outside the realms of your OS's packaging system, or there will be a `php[major-version]-[library_binding]` package for your OS probably already in your OS's official package mirrors. Say all you want about PHP, but of all the application stacks I've had to deploy, PHP was and is probably still the simplest. The advantage of that shouldn't be underestimated. The only serious competitor in that space that I've ever touched is probably Go.
Post reply on HN