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

341–350 of 422 posts

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

#341

Post by _pmf_ »

pier25 wrote: post #285
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.

Even for small projects libraries such as Vue or React are very useful. Of course it feels easier to stick with what you know, but managing the DOM with data is so much easier than using jQuery + Handlebars. Seriously, spend some time learning Vue. You won't regret it. It has to be said that you don't need any building process (Webpack, gulp, etc) to use Vue. You can simply write your templates in your index.html and…

Just when I thought that we have enough JS frameworks and there's nothing to do fundamentally different, along came vue.js ...

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

#342

Post by [deleted] »

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…

[deleted]

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

#343

Post by danabramov »

roguecoder wrote: post #329
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.

Vue is much, much faster to load; it is possible to use vue applications over 3G where React apps choke. Vue is also, in my experience, much easier for back-end developers to contribute to without making app-braking performance mistakes. It has a canonical event-driven store, Vuex, with much nicer debugging tools than any of the flux frameworks (it includes getter values, for example). I have also found the error mes…

>I have also found the error messages more meaningful across the ecosystem; React can sometimes produce very unhelpful errors.

Can you file an issue next time? We're happy to fix confusing errors.

>much, much faster to load

I would love to see some data backing it up. I thought they are roughly in the same ballpark with Vue having slightly more built-in APIs but I might be wrong!

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

#344

Post by danabramov »

shouldbworking wrote: post #277

Anyone have a link to some benchmarks? As much as I enjoy the hype train sometimes, I'm not finding hard data on how much faster this is than the current React/Preact/Inferno . So much hype and no words about performance... I'm wondering if it's slower.

Please see my reply in https://news.ycombinator.com/item?id=14144042.

Regarding benchmarks, you might enjoy reading this: https://medium.com/@localvoid/how-to-win-in-web-framework-be...

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

#345

Post by danabramov »

Mayzie wrote: post #248

Will React Fibre be utilising WebAssembly for a performance increase, particularly for their virtual DOM? (falling back to JavaScript when possible, of course)

No, there are no plans to use WebAssembly in the next few releases although we'd like to explore this eventually.

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

#346

Post by danabramov »

lightblade wrote: post #229

Correct me if I'm wrong, but Fiber sounds like a micro tasker for React? Ember had been doing this for years through Backburner run loop

With the ability to pause large updates in the middle without committing them to UI, doing some higher priority updates, and then "rebasing" lower priority updates on top of them and continuing the work. So it's a bit more sophisticated.

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

#347

Post by _pmf_ »

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…

> 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, you can instantiate its contents with "MyCompX" without any additional setup).

For Android, it has the advantage of being able to hot-reload the UI without jumping through hoops (simply serve them over HTTP and install a small reload handler in your app that can be triggered either from the app of by something like a UDP message from the host). (Change one like in the app's main and you are able to pull the QML files from a local directory so you can modify them on the tablet without a PC or internet connection ...)

I'm actually reluctant to mention Qt/QML because I consider it to be my secret magic silver bullet for portable (non-web) UI development.

Regarding the license (there's a lot of misinformation, including Qt's main site trying to coerce you into using the commercial license): if you link dynamically, commercial usage is not a problem (LGPL). (This is usually only an issue on iOS.)

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: offering a version that only exposes the QML editor and interface generator, and ships qmlscene as execution runtime and an option to deploy the QML-only application with a rebranded qmlscene (embedding the QML resources and a custom icon). To be clear: this all exists right now, but with the C++ part enabled (which will scare off some developers even if they can create applications without it).

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

#348

Post by madeofpalk »

wayfarer2s wrote: post #265
madeofpalk wrote: post #210

Earlier quoted context omitted.

Except it's not for when you actually want to know when the component was put into the DOM, or you're running react server-side

> when you actually want to know when the component was put into the DOM You can use componentDidMount for that and its semantics are still the same.

Oh apologies - I really the comment as componentDidMount. My bad.

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

#349

Post by vrde »

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…

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 reinvent the wheel.

Facebook did something super valuable, that is ReactJS, and this is becoming the _de facto standard_. ReactJS is simple, opinionated, and supported by a large corporation. Thanks to ReactJS a new ecosystem was born, and now finally you have many projects gravitating around it, and this is good. It's just a matter of time IMO.

I strongly disagree with _"the browser is a bad app platform and javascript is a bad language"_. JavaScript has its quirks, but it's also really plesant to work with if you don't do weird shit like `isNaN('wft' - 1) // it's true`. The browser is a great virtual machine that is democratizing the web. If you are doing things right, you can have graceful degradation (it degrade gracefully to a lower level of user in experience in older browsers) to increase the audience of your web app, from the dev in SF with gigabit internet to someone living in a rural area in a not so tech advanced country. This of course has a cost, that is spending time developing your app.

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

#350

Post by tannhaeuser »

julian_1 wrote: post #331
tannhaeuser wrote: post #315

Earlier quoted context omitted.

There's nothing "not actual XMLish" about HTML. HTML is formally describable in its entirety using SGML (see my project at http://sgmljs.net/blog/blog1701.html ), just not by the XML fragment of SGML.

Is it possible to scrape random html5 pages off of the internet and transform them with xslt 2? Or write content/metadata schemas (distinct from a DTD schema that simply describes html5) using XSD? Unlike xhtml, my understanding, was that the current tooling around XML won't just work out-of-the-box for html5.

What cwyers said. Plus, XML was designed to replace HTML as XHTML, but it didn't happen. Doesn't mean you need to give up markup processing alltogether. Just use full SGML, which has additional features such as tag omission/inference and other markup minimization features for text authoring not in the XML profile of full SGML such as markdown and custom Wiki syntax support. You might actually like it.

You can parse HTML 5 into XML using my HTML 5 DTD [1] and eg. OpenSP's osx tool or my upcoming sgmljs.net tool.

What do you have against DTDs? They do the same as XSD, and then some.

[1]: http://sgmljs.net/docs/html5.html

Post reply on HN