Facebook Announces React Fiber, a Rewrite of Its React Framework
techcrunch.com
techcrunch.com
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 migration is at [2], and the follow-up issue discussing the plan for the "addons" packages is at [3].
I'll also toss out my usual reminder that I keep a big list of links to high-quality tutorials and articles on React, Redux, and related topics, at https://github.com/markerikson/react-redux-links . Specifically intended to be a great starting point for anyone trying to learn the ecosystem, as well as a solid source of good info on more advanced topics. Finally, the Reactiflux chat channels on Discord are a great place to hang out, ask questions, and learn. The invite link is at https://www.reactiflux.com .
[0] https://www.youtube.com/watch?v=ZCuYPiUIONs
[1] https://github.com/markerikson/react-redux-links/blob/master...
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 tools change, the metalanguages, the data formats, even the damn paradigms change. Each generation requires more layers trying to fix up the underlying evil that nobody who soaks themselves in the matter will admit: the browser is a bad app platform and javascript is a bad language. Both have been pressed into serving a purpose for which neither were designed.
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, CMake, QMake, Tup, Bash scripts, Maven, Gradle, Ant, Buck, or something else? The build tool question is _totally_ solved, right? :)
Yes, the JS community has been reinventing a number of wheels. Yes, the browser environment and JS standard lib have weaknesses. On the other hand, it's also allowed developers to build useful applications that are immediately distributable to pretty much anyone who has an internet connection.
At the end of the day all it would take is one of the 3 major browser vendors to offer an alternative. That alternative could be distributed to a large percentage of desktops in a relatively quick manner saving billions if not trillions of dollars in wasted productivity.
It will never happen though.
* EDIT: This comes from someone who uses React, Redux, webpack, etc.. daily
Not that I even like XML. But having another XML dialect that's not actual XML shows that the only hope is to build valid tools and abstractions on top of all the crud.
You mean like Dart?
Besides, languages that target WebAssembly are almost certainly going to evolve to fit that space.
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.
Half the problem with the web stack is inexperienced people making things way more complicated than they need to be. A minimal webpack.config is pretty damn simple.
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).
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.
Actually, Java, C++,QT and co are going through great length to make development simpler and all the compilation pipelines easier. Let's take Java for instance, groovy, maven and war packaging considerably made Java server development easier. Java frameworks like Spring are trying very hard to make servlet development easier, by making complexity opt-in. Java is getting constructs like modules which will help with library development, C++ too, QT is streamlining its API ... So I'd totally disagree about your statement. The success of Go yet another proof of this. People are tired with unnecessary complexity and are ready to give up on "elegance" for the sake of simplicity.
My point is that building complex software inherently involves _some_ amount of complexity on the development side, which is reflected in the language syntax and tooling used with that language. Now that people are building complex apps in Javascript, we're seeing catch-up in the tools used to build Javascript apps to match the tools that have existed for years on the desktop/native side.
Complicated things exist.
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 infinite amount of devices. There is no other platform with the capabilities of the browser that has this much reach.
If we had the ability to start from scratch and build the ultimate web platform, yes, it would probably be way better than what we have, but we don't have that ability nor will we ever have it, so talking about it is a waste of time. We need to look at our current capabilities, where we want to be in the future, and iterate until we get there.
All of the tooling we have serves a purpose and solves a problem, it's not like frontend devs are adding tooling for the fuck of it.
Take a common stack nowadays: React, Redux, Webpack, Babel, Eslint, Yarn, Styled Components
Every single one of those tools in the stack make my life easier. I don't have to use all of them. In fact, there was a time where I didn't, but I would never want to go back to that time because these tools allow me to build way more complex apps way faster than I used to. And the other great thing about these tools is you can add/remove them as needed. Take something like browser prefixes, as browser support for certain prefixes or features are implemented at a large enough scale, the tooling for that becomes obsolete and you drop it.
And as far as JavaScript goes, pre ES6 I would agree, it sucked. Post-ES6, I will have to disagree. I love writing JS nowadays.
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?
And yet, with JSX we have a gratuitously non-standard dialect of JavaScript that isn't on the standards track and will never be natively supported in browsers. So, even when browsers catch up and offer full support for modern ES6 syntax, we're still stuck with transpilers because Facebook thought it was a good idea to tightly couple their custom templating language to JavaScript itself instead of wrapping it in template literals, which is the standards-based approach that ES6 actually provides for embedded DSLs and templating.
Today, in Europe and North America, roughly ~85% of users run a browser version that has native ES6 support. IE marketshare fell off a cliff in 2016, and now IE11 is at less than five percent and still falling. I don't actually need to transpile during development today, and I won't need to do it in production either in a year or two, and yet everything written with JSX will need a transpiler forever.
It just gets compiled down to native javascript. JSX is also optional in React - meaning that you don't have to use it. And having an actual client-side data-structure to represent DOM is arguably better than using string based templates which is what folks have been using for decades.
Also, compilation is not a dirty word - when you consider just how primitive the standard language is. A static type-checking compilation pass also helps keep large codebases/modules manageable, and aids refactoring by being able to catch errors - without actually having to run the code to figure out what it does.
It's true that there is unnecessary fragmentation. But the broad trend reveals that front-end development is actually starting to catch up with best-practice.
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 generally virtuous in programming languages. They tend to come about to mitigate language fragmentation between rival factions, something that most good and popular languages don't have a problem with.
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.
Template literals could not possibly be a replacement for JSX. JSX is Javascript, template literals are strings. JSX isn't a templating language by design, it's one of the primary advantages.
I do my templating in template literals because using standards-based JavaScript means that I don't need 50MB of fragile packages from npm or a largely superfluous build step during development.
[1] https://github.com/facebook/react/issues/690
[2] https://www.npmjs.com/package/babel-plugin-syntax-do-express...
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.
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.
1) What was CSS meant to do if not layouting?
2) What should we have used instead of HTML for building interactive application UI's?
3) What advantage does using the right language for the right job confer?
I'm a beginner so please excuse any ignorance on my part.
It's just different, IMO. Programming is programming, but different specialties have different things you need to worry about.
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.
"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.
I'm against the front x back end split. I think any web dev need to know html, css and js. That's mandatory. Besides that, you should definetely learn the server side too, specially databases, since they'are by far the biggest bottleneck and performance hog you'll need to optimize.
But I'm getting old and I know that because I think everything new is stupid. Once upon a time, we had RAD tools to build UI's, but unfortunately, that's lost in the past...
The answer to this is simple but horribly disappointing. In the military we describe this behavior as "justifying your existence". There are three separate causes to this problem.
First, solving valid problems is hard in any environment. Dicking around with tooling and configuration is easy. This includes frameworks, abstraction libraries, and so forth. Real problems are often tied to products, services, or end-user problems (opposed to these invented developer problems).
Second, writing open source software takes initiative and discipline. It is easier to have the energy for hard problems when people are telling you what to work on and you are getting paid. In this case failing to complete the hard problems bring retribution and eventually termination. When you are on your own or volunteering your time you have to really want it, which completely compounds the first point.
Third, there is a low barrier to entry to do front-end work. You can copy paste some code from the internet into your browser console and watch it do stuff. You don't need a compiler, special environment to get started, or any kind of fancy software. This problem is compounded in the legacy corporate world where web technologies are still viewed as inferior child's play for incompetent weak-minded children. After all real developers write ALL of their web related code in Java 6 (sarcasm).
Regarding the complexity of the underlying system, I think this is not a concern of the typical frontend developer. It has nothing to do with JavaScript or the web. If you are writing a "simple" C program on Linux, would you be concerned about the complexity of the underlying C library (yes glibc is rather big and complex) or the Linux kernel? You won't. This is the point of abstractions. If you want, you don't have to learn about any of these; treat the implementation as a black box and start writing actual frontend code.
> Each JSX element is just syntactic sugar for calling React.createElement(component, props, ...children). So, anything you can do with JSX can also be done with just plain JavaScript.
Source: https://facebook.github.io/react/docs/react-without-jsx.html
There's also a variety of libs to help with that process. We have an existing ES5/Backbone app that's built with Require.js, and we don't have a "compile" step in there. We just added our first couple React+Redux-based features into that codebase, but can't use JSX due to that lack of compilation. I opted to bring in https://github.com/Jador/react-hyperscript-helpers as an alternative to JSX. Not perfect, but it's a suitable alternative given our limitations. There's several other "virtual DOM/hyperscript"-ish packages out there as well.
It's upvoted because it's HN's current favorite holy war. "Front-end development is out of control" is something everyone has an opinion about, in a way that the announcement of React Fiber isn't.
That doesn't mean the same debate needs to be re-litigated every two days. Occasionally would be fine, but when it happens in every tangentially related thread it sucks the oxygen out of everything else.
And, by the way, I'm not defending react.
This has got to be the biggest jump to a conclusion I've seen in HN comments this year, without a close second.
Sincerely, C programmer who thinks there still something to be learned from some of the architectural underpinnings of a library like React.
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 was such a joy to use compared to gcc. Could get a button with a background color and an image displayed under 2min. Just saying.
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.
Yeah, and we're finally making real progress towards making it better. I used to do web development because nobody else wanted to, now I do because it's really fun. This is a forum for hackers -- we should be excited about the unsolved problems instead of complaining that things are changing.
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. Meanwhile `this` still doesn't mean "this", there's still no integer or boolean types, accessing a nonexistent variable silently fails but happily continues execution, only reporting an error when it's far away from the problem. There's no threading, no security primitives, and no decent debugger. None of the problems are being fixed and the new features are either lackluster or make things worse.
And that's just the language itself. The ecosystem is in more of a shambles. Web development in the age of left-pad and global shared state being normal is exciting in the same sense as plagues of frogs and locusts are exciting: it's not boring but if it were boring that would be better.
It's more fun to roll your own or to pick up a new one.
I mean, in how may ways can you organize code that manipulate a DOM tree, pull data, massage data, and update the DOM tree? Well, the more the merrier :)
In my opinion, the important thing in frontend development is to know which tools and libraries to adopt and which ones to ignore.
As a platform, I find JS+HTML5 really appealing and I'm happy that there are many ways to use and creatively remix these technologies, so I don't see the large churn in the ecosystem as a disadvantage but rather as proof that browser-based JS works very well as a platform to develop applications on.
Personally, I can't stand javascript, and why you'd ever elect to use it for backend/server side code mystifies me. So I don't use it (or work in web development), and couldn't care less about what platform the hip web devs deem acceptable.
I have always used python/ruby on the backend, and I prefer them, but I recently worked on a couple of javascript backend projects, and I found one abhorrent and the other quite pleasant.
As could probably be expected, the practices used to develop the latter were just better. (These were even done by the same developers, in large part, and the differences were mainly lessons learned).
Anyway, if you're already working in a javascript-heavy front-end like React, it doesn't seem like such a stretch to use it on the backend, too.
Google, Facebook devs please go spend some time with the language and platform greybeards at Microsoft.
EDIT: Feels like Software Engineering needs a set of Software History textbooks to keep reminding us of what has already been built.
[1] : https://en.wikipedia.org/wiki/Lars_Bak_(computer_programmer)
now we dont use yeoman to create react apps, and we have a thousand start kits that get u off the ground. your node_modules directory probably has 30k+ plus files before a single line of your app is written. yarn
just imagine ur an embedded programmer, and you boss asks u to write a hello world for the nexet device, and u come back with a react app with 30,000 dependencies to get the job done. then u find a bug, which fb just fixed in the next release. But u cant upgrade to the latest version, because that conflicts with library that is used by a 3rd level dep, that is used to add padding to a smiley somewhere.
I see an incredibly complicated problem space- presentation of multimedia content and execution of code on billions of 'fragmented' devices over which the content creator has no control- and the minds of humanity iterating on approaches to the problem.
Front-end development is fashion.
Of course, it comes with its own issues, but you'll be blind to them for the first few years while you enjoy the cure of stability :D
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 I don't know why that's a significant problem with WSDL seeing as how you could autogenerate the javascript interfaces anyway.
I still can't really wrap my head around what problem Swagger is solving that wasn't already solved by WSDL.
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.
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.
> We aren't going to get off of your lawn while you continue to beat a dead horse.
> a failure of your imagination and ability to adapt
Please don't do this in HN comments regardless of how tired you are.
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 JS-app" thingie) have practically destroyed how most of the websites are displayed by the 2 devices I own. Sites like Hacker News or Wikipedia, which still work perfectly fine, are very far and few between. I sincerely deplore this.
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.
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.
Bundling the entire website inside a single js file, that needs to be re-downloaded everytime you add a div or change a single css class is stupid, sorry.
Your website doesn't need to be pure text. It can be beautiful, modern and responsive. And it doesn't need much js for that.
The world has become mobile first, not js-centric. Pushing spa everywhere is just wrong.
Because business models are composed on the web, it's just harder to settle on unified design standards. It takes time for everyone to agree on a separation of responsibilities on the page. This is compounded by the sheer newness of the business models. My webcomic about fancy cheeses has a segment marketing a line of tractors now to industrial buyers at a conference in Wisconsin this week? OK. That's an opportunity I probably wouldn't have had selling Java apps.
It's not unreasonable to expect that the ecosystem doesn't operate under an ever-expanding set of wrappers, frameworks, layers, and models, and it's certainly not unreasonable to expect that our tools don't suck.
The open standards you talk about ARE already a part of the ecosystem, and well-established: HTML, HTTP, DOM, and ECMAScript. The new JS library of the week is not a part of that.
But the point of the web already having these standards is exactly the point - these frameworks are built on top of and contribute to the underlying universal standards, so what's the problem?
One that I've been particularly keen on over the last year is GraphQL. If you're interested in simplifying frontend development while giving it more power and control to dictate the data that it needs for each component / view, you should check out GraphQL. I know what you're thinking... "Ugh, another dev tool to learn etc etc". But it's definitely one that's here the stay and a bigger idea than even REST itself. The OPEN STANDARD of it is KEY.
The idea is that you have a type system on the API level and one endpoint. And querying works using a standard GraphQL language, so it's cross-API compatible and you don't need to go learn a whole new API convention at each new place or project you're working on since with REST, they're probably all built in different ways. And GraphQL works across all platforms (i.e. no more proprietary SDKs). All you need are things like Relay and Apollo and that's it.
I've actually been working on a platform called Scaphold.io (https://scaphold.io) to help people learn more about GraphQL and give them a cleanly packaged server and help you manage your data so you don't have to in order to feel the benefits of GraphQL right off the bat. Because of the use of GraphQL, it comes with the best of both worlds of Parse and Firebase with awesome data modeling tools, real-time capabilities, and of course it's built on an open standard.
Truly is the future of APIs that works perfectly with React, and any other framework that comes out down the road for that matter. Facebook's tooling is really neat cause it's built from first principles as well as from their experience running one of the largest distributed systems in the world. So they definitely know a thing or two about building developer tools that are cross-platform compatible and developer-friendly.
Javascript isn't a monoculture because all the tools are bad.
Except, it's already a monoculture of one language (JS) and one display algorithm (DOM) and everything is just compensating for that.
The "runtime" is not general enough.
Old people also get tired by all these "apps" wining for your attention; they want "just a phone". Young people grew up with it. Note to self: I'm getting old.
Old people were used to buying development toolset (compiler+tools+IDE), usually including a physical book, with which they can create software. Young people are used to assessing open source projects, and piecing a project together on top of many freely available libraries/frameworks.
Except, you know, the entire presentation on it at React Conf back in March.
Somebody forgot to fact-check his article. That's for sure.
I think that's just called "research," and it's usually step #1 for this kind of article...
Yep, I can tell from the 5 seconds of blank screen while my phone browser loads all that JS.
Edit: Found the github repo - https://github.com/tomocchino/isfiberreadyyet
Looks like it fetches from the umbrella issue[1]
Do any of these fancy frameworks actually make a HTML fallback anymore? Most of the web pages I visit still renders fine without javascript.
Having said that, it's entirely possible (though not easy) to have your React app work without JS enabled by rendering it on the server before sending the page to the client. This way, you get the best of both worlds, but it's a lot of work to implement this properly for a remotely complex app. The answer in the short-term is that you shouldn't be using a "fancy framework" for anything for which the above disadvantages are a deal-breaker (like most public sites) until the server-rendering story matures and becomes more compelling.
This is exactly the type of openness you want to see for such a widely used project like React
Won't be long until someone upgrades their 16-thread 32GB machine because Facebook was "too slow"?
I type this on a dual core phone with 2GB of RAM that's faster than most desktops 15 years ago thinking I need a faster device.
I've been cleverly waiting since 2006 to learn jquery. Will start next year.
But once it's stable, it's outdated.
The React devs have also been great with releasing codemods for breaking APIs.
Sounds neat, but it also seems like an explosion in complexity -- perhaps there will be a bunch of weird scheduler bugs the operating system folks more or less figured out a long time ago?
It's not as hard because there is no parallelism (at least now) and any mutations of the internal data structures happen in two or three tightly controlled places. But yea, debugging these is harder during development (for us) and we'll need to make sure our testing story is rock solid before shipping the asynchronous mode by default.
One thing that really helps here is we test all updates on Facebook which uses React in many places and has a giant user base. So regressions that lead to a drop in metrics (e.g. a crash or a race condition) automatically get reported to us, and this adds a second line of defense after unit and integration tests.
That said, the early feedback from others in the React community is that the Fiber implementation is simpler overall and easier to work with than the "React Stack" implementation. Fiber is also explicitly built to support additional renderers on top of the core reconciler, while building renderers on the Stack implementation apparently required some levels of monkey-patching or reaching into internals.
React Fiber is nothing new. It's more than an year old. Facebook has talked about it many times. Anyone who uses React would know this.
Shouldn't we prefer official sources instead of articles written by third party content writers that are clearly not that knowledgeable? Seriously, this article looks like the author was being paid by character count and not quality.
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.
By the time Angular 2 was released, Ember, Vue and React have devoured the market
There will be new public api's to build your own custom rendering engine, ex how there is react-dom for browsers, react-native for mobile, and it will get easier to target new platforms thanks to fiber.
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! :-/
- https://github.com/facebook/react/issues/7671
- https://twitter.com/dan_abramov/status/790590733468241920
- https://www.reddit.com/r/reactjs/comments/5fg7iq/why_should_...
- https://daveceddia.com/where-fetch-data-componentwillmount-v...
Also see Lin Clark's "React Fiber" talk, linked upthread. Basically, pieces of work can start and be interrupted, and then be restarted, which will mean that `componentWillMount` can be called several times before the component _actually_ mounts.
You can use componentDidMount for that and its semantics are still the same.
Fiber is a rewrite that makes it easier for us to add new features to React (and it adds some). It also adds the foundation for enabling better perceived performance in the future releases thanks to async pre-rendering and more control over scheduling. That part is still work in progress and won't be enabled in React 16 by default.
So we do think eventually it’ll enable us to build more responsive apps, but we’re still working out the details and experimenting with what it can do. Don’t expect any drastic changes on this front in React 16.
Elm really could be the future of bullet-proof web development. It has everything it needs except for runaway popularity.
Does Fiber introduce any of those optimizations, or nah?
So much hype and no words about performance... I'm wondering if it's slower.
Regarding benchmarks, you might enjoy reading this: https://medium.com/@localvoid/how-to-win-in-web-framework-be...
[1] https://pdfs.semanticscholar.org/d10d/aba5df8b4c563b62fd01a3...
It should help with things where perceived lag is undesirable, like typing in an input field.
Relevant code if you're curious: https://github.com/facebook/react/blob/233195cb6bc632ade61a8...
Since requestIdleCallback leaves the scheduling out of your hand, how do you ensure nodes are still updated when you need it? Like tests?
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 their JS.
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 it be improved in any way to get below a few seconds? Or will I have to continue to write vanilla JS to get responsive apps?
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.
What's preventing us from using it in our apps then ? Do they limit the use of the API to what's implemented in Fiber in some parts of the website ?
If you left React for performance reasons especially related to real-time updates or animations, well this version is better.
https://thefeedbackloop.xyz/designing-and-implementing-glimm...
Can we write an efficient rich text editor like Google Docs in React? Or would it still be too slow?
https://facebook.github.io/react/contributing/codebase-overv...
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.
Thanks for posting this Scott, if anybody has questions about styled-components feel free ping me here or on Twitter. (@mxstbr)
With frameworks like React these days, content+behavior is in JavaScript already, and with writing CSS in JavaScript, we've gone back 1.5 decades I think.
When you start thinking in components it becomes much nicer to have the styling, logic and layout all in one file, isolated from the rest of the application and easy to edit, move around and apply to any page.
The previous 'best practice' of having these coupled aspects in separate files now seems quaint and tedious.
There are of course trade-offs, and CSS-in-JS has not triumphed yet, but if you've held off from considering this approach simply because you've had 'separation of technologies' drummed into you in the past you might be missing out.
http://javascriptplayground.com/blog/2016/07/css-modules-web...
What it lacks is some of the maturity. For example, dynamic loading of assets only works if they are static and the cli isn't trivially deplorable. It is also less standard among front-end developers, which mostly comes through in the selection of libraries available (Vue is close enough to vanilla templating that the learning curve is shallow.)
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!
> I would love to see some data backing it up.
In Stefan Krause' js-framework-benchmark, the vue implementation starts in 55ms vs 89-113ms for the various react implementations. See the 'startup time' row here: https://rawgit.com/krausest/js-framework-benchmark/master/we...
I haven't profiled vue and react on this particular benchmark, but I have done so for some of the other implementations. Baring anything exotic during startup, the 'startup time' benchmark comes down to package size. It takes time to fetch, parse, compile and load javascript. React is just a bigger package.
All disclaimers about benchmarks, microbenchmarks, n=1, YMMV, etc apply.
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).
I cannot imagine the shitshow that project would be using jQuery to track the state.
Nearly as soon as you progress from 'backend rendering html' to single-page-app, it behooves you to use React.
I try to fit the more traditional paradigm when I'm allowed to architect an app myself. I like rendering a page on the backend.
Anyway, you can read arguments by smarter people than myself: http://stackoverflow.com/questions/21862054/single-page-appl...
That's just one thread of many.
Worked on or maintained an existing app for a number of years? There is a very big difference.
there's no such things as the best approach for all needs. React brings you load of advantage but it assumes stuff you might not be ok with:
- spend time maintaining your project over time fixing stuff on version change that won't bring any direct value to your project
- you're ok with the licence and with the company maintaining it.
- hard to debug stack trace
- ship code that you have no control over, increasing the payload size (at least for small to medium size projects)
> I cannot imagine the shitshow that project would be using jQuery to track the state.
First nobody force you to use jquery. Manipulating the Dom isn't what it was when people had to maintain stuff on ie6. Dealing with the Dom directly isn't a "shit show" anymore and if you understand the concept of redux you can use those general concept and apply it in your project to manage the state. Plain Js simply assume the Dom isn't a magical piece of software, it just has prototype and stuff people usually don't like around here but hey, if you're coding stuff for the web, it's better to know how to deal with it than denying it
Es6 brings lot of great features you can use today, you don't need react for that
React and Redux is the easiest debugging has ever been. While its true that stateless crashing components can cause some headaches (will be addressed in Fiber), inspecting state and flow of actions, how something rendered or changed and why --- haven't had such a experience before with no other tool or language.
For small projects, sure, they might. But working at larger scale falls apart using plain html and jquery.
Scale was a poor choice of words. Front-end complexity is a better metric, and in particular complexity which relies on manipulating state.
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 import using <script>.
[Looks at facebook.com]
[Looks back at statement]
[Keeps building in React]
In reality those arguments don't hold water. In reality our field is 30 years+ old and there is some maturity in the way things are done. All this crazy shit of rewrite everything all the time will just eventually tire people out and people will cut this redo an entire framework just because out.
JavaScript is one of the most important languages around right now and pretty soon the adults are going to be taking it away from the kids. Just as an FYI, this is another example of that. Too many important decisions are happening without much thought about what's there already.
I don't know maybe I'm wrong and maybe this time will be different but I've been around long enough. I learned the ins and outs of angular only to be told "fuck that" shortly after. It all seems very wrong too me but maybe you can tell me otherwise?