4 ms·
> move the UI/DOM building back to the server side > Intercooler responses are HTML fragments. I'd argue that, just like described at the end of the article,
by aikah 11y ago
> move the UI/DOM building back to the server side
> Intercooler responses are HTML fragments.
I'd argue that, just like described at the end of the article, it's just shifting the burden on the server. It's a trade off.
IMHO React gets a lot of things right :
- DOM diffing
- Components
- 1 model as a unique source of truth
And when one thinks about it, IT IS MVC in its purest form, since there is only one model, one big view(the tree of components) and one controller(using event delegation). What React nailed is an efficient way to rerender the view.
- carsongross 11y agoReact doesn't solve the fundamental problem of either API churn or security issues in browser client code. It may be elegant (I don't think it is) but it is orthogonal to the issue at hand. Server side MVC and HTML as a transport has a huge number of advantages, not the least that HATEOS "Just Works" without anyone having to think about it, but even if it didn't, I would think that the API churn/security tradeoff would give the development community pause about heavy client-side logic.
- Silhouette 11y agoReact doesn't solve the fundamental problem of either API churn or security issues in browser client code. I'm not sure what problems you are referring to here, since you don't seem to have defined them anywhere. They sound like they'd be well outside the scope of a library like React, though, which is essentially just a declarative UI rendering tool.
- xg15 11y agoAnd rendering on the server solves API churn by... having no API at all? Then what do you do once you'd like to add non-browser clients like native apps or an actual API for third parties? Additionally, I don't see how rendering on the server frees you from thinking about security or setting (and enforcing) proper permissions. All you gain is that the problem is less visible and your entities are obfuscated in chunks of redundant HTML. In fact, now you may open up new security holes like XSS that you can avoid easily with proper client-side widgets.
- kuschku 11y ago> What React nailed is an efficient way to rerender the view. Well, it’s not really efficient. A more efficient solution might be if we wouldn’t even need DOM diffing, but instead every module would be based on a reactive model, and we wouldn’t have to deal with the diffing anymore.
- aikah 11y agoI'm not sure how it would work since the DOM is not reactive. At the end of the day, any "view" library for the browser is a DOM builder. It cannot be reactive, by nature. edit: s/nature/definition
- teleclimber 11y ago> It cannot be reactive, by nature. Indeed it can't. But you can get close. The key is that the side-effect has to be much more granular. Instead of re-rendering a virtual dom for an entire component as a side-effect, the side-effect is changing a single attribute on an element, or updating its list of children. This means using a template language where one can make these associations between variables and DOM. JSX doesn't work here because its output could be anything. I am toying with an experimental framework that implements these ideas. I am convinced we can do better than diffing vdoms.
- mtzaldo 11y agommm... Instead of a dom it will be called dam (domain actor model)... look ma' I can also write cool stuffs...