| ▲ | mattlondon 2 hours ago |
| Wait until you see React & JSX... At least html and CSS are both presentation. React/JSX now confuses presentation and business logic. |
|
| ▲ | lateforwork 2 hours ago | parent | next [-] |
| > React/JSX now confuses presentation and business logic React was originally designed to be the "V in MVC". You can still use it that way. React becomes very simple when you only use it as the V in MVC. |
| |
| ▲ | azangru 2 hours ago | parent [-] | | What are the M and the C, and how do they talk to the V in this case? | | |
| ▲ | lateforwork an hour ago | parent | next [-] | | M stands for Model layer. This layer handles business logic and knows nothing about UI. It does not have any html or CSS. V stands for View. This layer handles HTML and CSS. You can use React here. C stands for Controller. Controllers know about Views and Models and which model objects to instantiate for which view. It makes REST API calls and does caching, and handles errors. Controllers know about the application state and decide what page to display next. For an application written in this style see: https://github.com/wisercoder/eureka/tree/master/webapp/Clie... (This app doesn't use React, but does use TSX, and you could use React as well). | |
| ▲ | apsurd an hour ago | parent | prev | next [-] | | react can be pure functions that take in props. Given a set of props, ideally data primitives, the outputted view is guaranteed. it's nice. In practice, the entire JS ecosystem enjoys flying off the rails, every season, but it's not strictly react's fault. To answer your question, however those props get into the component is up the the M & C. can be async server, or shoved in as json in the script tag. | | |
| ▲ | azangru an hour ago | parent [-] | | If you move the data (the M and the C) entirely out of react, and only pass it in via props, there would be only one place — the root react node — where the props could get into react. Is this what you have in mind? Or are you envisioning multiple root nodes? | | |
| ▲ | apsurd an hour ago | parent | next [-] | | Well, i've always been a fan of the island architecture that effectively mounts root nodes as little islands of isolated state, yes. Mainly this avoids the hell that global state SPA patterns produce: redux, reducer patterns in general, and 8 thousand context providers. I do think there's use cases that warrant global in-memory state, but it's such a pain in the ass to maintain and evolve, i'd always plan against it. Every html node in your app does not need to know about literally everything going on and react instantly to it. it just doesn't. Just make another page! Also: so the islands pattern can be as fancy or rudimentary as desired. they can bootstrap themselves via async endpoints, they can be shipped as web components even, or they can be static, pre-hydrated in some manner. | | |
| ▲ | kittbuilds an hour ago | parent [-] | | The islands pattern is underrated for maintainability. I've found the biggest win isn't even the state isolation — it's that each island can have a completely independent upgrade path. You can rewrite one island from React to vanilla JS (or whatever comes next) without touching anything else. The global state SPA pattern fails for a more fundamental reason than just being painful to maintain: it creates an implicit contract between every component in the app. Change one reducer and you're debugging side effects three layers away. Islands make the contract explicit — each one owns its data, full stop. The one gotcha I've hit is cross-island communication. PostMessage works but gets messy. Custom events on a shared DOM ancestor end up being the cleanest pattern for the rare cases where islands genuinely need to coordinate. |
| |
| ▲ | tim1994 an hour ago | parent | prev [-] | | With signals you can avoid the prop drilling. I think signals can help a lot with this approach | | |
| ▲ | azangru an hour ago | parent [-] | | I think the parent wants to separate the V from the M/C. If you smuggle signals inside of components to avoid prop drilling, you would be coupling the M/C and the V. I suppose that's not what the parent has in mind. |
|
|
| |
| ▲ | cbarrick an hour ago | parent | prev [-] | | - M for Model: your data model.
- V for View: views of your data.
- C for Controller: does stuff with your data. |
|
|
|
| ▲ | madeofpalk an hour ago | parent | prev | next [-] |
| I think you're confusing business logic with view logic. |
|
| ▲ | bromuro an hour ago | parent | prev [-] |
| React is great for MVVM indeed. Who is still using MVC in 2026? |
| |
| ▲ | interlocutor an hour ago | parent | next [-] | | Ever heard of Django? ASP.NET? Most UI frameworks, including ASP.NET Core, Spring Boot (Java based framework), Ruby on Rails, and Django (Python) are all based on MVC. | |
| ▲ | flowerlad an hour ago | parent | prev | next [-] | | MVVM was invented by Microsoft for 2-way syncing in WPF. Today we know 2-way syncing is a mistake. Who uses MVC in 2026? Pretty much every framework out there, including Java frameworks and Python frameworks and .net | | |
| ▲ | ozim 4 minutes ago | parent [-] | | You have any more sources on MVVM being a mistake? I found WPF rather nice to work with. Same with knockout.js and Angular I don’t see much downsides. Everyone can write bad code of course in each of them but I think it was working quite well. |
| |
| ▲ | techpression 41 minutes ago | parent | prev [-] | | Adding to sibling comments, Phoenix. And it’s a damn nice experience at that. |
|
