Facebook Announces React Fiber, a Rewrite of Its React Framework • Hacker News Board

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

#381

Post by austincheney » Wed, Apr 19, 2017, 1:45 PM UTC

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…

The most disappointing part of all of this is that in the JS environment no build step is required, but it is often there anyways...

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

#382

Post by douche » Wed, Apr 19, 2017, 1:51 PM UTC

Sacho wrote: post #362

douche wrote: post #304

Earlier quoted context omitted.

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?

Any sufficiently large jQuery webapp has a strong tendency to become indistinguishable from a plate of spaghetti, without strong efforts to keep things sane. Angular, once we got over the learning curve and converted over the old functionality, made it a lot easier to make changes and add features.

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

#383

Post by oatmealsnap » Wed, Apr 19, 2017, 1:52 PM UTC

austincheney wrote: post #381

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 most disappointing part of all of this is that in the JS environment no build step is required, but it is often there anyways...

What do you mean? Are you referring to gulp and other similar tools?

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

#384

Post by TP4Cornholio » Wed, Apr 19, 2017, 2:03 PM UTC

nkkollaw wrote: post #124

See, Google should learn from Facebook: total API compatibility with the previous version. They saw what happened with Angular and Angular 2—which Google named the same despite it being a totally different framework—and made a smart move.

Facebook's motto is "move fast and break stuff." I'm glad they didn't follow this when making React Fiber. I suspect they learned from Angular 2's failure.

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

#385

Post by inopinatus » Wed, Apr 19, 2017, 2:09 PM UTC

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…

"The thing that backend devs don't realize is that frontend is not easy." - I think that's a false dichotomy, one that describes no professional programmer I have ever encountered except the most junior, or the most foolish of hopefully-soon-to-be-ex colleagues. In my experience it is product managers, architects with a mostly-infrastructure background, and nontechnical stakeholders, who tend to assume that frontend is easy. All developers who prefer to work in the backend will have built a user interface at some time, and learned that programmatically fulfilling human needs and intentions is a tough ask.

"ReactJS ... is becoming the _de facto standard_ ... and this is good" - strong disagree, standards that aren't standards that are controlled by a proprietary actor have rarely been a good thing. The woes of dealing with Microsoft Office file formats, or Adobe Flash, or Google Reader pay testament. Heck, QWERTY keyboards. Or Edison's AC/DC feud with Westinghouse, a struggle over proprietary preferences that can be directly blamed for the extended length of my tea breaks when visiting the US.

I feel like there's something missing from core ES, something conceptual that would encourage an ecosystem to develop that isn't framework-specific. We just don't know what that is, yet.

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

#386

Post by austincheney » Wed, Apr 19, 2017, 2:22 PM UTC

oatmealsnap wrote: post #383

austincheney wrote: post #381

Earlier quoted context omitted.

The most disappointing part of all of this is that in the JS environment no build step is required, but it is often there anyways...

What do you mean? Are you referring to gulp and other similar tools?

I am referring to any build step. Do you need a build step to execute JS?

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

#387

Post by jakelazaroff » Wed, Apr 19, 2017, 2:24 PM UTC

kerkeslager wrote: post #374

jakelazaroff wrote: post #296

Earlier quoted context omitted.

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

> Sure, but the patterns you use with the class syntax are incompatible with the patterns you use when using object literals

How so? You can still access the prototype. It's just that the most common reason to — declaring instance methods — can be accomplished with the easier-to-read class syntax now.

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

ES6 is a non-breaking change. You can use arrow functions for literally every function you write other than generators.

> var a = {}; > var b = a.c;

That's a nonexistent property, which probably should throw some sort of error — but that's why we have tools like TypeScript and Flow that can detect this.

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

#388

Post by vertex-four » Wed, Apr 19, 2017, 2:25 PM UTC

fulafel wrote: post #306

segphault wrote: post #101

Earlier quoted context omitted.

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

> We all switched from coffescript to ES6 and Babel because ES6, being standards-based, will eventually be supported in browsers, right? No, a lot of us switched to ClojureScript, TypeScript, Elm, etc and don't look back. As long as you have to transpile, why not transpile from a good language? (Not to say that native ES6 support would compensate for the advantages of the abovementioned languages) Standards are not g…

Or, you know, allow multiple implementations without someone having to reverse-engineer what's meant to happen in edge cases from the reference implementation...

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

#389

Post by braveo » Wed, Apr 19, 2017, 2:32 PM UTC

lobster_johnson wrote: post #142

braveo wrote: post #60

Earlier quoted context omitted.

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

The question I posed in the discussion is why they didn't extend WSDL instead of trying to rebuild the entire ecosystem by creating Swagger.

To me the XML/JSON thing is a non-issue. I've never really gotten the unreadability of XML argument given a decent prettifier (which also applies to JSON), especially for something like a web service description.

I guess my thing is, we already have a web service description language, it's called WSDL, and it's already been extended to support REST, why not extend it to support whatever use case you have, or build the tooling around it to support said use case?

You could have easily built the Swagger Spec to spit out WSDL instead of JSON. It means you would have been able to lean on the existing tools that can swallow a WSDL file instead of having to recreate the entire ecosystem yourself.

What I kept getting back was "JSON > XML" and to me that's just a non-issue. It's so far down the list of what's important that I can't imagine making the decision to try and recreate all the tooling around WSDL for it.

And I guess I've never really had your experience with WSDL because I've never been forced to be aware of namespacing issues any further into my system than the edges. Perhaps I've been lucky, but I've been using WSDL for years to ease integrating into web services and I've never stopped and thought to myself that it would be better in JSON with a YAML spec. And I rarely deal with SOAP nowadays, and when I do, I just use a library to swallow the WSDL and do the right thing.

I guess that's really where I'm coming from. It smacks of religion to me.

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

#390

Post by fauigerzigerk » Wed, Apr 19, 2017, 2:33 PM UTC

_pmf_ wrote: post #347

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…

> Qt is big and complicated. I'd encourage every developer considering Electron to give Qt/QML a try. It merges the declarative nature of WPF with a nicer syntax and the ability to use JS directly in the QML file, obliterating the need for converters of formatters (that plague XAML/WPF and JavaFX). Writing custom components is trivial and intuitive, with zero syntactic overhead (if a QML file "MyCompX" is present, yo…

>The recent Electron situation (needed on one hand, loathed on the other hand) is a unique opportunity for Qt to gain (back) some developer mind share, but to avoid alienating web developers with scary C++ stuff it would help to decouple QtCreator from the Qt C++ API

For me it's exactly the other way around. If I'm using Qt it's because I want to use C++ to make my app as efficient as possible in terms of CPU and memory usage. Now that JavaScript is in the picture, I'm less likely to consider Qt for a cross platform app because I can just as well use any of the other more popular options like Electron or ReactNative.

Qt used to be a C++ GUI framework. Rebranding it as something else won't work. They won't get the web crowd and they will alienate people who want to avoid web technology.