4 ms·

<Foo bar="baz"/> = React.createElement(Foo, { bar: "baz" })

lhorie 6y ago
Technically, it depends on what babel plugin and configuration you use (e.g. it compiles to `h(Foo, {bar: "baz"})` for a preact setup and to completely different code w/ a Solid.js setup)
JMTQp8lwXL 6y ago
I don't understand how people claim this is hiding huge levels of complexity. It's trivial syntactic sugar. If stylistically, you don't like it, oppose it on those grounds. But complexity? It is syntactic sugar for a function call.
- kansface 6y ago
  I agree with you - so much so that I don’t use source maps to debug stuff. It’s also the same reason I strongly dislike hooks (they aren’t really JS) while at the same time, they solve a problem I very rarely have (shared behavior without shared state).
- kls 6y ago
  The opposition to it on fundamental grounds is born out of wrongheaded and misapplied best practices and quite frankly it needs to die. Dijkstra is credited with the idea of separations of concerns which is a valid application of code organizational management. The problem is, somewhere along the way (in the dawn of the web) we conflated separation of technology with separations of concerns. Thinking that separating technologies for technologies sake somehow made code more maintainable but the reality is, that it was dogma, if a snippet of JS, a snippet of CSS and a snippet of HTML will only ever be used as a black box component and only ever be reused as that black box component in total, separation of technology only leads to more complexity in interfile dependency and mental compos-ability of the whole solution in ones mind. There is an argument that separation of technology leads to simpler build management, but I personally will take a little more complexity in my build over complexity in the code base as usually a build becomes fairly static as a project matures.
  - sibeliuss 6y ago
    This argument maps to CSS-in-JS, too. It's a misunderstanding that this pattern would be rejected outright.

Technically, it depends on what babel plugin and configuration you use (e.g. it compiles to `h(Foo, {bar: "baz"})` for a preact setup and to completely different code w/ a Solid.js setup)

JMTQp8lwXL 6y ago

I don't understand how people claim this is hiding huge levels of complexity. It's trivial syntactic sugar. If stylistically, you don't like it, oppose it on those grounds. But complexity? It is syntactic sugar for a function call.

kansface 6y ago
I agree with you - so much so that I don’t use source maps to debug stuff. It’s also the same reason I strongly dislike hooks (they aren’t really JS) while at the same time, they solve a problem I very rarely have (shared behavior without shared state).
kls 6y ago
The opposition to it on fundamental grounds is born out of wrongheaded and misapplied best practices and quite frankly it needs to die. Dijkstra is credited with the idea of separations of concerns which is a valid application of code organizational management. The problem is, somewhere along the way (in the dawn of the web) we conflated separation of technology with separations of concerns. Thinking that separating technologies for technologies sake somehow made code more maintainable but the reality is, that it was dogma, if a snippet of JS, a snippet of CSS and a snippet of HTML will only ever be used as a black box component and only ever be reused as that black box component in total, separation of technology only leads to more complexity in interfile dependency and mental compos-ability of the whole solution in ones mind. There is an argument that separation of technology leads to simpler build management, but I personally will take a little more complexity in my build over complexity in the code base as usually a build becomes fairly static as a project matures.
- sibeliuss 6y ago
  This argument maps to CSS-in-JS, too. It's a misunderstanding that this pattern would be rejected outright.