If you told me that was the case today with web developers generally, I’d laugh at you even harder than I would have if you made that prediction ten years ago.

Because some checks are expected to be runtime only, it lets you specify types like "Odd integers" by writing a `where` clause.

``` subset OddInteger of Int where !(* %% 2) ```

You can use multiple dispatch to separate dispatch from processing: ``` subset Fizz where * %% 3 subset Buzz where * %% 5 subset FizzBuzz where * %% 15

  multi sub fizzbuzz(FizzBuzz $) { 'FizzBuzz' }
  multi sub fizzbuzz(Buzz $) { 'Buzz' }
  multi sub fizzbuzz(Fizz $) { 'Fizz' }
  multi sub fizzbuzz(Int $number) { $number }
  (1 .. 100)».&fizzbuzz.say;

Or even use inline anonymous subsets when you declare your functions: ``` multi sub fizzbuzz(Int $ where * %% 15) { 'FizzBuzz' } multi sub fizzbuzz(Int $ where * %% 5) { 'Buzz' } multi sub fizzbuzz(Int $ where * %% 3) { 'Fizz' } multi sub fizzbuzz(Int $number ) { $number } (1 .. 100)».&fizzbuzz.say; ```

Raku's type system is one of its features that will show you new ways of thinking about code. I advocate playing with Raku specifically for mind expansion because it has so many interesting ideas built in.

[1] https://docs.raku.org/language/typesystem

However, regularly it's not the case -- especially with people moving from nominal systems.

TS can't really be practically nominal when it has to be constrained by its compile target. So I guess it ultimately boils down to an anomaly/criticism born from the legacy of how web standards came about.

https://github.com/pomber/didact

At a high level though, you create a tree of nested objects. Each has a handful of special properties (children which contains an array of child objects being the most interesting to users). The rest of the properties are used to interface with the rendering engine by passing it configuration and (usually) event functions it can call when something happens.

That tree of objects gets passed to the rendering engine which turns the tree into some kind of output (DOM, Canvas, WebGL, Ink, etc)[0].

When something happens (an external event, a timer, event from the render engine, etc), your code potentially changes the object tree. React then walks that tree and uses a few shortcuts to quickly detect what has changed. Instead of re-rendering everything, it can give a list of things that have changed and what the new values are. The render engine then decides how to make those changes happen and the cycle repeats.

It's really pretty simple.

[0] https://github.com/chentsulin/awesome-react-renderer

- https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-...

I can also recommend Dan Abramov's post "React as a UI Runtime":

- https://overreacted.io/react-as-a-ui-runtime/

and then of course the actual React docs for learning how to _use_ React:

- https://react.dev/learn

Things like XSLT are really quite good if you can get past "ew xml icky"

You can inline different schemas in modular, bazaar like ways from a variety of sources and pull in different parsers that do different tasks.

For instance you could have, say an object subtype and pretend you, a spreadsheet developer made something compatible with it.

As the tool parsers the XML, it sees the spreadsheet, which it has never encountered however, the schema tells it where to get the parser so it dynamically loads it, passes off the subtree it doesn't recognize and lets your spreadsheet parser do its things.

It's remarkably clean and elegant clockwork for distributed modular applications.

Things like a mobile phones share feature would be a perfect use case: a wide variety of objects from different applications passing through the same schema with a share directive invoked that allows you to share in a variety of ways. XML can handle this quite magically.

I've built systems like this with XML, it just works. I was like "damn. XML... Who would have thought"

People just never learned XMLs killer features because it got a bad reputation as being the thing that out of touch enterprise Java bozos make messes with - which is true.

But that's also why JavaScript was shat on for 15 years. You gotta be adult enough to look past that. Try to separate the merits of a technology from your perceptive competency of its users.

The TS type system is neither especially powerful nor especially robust