What's with everyone's obsession with React recently? All I see is a template engine and not a particularly good one. You're still left with the same problem mixing your HTML into JavaScript.
The thinking--and I'm not sure I agree with it, but it doesn't seem that objectionable--is that, while the HTML/CSS/JS separation makes a lot of sense for documents, it does not necessarily make as much sense for applications. HTML is just being used as a rendering language, not as a content description language, if that makes sense? And so the split between them might not make as much sense.
As a template engine (which I'm not totally sure is the correct term for it), I will cape up for it (more from a React Native perspective than a React perspective, and with the caveat that I think the JS world is mostly a crime-in-progress). I haven't found something that I've enjoyed working with in the JavaScript world nearly as much as React.
So 100% agree. I haven't found something I've enjoyed working with in JavaScript.
The environment I work on usually has very clean MVC and the issue is always that the designers I work with don't know javascript but need control over the HTML so I'm always taking their raw HTML with almost no javascript and basically reworking the HTML & CSS to do the animations or w/e is necessary.
I've tried React but generally I just get very dirty .JS files with mixed HTML/CSS in them. It's honestly not as clean as people make it out to be unless you're working with UI/UX people who know JavaScript already.
Literally every time I have an HTML/CSS person mess with the code I have to fix the JavaScript afterwards.
I think the implications of UI/UX people who don't know JavaScript is probably not great to begin with, yeah? I'm not sure that React isn't just exposing a flawed assumption that maybe we shouldn't have had in the first place.
TL;DR: It's not about the HTML in Javascript; it's about being able to declare all the states of your UI in a stateless way. The result is that React components are like pure functions: you pass them inputs and you get predictable outputs.
We use ExtJS a lot. But I think the exact opposite is the case. With ExtJS, you have the usual double-binding, e.g. if you set this property of that Model somewhere in your view hierarchy some little snippet of HTML are inserted/removed from the DOM. It's basically side effects only.
If I understood it correctly, one can think of react app/page as a pure function taking data and producing a DOM.
Reasoning and testing pure functions should be much easier than a set of components which partly rely on side effects.
I've used both React and ExtJS. Overall React is much easier. ExtJS becomes a mess of event handlers, just take a look at all the possible events when working with their trees. In theory it looks great, in practice it's hard to follow the code and performance is terrible. The two way binding causes all sorts of headaches including the usual remove listener, update model, add listener type code. It's difficult to follow what code updates what part of the DOM. With React I only need to look at a component's render function. Same with the component's state.
React is not about templating. It is about swapping an O(n^2) problem of transitioning between all N possible states of your app for an O(1) problem of describing what the UI looks like in any state and letting a machine do the transitions.
JSX is convenient but all React really requires is putting all of the logic to render a component under one method. You could carefully construct a piece of XML or something like that in render and then pass it to a templating engine of your choice°, instead of any JSX.
But JSX is as nice a language as any for templates, and side effects in render are clearly wrong in React so the old issues of turing compete templating are ameliorated.
° You'd have to do a tiny bit of wiring to make sub-components go back into the react pipeline.
I found the whole update state and have the UI automatically render on state changes a very useful model. You only need to define the UI once, and have the real time rendering left to the state watcher.
It's a useful model, but I've found that it can break down a bit on really large, complex apps. If a piece of state is being passed to multiple places via props (either manually or using something like Redux), it can be difficult to see at a glance every place in an app that a single bit of state is being used.
Going back quite a few years now, I once worked on a GWT app that kept its state in a central store, and updated it via firing events on an event bus. In practice, it worked somewhat like Redux, but instead of mapping state to props, in each component you'd subscribe to the update event and then update the relevant bits of the component in the event handler. Being Java, it was easy to find all references to the update event to get a quick understanding of exactly what it was being used.
Come to think of it, it would be easy enough to use React that way too, especially if using TypeScript and maybe something like RxJS.
> it can be difficult to see at a glance every place in an app that a single bit of state is being used
What problems has this caused you? Personally, I find being oblivious to what specifically needs to update is useful but I'm interested in situations where that's not the case.
> It's a useful model, but I've found that it can break down a bit on really large, complex apps. If a piece of state is being passed to multiple places via props (either manually or using something like Redux), it can be difficult to see at a glance every place in an app that a single bit of state is being used.
This is why a UI app state query-based approaches (ex: om next) on a single app state tend to be a bit easier, but still can suffer from what you describe (especially if queries are dynamically built by a user or something). At a minimum, you can either re-use the same query or at least know through the query syntax where your code is touch some bit of state as it should be available for analysis by an IDE and easily searchable as plain text. Still, there's not really a perfect solution I've seen and eventually things can get messy if you aren't careful and as you increase the number of developers touching code.
In general, updating a UI only based on changes is a great approach. The challenge has always been identifying what changed and minimizing the tracking of those changes in scalable way. I saw many old approaches use things like dirty flags everywhere or doing field comparisons one by one. Things like react frameworks in Clojurescript make this so much easier today because you can do a very fast identity check that is cheaper using immutable structures like those in Clojure. If your check itself is expensive, the benefits of a delta-based approach are limited vs. giving up and doing full re-renders. I've hit this in game programming either way, but usually the change approach wins unless there's some very specialized case or design issue or simply just tons of raw power it's not an issue anyway.
Where events themselves suck is predictability. This is doubly so for systems that introduce event hierarchies i.e. inheritance-like constructs for events. I strongly prefer deterministic approaches to rendering when possible. That's not to say you re-render at a fixed interval, but rather attempt to re-render changes only if they exist. It makes debugging, optimizing, and understanding the system so much easier.
From a performance and debugging point of view, events or signals and slots tend to cause situations where you're jumping so much over the code you lose all kinds of CPU cache or GPU benefits (buffers, batching, pipelining, etc.) depending on what you are doing. Also some event systems use a lot of objects and in systems requiring allocations on the heap and/or garbage collection, this can become really ugly if the app is running for awhile. Events do make things easy for small projects, but tend to create spaghetti for larger ones, even with a single event bus. Approaches using loops, deltas and possibly queues/mailboxes tend to scale a lot better for games, and also for apps that have performance issues. A side benefit is your state tends to become a functional reduction, which has its own benefits such as making undo/redo, logging, and error handling easier.
Sometimes I'm rather confused by all the UI issues created in app dev. I understand them, but as someone who has many decades of experience doing both game and app development, I'm like wtf app programmers. React and things like it are or can be at least a bit closer to loop, pipelined, time approach that's used in modern game architectures precisely to achieve consistent performance and do sane things in the face of GPUs.
