Skip to content
This repository has been archived by the owner on Sep 30, 2021. It is now read-only.

Latest commit

 

History

History
163 lines (111 loc) · 7.7 KB

README.md

File metadata and controls

163 lines (111 loc) · 7.7 KB
Raw

moonzoon.rs* | martin@moonzoon.rs | Discord

* redirects to this repo until ready

"We don't want to lose time and money due to millions of unnecessary technical micro-decisions."

MoonZoon is a Rust Fullstack Framework.

  • NO Javascript
  • NO CSS
  • NO HTML
  • NO REST
  • NO GraphQL
  • NO SQL
  • NO Analysis Paralysis
  • NO Wheel Reinventing
  • NO Passwords*
  • Rust
  • Fast
  • Simple
  • Scalable
  • SEO
  • Auth
  • MoonZoon CLI
  • Easy Deploy
  • Offline Support

* Authentication methods are described in Backend.md

Demo

Blog

Dev News

  1. CLI, Build pipeline, Live-reload, HTTPS [dev.to / MD]

  2. Live demo, Zoon, Examples, Architectures [dev.to / MD]

  3. Signals, React-like Hooks, Optimizations [dev.to / MD]

Documentation

1. Philosophy & Non-Goals.md

2. Frontend.md

3. Backend.md

4. CLI.md

5. Cloud.md

6. Development.md

Size & Speed

Benchmark example size

Benchmark example speed

FAQ

  1. "Is it production-ready?"

    • No, it's in the design & early development phase now, but you can subscribe to #news channel on our Discord server to don't miss the announcement.
    • MoonZoon will be battle-tested during the OpenHope and other projects development.

  2. "Why another framework? Are you mad??"

    • I want to write products. Reliable products. Quickly. I want to enjoy the development. I don't want to play endlessly with tools, protocols and config files.

  3. "Why Rust?"

    • It's the best language.

      Longer explanation

      I've written commercial or hobby projects in multiple languages (Js, CoffeeScript, TS, Elm, Elixir, PHP, C, C++, C#, Go, ..). However I want to write only in Rust.

      Rust is hard to learn even for experienced developers, because they have to unlearn many things and adapt thought process to Rust concepts and best practices. However once you stop fighting the compiler, Rust takes your hand and push you to correct and efficient solutions.

      I had similar feeling when I was learning to drive a car - it seems pretty hard/strange from the start but once you get used to it, you know that each control / button / pedal has it's specific place and purpose for a good reason. And it makes even more sense once you learn low-level stuff - e.g. how the transmission and a clutch work.

      However steep learning curve isn't bad:

      • It means that Rust doesn't hide real complexity behind too simple models.
      • It's almost impossible for complete beginners to publish incomplete/buggy libraries.

      _

      Rust is designed so well that I feel nervous while I'm writing in other languages - I have to do compiler's work again in my head and think about weird things like typos in code, nulls, undefineds, memory leaks, accidental mutations, how to write fast code without mutability, etc. It generates significant cognitive load so I can't focus so much on business logic and other important stuff.

      I don't believe that you should use the most suitable language for a specific domain or problem at all costs. I think consistency among your / company projects, productivity and simplicity should have the highest priority. And Rust is a very universal language so I think it's a good choice for almost all cases.

      There are also things that should be improved (and are improving):

      1. Compilation is still slow, but it's not so frustrating now.
      2. IDE support still isn't very good because of Rust complex types and macros but thanks to Rust Analyzer it's getting better every day.
      3. target folder (it's something like node_modules) can be pretty big.

  4. "The API looks weird!"

    • I would like to make it compilable on the stable Rust so I can't use some unstable features that would make the API a bit better.
    • Or I wasn't able to find a simpler and nicer API - please let me know why and how do you want to improve it.
    • Or we have just different experience and feel for graphic stuff.

  5. "Who is developing it?"

  6. "Could I help somehow? / Where can I find more information?"

    • Join our Discord chat and don't hesitate to ask any questions or present your ideas.
    • Create a pull-request if you want to fix typos, dead links, weird Czech-English sentences, etc.
    • If you think MoonZoon will be useful for your project, I want to know that! (Use chat or martin@moonzoon.rs).
    • Don't hesitate to tell your friends about MoonZoon and feel free to share the link (http://moonzoon.rs) on social platforms / forums / blogs / newsletters.

  7. "My only concern is the “no SQL” comment. Will it be possible to use MZ with something like SQLx if I prefer?" (by @duspom)

    • From the Philosophy & Non-Goals section: "E) Don't build artificial barriers for MoonZoon users - if they want to use REST, CSS or SQL, don't try to stop them."
    • You don't have to use built-in persistent variables in actors. Or you can use them and query the persistent store (e.g. Postgre) directly.

Thank you for reading! We are waiting for you on Discord.