Vue.js 3

So you suggest switching from one of the Big 3 to Mithril because you are concerned about market share, while Mithril probably has magnitudes less market share?

> I don't really understand [X]. Doesn't [Y] make your app difficult to reason and debug it?

It (passing mutable values around) does make it harder to understand the data-flow, yes.

But we programmers keep assuming our rules & protection & orderliness are helpful & necessary. And those patterns we opt in to keep getting codified, embraced. But along comes someone who breaks those rules, & it keeps turning out, a lot of the things we think we do to be orderly & safe & sensible are actually not that helpful at all, or have impeded really wonderful progress elsewhere.

I think of React. Until React came along, everyone doing web development knew, it was obviously correct, that we needed templating languages. We knew we needed content & code separate. We knew content was obviously a different beast than code & that content should have tools designed for content. As it turns out, mixing code & content actually works really well & that we had ruled out a wide space of possibilities that were really simple, powerful, & direct.

Relatedly, here, with shared-mutable-variables, I'd pitch that hopefully tools compensate for a lot. Hopefully it's possible to run the app & see who is modifying values, see who is being updated when values change. It's nice being able to have the code tell you, up front, easily, but also hopefully watching at runtime is possible, makes it easy to suss out what the connections & causalities are within a system.

Which template engine? Then what if you realize you need a router? Then the developer who glued those together leaves, and all you can hire is juniors.

There are benefits to using the industry standard (which today I consider Vue, React, Angular and slowly Svelte), you can learn it quickly, as it has ton of resources and you can hire easily, as you aren't forcing someone to use some obscure, home baked js framework.

That's my take at least.

One example is building an application like minesweeper. Would you really want to tackle that with jQuery and templating engine? I'd rather break everything into components, have them talk to each other through a state manger like vuex or redux, and only phone home to my API for important things, like the final game score.

It's almost a necessity for complicated apps. Right now I'm building an app which involves a reporting screen with all the following features on a single page:

- 10+ breakdowns for report - 10+ filters for report - Each filter has an include/exclude dropdown list which then has multiple features within even a single filter (so some filters are EQUALS/NOT EQUALS) others are INCLUDES/DOESNT INCLUDE/EMPTY/NOT EMPTY and all the appropriate options for each filter, not to mention clearing filters, etc - column sorting - column hiding - filtering with search - pagination on both client and server side (50K rows batching into sub pagination groups which client side takes over on server batches) - a dropdown at the top which re-initializes EVERY piece of data with a different account and changes quite literally re-initializes 50+ "states" of the UI on the page

Thinks of google analytics

First of all, we can assume doing this on the front end is 100% required. Imagine using google analytics where every single option you change is a backend request. Impossible, so now that weve gotten past that...

Imagine using something like jquery or custom JS where you try to manage the incredibly complicated input/output nature of each component of the page.

Component based design is required because you can keep all your logic for the entire app for a single TINY piece of the app in its own file. So something like a dropdown menu can get its own component called ``, and within that you define all "outer state" that component can use as a prop, or input state (so for example, you want the items that appear in the list to be defined OUTSIDE the component so the component can be re-used). However, that component also has its own internal state, such as whether its open or not, whether its animating or not, what item is selected etc, so if a component has internal state, then you store it IN the component itself. So now the 'state' of EVERY component on the page is defined in 2 places... the originator of the state (such as the component which holds your API calls), or in the component itself. When any change takes place in ANY of those states, all components related to that state "update" automatically to use that new state. This means by simply making a new API call, the outer component state changes, and every single component that relies on that state updates accordingly, even for the most complex UI imaginable its trivial to think about 95% of the logic because all the state is exactly where you expect it to be, and when there are infinite numbers of nuanced side effects, you usually program them IN the component and you dont have to clutter your actual logic (say for instance the api updates your base state, you want the dropdown to reset to zero, so you would code this into the component itself, so that everywhere on the page that uses this component it would all follow suit).