3 ms·
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.
by leeoniya 11y ago
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.
- evv 11y ago> 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.
- ngokevin 11y agoYou'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.