I've seen this project pop up two or three times in the last few days. I'm really excited about this and wasm in general and spent last night working through the docs page (https://wasmcloud.com/docs/intro/).

I set up hello world in TS, Rust and Go and went through the happy path of saying hello world. That was a really nice and encouraging dopamine hit.

My biggest critique is once you need to go any further and turn hello world into even something pretty small but useful, the wheels fall off fast. Almost immediately after the "ooooh cool" of creating a hello world container with `wash dev` and seeing it on port 8000, which was my favorite part, things started to get weird.

After the tutorial introduces `wash dev`, a sort of create-react-app for wasm that bootstraps the project, generates a ton of boilerplate and generates a hot-reloading server, the tutorials immediately introduces `wash up` and `wash ui`. I figured out `wash ui` is an admin dashboard of sorts. Why can't I just have admin dashboard as an option in my hosting command like `wash dev --dashboard=true`? It never really explains why I want `wash up` vs `wash dev`, where they differ, why they differ and why each exists. The `wash up` experience is much more clunky and, to be honest, I'd really just want to keep going with the same command that was working for me like `wash dev --dev` and then `wash dev --prod` with a heavy emphasis in the tutorial on the difference for each as it's really not clear.

Confusion aside, the project seems very optimized for everything up to `wash dev` and then gets weird after that. I originally tried to create three components: hello-go, hello-rust and hello-ts. I used `wash new component hello-{lang} --template-name hello-world-{language}` and it created a sub-directory for each component. Each sub-directory looks like it's own self-contained universe and it is not _at all_ clear how to get each component invoking other components (which is heavily emphasized as one of the killer apps throughout the introduction page). Furthermore, the `wash dev` command seems to only work within a single component. It is not clear how, if at all, I can run `wash dev` in the main directory and rebuild each component in its sub-directory (how I would like this to work). Also, it seems like each component's `.wadl` defines the component behavior (the url via spec.components[http-component]) but I don't want to think about each individual component, I really want to have one infra definition in root that defines the behavior of every component (particularly the spreadscaler and http address).

There are no examples for anything beyond super-trivial /get of hello world. Could you show a post? Can I run multiple components on different routes? What about different components on different ports? If the intent is to run a "super lambda" that handles all traffic and routes internally, at least show that as an example.

Finally after a lot of digging, I found a link to a multi-component example (https://github.com/wasmCloud/wasmCloud/tree/main/examples/ru...) which introduces a half dozen new tools and commands not discussed anywhere in the tutorials and introduces a ton a clunky steps. In my head, I was thinking about all the steps in a Github Action runner I would need to make this seamless and just thought...this ain't it.

Also, about half way through the docs make a throwaway reference to hosting with Wasmtime and JCo....wat? I thought the point of the wash tool was to take me from dev on localhost to hosting in production. Is it not? If not, make that _very clear_ in the docs.

To be clear: I _REALLY_ want WasmCloud to be successful. A lightning fast (virtually cold-start free) self-hostable, serverless function platform is my dream. I would love nothing more than a platform where I and/or a small team could write functions in Go/Rust/JS/TS/Python, bundle and deploy them to a serverless platform we host. It's even better that this platform out of the box provides support for metrics, monitoring, logging and tracing. The first article I read about you a few days ago I jumped out of my chair in joy that my dream was finally coming true. While I didn't dig into it too much, it seems the platform also provides idioms for distributed systems (some mechanism to distribute load across self-organizing hosts on different machines). The reality is more rough and after using it, it's not clear if I misunderstood what this project is and was confusing it for something else or if it just needs more polish and DX focus.

I am rooting for you so much and wanted to give this feedback as I can't think of anything better than a self-hosted cold-start-less distributed serverless function platform but the rough edges would mean either I incur a ton of CI automation to smooth the rough edges, or I just keep watching this project before adopting.