6 ms·
I've always thought the "HTML in JS" was in fact a strawman argument set up to deviate the attention from the fact that it is indeed a different syntax for func
by genezeta 8y ago
I've always thought the "HTML in JS" was in fact a strawman argument set up to deviate the attention from the fact that it is indeed a different syntax for function calls (and class instantiation). And it is actually that the thing that I dislike about JSX. I think it's a bad syntax for function calls/class instantiation.
I do like hyperscript better than JSX... precisely because it's not a syntax for function calls. Because it's just a function.
- TomMarius 8y agoIt's not just that. The abstraction placed between a Node and an Element is very important and crucial for React (and for a good reason, this is similar to a well-known programming paradigm used for 3D games). I'd say there is a significant semantic difference that can be simulated by a function call (you can simulate nearly any statement).
- abritinthebay 8y agoIt doesn’t have to be function calls though. Conceptually it’s a nested model, that’s it. It could quite easily be a series of nested objects. The point is not that it abstracts functions it’s that it abstracts nested nodes. Anything else is a library implementation detail.
- scriptkiddy 8y ago> I do like hyperscript better than JSX... precisely because it's not a syntax for function calls. Because it's just a function. You should check out Elm: https://elm-lang.org/ https://elm-lang.org/. It uses a hyperscript like syntax for rendering in a functional style. It's all just functions, and it reads that way too.
- WorldMaker 8y agoIt's not entirely a strawman, because there are legitimate concerns about separation of concerns that the "HTML in JS" argument worries about. Especially in the web world which still knows the legacy against fights of business logic in templates going back to "bad old PHP days", etc. There are good reasons to be skeptical about JSX simply because of the worry about how much business logic may accidentally be embedded directly into views. For JSX, the answer is typically to solve that in other areas of workflow and patterns of habit. But the war between "as dumb as possible a templating language" and "just let me use my real language for templates" will probably wage on in the web space forever.
- tracker1 8y agoMaybe it's best not to think of React as a View but a Component... You can create Components that are simple Views and render what they are given, you can also create smarter Components that are more in line with Controllers. As a loop: Store -> State -> Reducer -> Component -> Action -> Dispatch -> Store ... Or if you want something closer to MVC, you could use MobX or similar.
- WorldMaker 8y agoI've been sold on JSX for a while, personally, and pretty much have that architecture in my apps I'm working on. I just also remember being an idealistic Django-loving youth that wanted the dumbest possible template engine to avoid teenage PHP drama, so I definitely sympathize with folks whose gut reaction is upset with JSX for crossing the streams (again), and thought to make sure it was clear that it isn't a straw man argument to many. (Even if it is also, as in my case, an argument that can be won in favor of JSX. Though also in my case one of the big factors winning that argument was TSX [Typescript type checking of JSX views] versus many of the alternatives and their [lack of] static checking/analysis.)
- tracker1 8y agoHyperscript roughly equals React.createElement, JSX transpiles the same for either pragma. JSX is just a more natural syntax to those used to HTML/XML directly as an expressive syntax. Nobody is forcing anyone to use it... `const h = React.createElement;` if you prefer the functional syntax directly.