Back-end languages are coming to the front-end

They do create a new VM isolate. That’s a cost your workload will need to exceed before you get much if any benefit.

As far as thread count, my default guidance is 50% of cores if your CPU has SMT/hyper threading, coreCount - 2 otherwise.

Those numbers can go higher depending on how much of your workload is CPU-heavy. If you have an even mix of compute and IO, for example, your threads will frequently be idle/less contentious (same principle as the single threaded event loop).

And if your workload is a queue of short lived, isolated steps, I also recommend pre-spawning idle threads (potentially well beyond that active maximum). Pre-warming those isolates can help as well, or isolating with vm APIs (eg SourceTextModule) instead.

As with, well, everything: your mileage may vary, it depends on your actual bottlenecks and constraints, as well as your tolerance for tuning.

In practice, there are two things:

- crash on error - functions are just functions

The first one is counter intuitive to many programmer. Basically you use pattern matching aggressively, like this:

    def full_name(%{first_name: >, last_name: >}) do
      "#{a} #{b}"
    end

This code will work only if a map/struct with the correct non null field are passed. The pattern match utf8 string of at least 1 valid utf8 character. Any other argument will crash.

Crashing in elixir is the way to handle unexpected things. For example, you will do:

    {:ok, myobject} = DB.get....

And if the DB fails (something unexpected), it will crash, the process will be restarted and the live view connected remounted and it will start again from a clean state.

Of course, error that are expected should be handled.

The second thing with elixir, is that functions are decoupled from data. You can move them around easily. For example, the above function will work on any struct with the correct fields and a plain map. But you can pattern match on specific struct too, which makes the code more like OOP, but it is more rarely done.

The key idea is to restrict code paths to something you expect, and always be explicit about what to expect.

How does your framework handle re-rendering large components? E.g. a table with 1000 rows. I can't see any obvious mention of virtual DOMs so I assume you're not using them.

You might say virtual DOMs are exactly what you're talking about when you talk about the design choices of popular frameworks.

It fundamentally comes down to the idea of writing functional components. I declare exactly what I want my UI to look like as if render() is called every frame. But I don't care _how_ it gets there.

The complexity comes from taking this declarative UI and making it performant.

I don't doubt that 90% of web pages could get away with not using React or Vue or Angular. But as someone who loathes writing complex applications with pure HTML and JavaScript, they do serve a purpose.

I've written web apps that are basically just one large render() function with pure JS/HTML and it gets the job done. But at some point you do need to optimise and then it all falls apart.

From a costing perspective,

- hosting a web sockets server is expensive

- bandwith is cheap

- client cpu is free

So a lightweight, modern SPA wins in this case

It's not a hard problem, but I consider it to be a dumb problem.

Let's say I have absolutely zero business purpose for an API - like zero. Neither general purpose or single purpose. I now have to make one to serve a native/mobile app. I have to pick language, I have to design API surface, pick an RPC framework, REST or GraphQL, I have to adopt a different testing strategy for it, etc.

When all I really wanted to say was: "Hey server... can you serve a slightly different template connected to all the logic I've already written that a mobile app can understand as long as the app contains a component library?"

As for the opposite model where you are API first, at least you have the language, API contract / technology, testing strategy in place. And it will work regardless of what your clients are! The clients then implement their own UI, ideally on top of some shared, headless client (maybe a native module?) and you have maximized code re-use. Only the UI tech is different (and that's a maybe, since you could use flutter or RN), and is tailored to each device nicely.

So I do think the second is VERY desirable because it's single paradigm and you can go pretty far to reduce duplication of effort, almost entirely.

There is no such possibility in the server-driven paradigm, and I'd like to see it because it would give me all the re-usability benefits of the second approach, with a huge advantage of making the clients leaner.

It's a personal thing, but I personally don't want to smash my web-app backend into the same service as a general purpose API. It requires a lot of discipline to keep the concepts separate, and it fails more often than I've seen it work. I do appreciate your comment here of "better engineering" because I so very much wish for that. I wish that the average Django/Rails/Phoenix/whatever framework would not turn into a swampy piece of junk when you keep both responsibilities in the same codebase, but they often do.

The options we have are pretty decent - I just think something like LiveView could be better. Its only promise is a (admittedly slicker) take on SSR for the web. That doesn't move the needle far enough to be revolutionary to me, and doesn't solve a problem that most people have. The problem we have is that the server paradigm is way, way behind where it should be when it comes to serving different types of clients.