I'm sorry but I had a really bad visceral reaction to the sample code. All of the declarative 3D languages haven't been very successful, and for good reason -- they generally just get in the way.
Three.js is such a joy to code in because it has a great API and works well with functional javascript.
Not everything needs to be declarative, and if you need a model for your three.js application there's nothing preventing you from using something immutable.
1M times this. The desire to wrap everything in declarative constructs just forces you to learn more and more proprietary DSLs for a curated subset of features. Eventually you _will_ run into roadblocks and have to fall back to imperative.
The trend to React-wrap all the things is truly baffling to me. Some problems are just not meant for this. It works well for HTML/CSS and UIs because these have always been declarative, so is a natural fit and is a superset plus sugar.
> Eventually you _will_ run into roadblocks and have to fall back to imperative.
This is the case with low-level components, which is why React's lifecycle methods make it so easy to fall back on imperative code.
> The trend to React-wrap all the things is truly baffling to me. Some problems are just not meant for this. It works well for HTML/CSS and UIs because these have always been declarative, so is a natural fit and is a superset plus sugar.
My mind may be twisted from working with React every day, but I would say that a declarative API tends to be more natural when building real world applications. Not just for HTML and UI. At Facebook for example, we declaratively describe the data needs of each component and mutation using GraphQL and Relay.
You've seen A-Frame? It's an equal set to three.js and embraces the combination of imperative + declarative. Declarative is just a thin abstraction layer on a system that lets you wrap three.js code into composable and reusable modules.
React could then optionally be wrapped on top of that in a way that adds value.
I agree, and actually the same can be done the other way around. You can create a React component that handles 99% of all your Three.js code then just have that and this UI used together at a high level.
Three.js' API is great for 3D programming but creating UIs suffers the same problems as creating UIs with plain JS in the DOM.
Also, no need to feel sorry! This is just an exploration at this point, so it's interesting for me to hear peoples' reactions whatever they may be.
Don't mean to hijack, but A-Frame might do you well. Even though it looks declarative, it's just a very thin abstraction (that is actually useful) on top of three.js. Thin enough that it can do anything that three.js can.
Sort of, but not really. That library is sort of solving the same problem that React Three solves. React Three UI allows you to design 2D UIs (using flexbox, animations, etc.) that can be placed in 3D space using the existing React Three API.
10 comments
[ 3.7 ms ] story [ 29.7 ms ] threadThree.js is such a joy to code in because it has a great API and works well with functional javascript.
Not everything needs to be declarative, and if you need a model for your three.js application there's nothing preventing you from using something immutable.
The trend to React-wrap all the things is truly baffling to me. Some problems are just not meant for this. It works well for HTML/CSS and UIs because these have always been declarative, so is a natural fit and is a superset plus sugar.
This is the case with low-level components, which is why React's lifecycle methods make it so easy to fall back on imperative code.
> The trend to React-wrap all the things is truly baffling to me. Some problems are just not meant for this. It works well for HTML/CSS and UIs because these have always been declarative, so is a natural fit and is a superset plus sugar.
My mind may be twisted from working with React every day, but I would say that a declarative API tends to be more natural when building real world applications. Not just for HTML and UI. At Facebook for example, we declaratively describe the data needs of each component and mutation using GraphQL and Relay.
React could then optionally be wrapped on top of that in a way that adds value.
Three.js' API is great for 3D programming but creating UIs suffers the same problems as creating UIs with plain JS in the DOM.
Also, no need to feel sorry! This is just an exploration at this point, so it's interesting for me to hear peoples' reactions whatever they may be.
https://hacks.mozilla.org/2016/03/build-the-virtual-reality-...