Readit News def get_user_data(user_id: int) -> Dict (JSON-looking data):
...
def render_user_view(user_id: int) -> HTML:
user_data = get_user_data(user_id)
render_template("user_detail_view.html", context=user_data)
People tend to overestimate the "interactivity" needs of their apps and underestimate what they can achieve by just swapping HTML. HTMX also lets you swap "Out of Band" [0]. This makes it easy to model more complex interactions (like "reactions"), for example, updating a counter somewhere else in the app when a form is submitted. Reactive frameworks can also become a Rube Goldberg machine if an app is not properly designed from the beginning. Then you start fighting rendering loops, build dependencies, components' side effects, etc.
Personally speaking, HTML-driven apps are not just about easy vs. hard development, it's also about your users [1]. Maybe a big React app runs fine on 8 CPU cores and 32 GB of RAM, but very often, your users just want to read some content, maybe submit a few forms, and leave. They may not want to download 2 MB of JS so that the page can render boxes with text, even more if your browser can already do that if you give it some HTML.
[0] https://htmx.org/attributes/hx-swap-oob/ [1] https://shkspr.mobi/blog/2021/01/the-unreasonable-effectiven...
@inertia("User/List")
@api_view(["GET"])
def get_users(request, **kwargs):
// ...
return Response(data={"users": users})
(as-> [:foo :bar] v
(map name v)
(first v)
(.substring v 1))I guess in fairness you probably don't want to follow people who tweet like this but these kinds of tweets will still be hard to avoid. I'd rather just pay twitter $x/yr for no ads.
The real problem here is not the mutability of the state, it is the ownership of it. Who is responsible for keeping the state internally consistent ? In this code the answer is: no one.
To solve his problem, there needs to be a clear owner of the state, and that code should be the only code directly affecting the state and and be responsible for keeping the state internally consistent.
Wether this 'owner' is a collection of functions that operate on a global state in a language like C, or on a state passed in and returned, or an object in an OO language, or whatever. Doesn't really matter.
For example. Moving the character and collision detection should not be two separate function that affect the state but that can be called separately (or in the wrong order) and keep the system in an incorrect state. Only the code responsible for modifying the state should do so, and it should guarantee to leave it in a correct state on returning. Moving without collision detection can leave the system in an incorrect state and thus should not even be a function that exists.
When designing a system this is always something I keep in the back of my head: who is responsible for what ? Once you have that clear, things become much easier.
Congratulations, you have reinvented the style="" attribute.
For communications I think the way to do it might be to create 3-4 levels of responsibilities and say that no single player can operate in more than a few levels at once and must offer their services via live public auction or standard public wholesale pricing.
For wireless the way I'd split is is: 1. Location/site management, aka who owns/manages the poles. 2. Operating the actual Networking/Peering equipment, networking to the site with permission of #1. 3. Consumer/retail such as MVNO; direct-use in the case of large businesses, or value-add aggregation/resale for intermediates.
For wired the way I'd split is is: 1. Global networking/peering. 2. Regional networking/peering. 2. Last-mile equipment/rights, servicing. 3. Consumer/retail, value-add etc.
The goal here being to reduce the barrier to entry for small players via horizontalization which increases competition but not draw too many hard lines so that players have some flexibility in organization and so that players in one level have the opportunity of punching through to an adjacent or skip level if it is being overpriced.