I can see this was largely AI written. There is nothing wrong with that, but how much did you test and vet what the AI wrote?
Looking at the compiler, it doesn't make much sense. You have an AST that is rather minimal and I can't seem to find an IR. There are files, such as cron.rs, which have very little code relating to what I would expect, and the tests seem to test very little that is worthwhile.
The codebase seems tightly coupled and to cover specific cases, as if something was off and more features were requested. I think a 12k line file is evidence of that.
Perhaps it is a useful tool for you but I would have trouble using something like this with just my quick skim because it seems a mile wide and an inch deep.
Also, because of the sheer size of it, it would be extremely difficult to have an agent properly comprehend much if anything. Which I would want in order to audit the internals.
That is a lot of tokens. The problem here is that you have a compiler; why are you encoding standards as a prompt instead of as compiler errors?
You can use linting and static analysis to force conformance with agents instead of suggesting with a prompt.
I wish you luck with the project. I'll have to pass, too much code for me to follow when I could simply have an agent directly write the html now days.
It's an interesting idea, but it's hard to tell what the native parts are. The home page has a section titled "Native Targets" with an arrow icon that looks like it'd go to some docs, but appears to just be an icon. The running example is a straightforward responsive web page. The docs are centered around UI components for this tool and the lack of a Tree component really makes it look like this is a web framework.
Does it actually generate a native mobile or desktop application? I probably overlooked it, but I couldn't find an example app to build and experiment with locally.
Very frankly, I’m assuming that you typed something sloppy into AI and asked it to make a big project and a big web page for it, and now you have little or no idea what it did, except that it strung programming concepts together.
I understand why the current website might give that impression, but Dowe was not produced from a single prompt.
Before arriving at this architecture, we experimented with several languages and rendering approaches, including using WebViews for mobile. We ultimately rejected that approach. Dowe now maps its UI components individually to Jetpack Compose on Android and SwiftUI on iOS. The generated mobile applications are native and their source can be inspected.
Desktop is currently different: it packages the generated web/static output inside a native platform window. I don’t want to misrepresent that distinction.
The component model grew out of what we learned while building UiSvelte https://ui-svelte.sappsdev.com, our earlier Svelte UI library with around 80 components. Dowe does not depend on Svelte; that work provided much of the design experience behind its component contracts.
I invite you to evaluate the implementation directly. After installing Dowe, creating and running a project is simply:
dowe init
dowe dev
You can inspect the generated Jetpack Compose and SwiftUI projects under .dowe/apps/android and .dowe/apps/ios. Feedback based on the actual output would be genuinely valuable.
I love this idea. I was working on a JavaScript dialect to make programming more approachable after watching non technical colleagues vibe coding. It was clear that learning programming concepts would make a world of difference
> Dowe is a Rust compiler and runtime toolchain for building fullstack products from a unified, declarative source graph. Applications are authored in Dowe Source Format (.dowe), checked against explicit language and platform contracts, and lowered into the artifacts required by each selected target.
How do people publish these websites that are full of Claude-isms and slop-writing and feel proud of themselves? A single cursory read of this page with fresh eyes would tell you that the page manages to communicate zero useful information, while also being written in a way that brings a bad taste to your mouth if you can recognize AI writing. Who is this for? Why would anybody want to try a project that has such little care and attention put into it?
And lest I be misinterpreted, this is not saying that you need to learn how to do frontend in order to create a programming language. Feel free to use AI to make your website, I don't mind at all. But ultimately the words on the page are for human consumption, and if I can tell that no brain cells were put into considering them, I'm not going to be interested in consuming them. Practical advice: once you've used AI to create your website, treat all of the copy on the page as filler equivalent to 'lorem ipsum' and rewrite it all in your own words. It will go a long way towards engendering trust in your project.
I can see this was largely AI written. There is nothing wrong with that, but how much did you test and vet what the AI wrote?
Looking at the compiler, it doesn't make much sense. You have an AST that is rather minimal and I can't seem to find an IR. There are files, such as cron.rs, which have very little code relating to what I would expect, and the tests seem to test very little that is worthwhile.
Some of these are absolute monsters, like this one: https://github.com/usedowe/dowe-lang/blob/main/crates/compil...
The codebase seems tightly coupled and to cover specific cases, as if something was off and more features were requested. I think a 12k line file is evidence of that.
Perhaps it is a useful tool for you but I would have trouble using something like this with just my quick skim because it seems a mile wide and an inch deep.
Also, because of the sheer size of it, it would be extremely difficult to have an agent properly comprehend much if anything. Which I would want in order to audit the internals.
The language itself seems minimal, but then I look at the skills, like this one for example: https://github.com/usedowe/dowe-lang/blob/main/skill-data/do...
That is a lot of tokens. The problem here is that you have a compiler; why are you encoding standards as a prompt instead of as compiler errors?
You can use linting and static analysis to force conformance with agents instead of suggesting with a prompt.
I wish you luck with the project. I'll have to pass, too much code for me to follow when I could simply have an agent directly write the html now days.
It's an interesting idea, but it's hard to tell what the native parts are. The home page has a section titled "Native Targets" with an arrow icon that looks like it'd go to some docs, but appears to just be an icon. The running example is a straightforward responsive web page. The docs are centered around UI components for this tool and the lack of a Tree component really makes it look like this is a web framework.
Does it actually generate a native mobile or desktop application? I probably overlooked it, but I couldn't find an example app to build and experiment with locally.
Dowe generate a native mobile or desktop application no webview
Thanks for answering. Is there an example project you can share? I'd love to see this in action.
Of course — the Dowe docs are built with Dowe itself: https://github.com/usedowe/dowe-docs
Very frankly, I’m assuming that you typed something sloppy into AI and asked it to make a big project and a big web page for it, and now you have little or no idea what it did, except that it strung programming concepts together.
I understand why the current website might give that impression, but Dowe was not produced from a single prompt. Before arriving at this architecture, we experimented with several languages and rendering approaches, including using WebViews for mobile. We ultimately rejected that approach. Dowe now maps its UI components individually to Jetpack Compose on Android and SwiftUI on iOS. The generated mobile applications are native and their source can be inspected. Desktop is currently different: it packages the generated web/static output inside a native platform window. I don’t want to misrepresent that distinction. The component model grew out of what we learned while building UiSvelte https://ui-svelte.sappsdev.com, our earlier Svelte UI library with around 80 components. Dowe does not depend on Svelte; that work provided much of the design experience behind its component contracts. I invite you to evaluate the implementation directly. After installing Dowe, creating and running a project is simply: dowe init dowe dev You can inspect the generated Jetpack Compose and SwiftUI projects under .dowe/apps/android and .dowe/apps/ios. Feedback based on the actual output would be genuinely valuable.
Certainly looks that way to me.
So. It’s a high fidelity prototype. Evaluate the concept. The implementation can be improved.
If you can’t even make the web page yourself, what am I supposed to conclude about your web language?
I love this idea. I was working on a JavaScript dialect to make programming more approachable after watching non technical colleagues vibe coding. It was clear that learning programming concepts would make a world of difference
From the Github README:
> Dowe is a Rust compiler and runtime toolchain for building fullstack products from a unified, declarative source graph. Applications are authored in Dowe Source Format (.dowe), checked against explicit language and platform contracts, and lowered into the artifacts required by each selected target.
I can't be bothered to read a website that is so clearly AI generated with little to no polishing. What does that say about the rest of the project?
How do people publish these websites that are full of Claude-isms and slop-writing and feel proud of themselves? A single cursory read of this page with fresh eyes would tell you that the page manages to communicate zero useful information, while also being written in a way that brings a bad taste to your mouth if you can recognize AI writing. Who is this for? Why would anybody want to try a project that has such little care and attention put into it?
And lest I be misinterpreted, this is not saying that you need to learn how to do frontend in order to create a programming language. Feel free to use AI to make your website, I don't mind at all. But ultimately the words on the page are for human consumption, and if I can tell that no brain cells were put into considering them, I'm not going to be interested in consuming them. Practical advice: once you've used AI to create your website, treat all of the copy on the page as filler equivalent to 'lorem ipsum' and rewrite it all in your own words. It will go a long way towards engendering trust in your project.
This is a lot... is the web rendering just this framework in itself? Like this is a custom/new SSR solution?
Web render SSR, and native app on ios, android, no webview
So the way this works is that we chose pre-defined Layouts and components right
> ONE SOURCE. EVERY SURFACE. PURPOSEFULLY UNIFIED.
slop alert
How does AI slop like this constantly make it to the front page?
dowe is a fullstack framework, server, web, desktop, ios, android one code base
forgot to add slop.
Dowe — A full-stack language for server, web, desktop, Android, iOS, *and Slop.*