This approach is simple but does not scale. People did this long time ago, perhaps starting with SmallTalk in 80’s and VB/Delphi in 90’s.

You need separation between components and data. For example you got a list of 1000 objects, each having 50 fields. You display 100 of them in a list at a time. Then you have a form to view the record and another to update it. You may also have some limited inline editing inside the list itself. Without model it will be hard to coordinate all pieces together and avoid code duplication.

▲

epolanski 2 months ago | parent | next [-]

That screams pub sub which is trivial with JavaScript proxy imho.

▲

homarp 2 months ago | parent | prev | next [-]

can you elaborate on the 'don't scale part'? because apps in 90's don't see 'smaller' than webapps now

	▲	kikimora 2 months ago \| parent [-]
		Typical Delphi or VB app didn’t have model, instead it read database and put everything into controls (aka data binding). The it kept logic in event handlers. This code is a) hard to read and understand because logic is dispersed across event handlers and b) causes a lot of duplication. Over time codebase evolves into a mess. This is not the only way to create a mess. But this one works every time.

▲

austin-cheney 2 months ago | parent | prev [-]

So, state is simple, stupid simple.

The way to keep it simple is to have a single state object, which is the one place where state is organized and accessed.

The way to make it scale is architecture. Architecture is a fancy word that means a repeatable pattern of instances where each instance of a thing represents a predefined structure. Those predefined structures can then optionally scale independently of the parent structure with an internal architecture, but the utility of the structure’s definitions matter more.

Boom, that’s it. Simple. I have written an OS GUI like this for the browser, in TypeScript, that scaled easily until all system memory is consumed.