sebmarkbage

My work seems to have made you angry which makes me sad.

You’ll at least be happy to learn that useEffect will be sync if the render itself was sync in React 18. Ofc if you do an async render those effects won’t work anyway and you need to do it in the event handler itself.

I doubt it’s much of a conciliation though. I agree the programming model is weird. It’s the best idea we had for what we were trying to achieve. Sorry for the trouble it has caused you.

I think this misses the point of what a senior developer is.

Nobody builds a huge thing by themselves better than multiple people can. Being a senior developer is enabling a few other people to do their best work.

Not quite. This PR is almost ready to do it.

https://github.com/facebook/prepack/pull/397

Currently it is blocked on Map/Set support in the output which is an outstanding issue. We could also try it with a Map/Set polyfill.

We're very close to being able to though!

In fact, this isn't just Prepack itself but it is Prepacking the JS part of the entire Node.js runtime as well!

(I'm "Sebastian".) It meant to read C. It definitely wasn't C++. However, now I'm curious if I'm confusing it with the later Amiga games. I'll need to look into this. I was 8 years old at the time. :) Note that this was for hobby projects many years after the original launch of those products - not mainstream dev.

Yea, this is clearly not enough to be a standard but we don't really know of a standard for this and it is not really our primary expertise.

If Sentry or others that understand this problem space better create a standard format, we would be happy to switch to that.

Everything have to start somewhere. :)

If it spread to a become a defacto standard format, wouldn't that be a good thing? That way you only have to deal with this once and it will work everywhere.

At that time, the size/parse time will have much greater impact because the total size of libraries will be smaller or unaffected.

At the same time it encourages libraries to put significant error messages in their code without fear of bloat which helps your customers in the end.

Personally, I hope everyone will follow.

Parse time is the new bottleneck of modern client-side web apps. Of course React on its own isn't going to move the needle but if other libraries follow along it just might. With better, more expressive error messages without paying the cost at scale.

Note that the stateless part is mostly just a stepping stone to a stateful variant.

https://github.com/reactjs/react-future/tree/master/07%20-%2...

React.DOM is still in 0.13.

The point of this is exactly to reduce the library size AND getting to a stable 1.0 release. By making the class system optional, it becomes an optional dependency which reduces the library size. Supporting only createClass in a stable 1.0 release would mean that we're stuck with that dependency.

The way we see it, ES6 and 7 are around the corner and then the createClass dependency becomes optional.

This is actually a way to eventually reduce the size of the library since it makes the class system optional.

We're definitely considering optional module based systems instead of OOP, but it's still too early. https://github.com/reactjs/react-future/tree/master/07%20-%2...

This is actually an anti-pattern that we're explicitly trying to get rid of. The fewer components you have, the fewer optimization hooks you have. This also have subtle changes in semantics, and disables local optimizations in the consuming files.

The idea of a lightweight declaration of a component (e.g. a just function) is definitely still on the table and might be resurrected in a different form.

https://github.com/reactjs/react-future/blob/master/01%20-%2...

Yea, note that mithril is on that list. The syntax was where people unified. There wasn't agreement on semantics and this is moving closer to that.

It's possible that this will eventually unify again. E.g. around a replacement for an object literal. E.g. a standard record type.

In CoffeeScript it might look something like this:

element = type: 'div' props: className: 'container', children: [ type: 'span', props: className: 'foo' type: CustomClass, props: className: 'bar' ]

(This doesn't fully work in 0.12 because we also have some extra properties on there but that's the direction we're going.)

0.12 is just adding React.createFactory. 0.13 will optionally replace React.createClass.

We do this so that there's a seamless upgrade path. We have to remove the warnings to fix the classes.

Hi, this was a tough call for us to make. We wanted to everything we could to avoid extra bloat for everyone. In the end, most people tend to use some kind of extra helper, even if it's not JSX. E.g. a custom library or another third party language.

One reason for this change is to make it possible to use object literals or record syntax where that is more appropriate than function calls. We don't currently recommend it because there's no validation in that case, so you probably want static analysis to catch errors. I would encourage you to play with the idea of using object literals instead of function calls though.

One compelling reason for this change is that in 0.13 you will be able to build components using plain CoffeeScript classes instead of relying on React.createClass. So, in the end, you will be getting some of that bloat/overhead back.

We're definitely not making React depend on JSX. We will continue to support non-JSX and fully support compile-to-JS languages. Unfortunately, that sometimes means a trade-off. In this case trading React.createClass for React.createFactory. Some would've preferred it be the opposite tradeoff but React.createFactory gives us more benefits than the opposite.

The difference is that if you use Object.observe to track changes, then you don't have the ability to hold onto the previous version of an object and know what the old value was.

This is important for animations where you want to animate from the object's old value to the new value.

We have a tool that does Canvas drawing from React too. Currently some pieces are cached in retained mode but it's just an implementation detail for certain performance characteristics.

https://github.com/facebook/react-art

Canvas APIs are currently not as fast as the DOM renderer. There's also a lot of added complexity with regards to layout, text flows and text input. The code you'd have to ship down to solve all that with pure Canvas isn't worth it for a lot of applications.

For things that has it's own layout and no text input (like charts/data visualizations) or complex editors like Khan Academy's math content editor (http://bjk5.com/post/53742233351/getting-your-team-to-adopt-...) it definitely makes sense.

React exposes event handlers and setState methods which are seemly mutable and Object Oriented. This is because React is designed for large scale organizations and to be approachable by a broad developer base.

However, once you have certainly complexity in your asynchronous flow, RxJS is a great way to express that.

The interesting part of our experiments (which we designed together with Erik Meijer) can be found here:

https://github.com/facebook/react-page/blob/082a049d2a13b141...

RxJS makes it easy to create abstractions from complex pieces of your async flow. The getStreams method in that example could easily be broken apart into multiple pieces.

This fits very well into the React model and is definitely a great compliment if your organization is already familiar with Rx.

React does the diffing on the output (which is a known serializable format, DOM attributes). This means that the source data can be of any format. It can be immutable data structures and state inside of closures.

The Angular model doesn't preserve referential transparency and therefore is inherently mutable. You mutate the existing model to track changes. What if your data source is immutable data or a new data structure every time (such as a JSON response)?

Dirty checking and Object.observe does not work on closure scope state.

These two things are very limiting to functional patterns obviously.

Additionally, when your model complexity grows, it becomes increasingly expensive to do dirty tracking. However, if you only do diffing on the visual tree, like React, then it doesn't grow as much since the amount of data you're able to show on the screen at any given point is limited by UIs. Pete's link above covers more of the pref benefits.

Consider the architectural difference of React vs. one of the similar "view model" frameworks. It's similar to the difference between Git vs. SVN.

Other view model frameworks typically track all changes to the view model by explicitly firing an event for every delta change. That in turn causes another delta and so on. This is similar to SVN where every change is a delta from the previous state. That means that you'll need to codify every possible diff through your view hierarchy/graph. For simple stuff, they have built-in tools to help you do this. For complex views, that's really difficult or impossible (you can get into conflicts and deadlocks).

React makes it easy by simply regenerating a copy of the next view. This is similar to Git where every change is a snapshot.

There are benefits with either architecture, but I'd recommend you figure out what benefits matter more for your use case. I'm just pointing out one area where React is different.

Here's an implementation in WebGL

http://blog.calyptus.eu/seb/2010/11/webgl-not-just-for-3d/