5 ms·

What a nice surprise! No bloat, no fluff, just bare metal. I wish this project takes off. I remember how beneficial Sinatra was among the heavy Ruby frameworks

What a nice surprise! No bloat, no fluff, just bare metal. I wish this project takes off. I remember how beneficial Sinatra was among the heavy Ruby frameworks. We need something else than the React / Vue / Svelte triumvirate. Something much simpler. Something which brings back the joy and playfulness in web development.

anaganisk 6y ago
True but also we end re-inventing wheel as the project grows. After someone we will endup with react built on Dream. All frameworks were born for a reason right?
- AnthonBerg 6y ago
  I'm hoping, praying, and betting that powerful, sound, and elegant type systems will capture and integrate a lot of the boiling-plate frameworkery. Reinventing less and less of the wheel every cycle into oblivion.
  - FractalHQ 6y ago
    What’s wrong with Typescript...? Or even JSdoc. All this for what? Elegance and productivity? Svelte and typescript seem significantly faster to read and write than all the code I’ve seen from all this. And can even leverage the JS ecosystem. I feel like I’m missing the point of all this oCaml stuff, but I would like to understand the appeal.
    - antron-prime 6y ago
      AFAICT all of these are client-side frameworks. Dream is a server-side framework. I currently write my server with Dream and use regular JS React on the client. If you glance at most of Dream's examples that serve an interactive client, you will see that they serve JavaScript: https://github.com/aantron/dream/tree/master/example/k-websocket#k-websocket https://github.com/aantron/dream/tree/master/example/k-webso... You can use anything you want for the client, and I use the JS ecosystem heavily in my own usage. There are several full-stack OCaml examples, but that's entirely optional: https://github.com/aantron/dream/tree/master/example#full-stack https://github.com/aantron/dream/tree/master/example#full-st... As for server-side comparisons, OCaml is much easier for me to work with than, for example, TypeScript for many reasons. The first is that I can compile several hundred OCaml files, in the rare case of a full rebuild, in less time than running tsc incrementally on a small project, resulting in a much better iteration experience.
    - AnthonBerg 6y ago
      Typescript is indeed a step in this same direction!, as I see it. Underneath, Typescript has a goopier type system than OCaml. Formally speaking. Therefore Typescript ends up being less consistent and a less efficient tool for thought ... for me personally. That's the part underneath. On the surface we can use any syntax we care to. The Rescript language, formerly known as ReasonML, is a JavaScript-style syntax frontend for the OCaml compiler, plus a backend that compiles to quite readable and fast JavaScript: https://rescript-lang.org/ https://rescript-lang.org/ The end result is a very readable language that feels comfortable. We can quickly write robust programs in it. (There's more inherent robustness than in TypeScript!) It also interoperates very elegantly with the JS ecosystem and runs on JavaScript runtimes. OCaml code and ReScript language can be transpiled to each other, so depending on how Dream talks to the external world – i.e. what's the shape of the system call interface at the end of Dream's world? - then maybe Dream the OCaml web framework can be used as a JavaScript web framework and run on Node.js. Which is interesting and I want to understand now that I know to ask the question – thanks!
      - antron-prime 6y ago
        Dream doesn't have much of a system call dependency footprint itself. It's basically just a convention for plugging request -> response functions into a web server. Some of its native dependencies will have to be replaced by Node equivalents. Soon after that, it would be portable to Node. There is already work underway to port Dream to Mirage, to run in unikernels: https://github.com/aantron/dream/pull/22 https://github.com/aantron/dream/pull/22 Lwt, Dream's promise library, is itself getting ported to run on top of libuv: https://github.com/ocsigen/lwt/issues/813 https://github.com/ocsigen/lwt/issues/813 libuv is, of course, the I/O library that powers Node, so it might be practical to run Dream as a native node module very soon after doing this. (As an aside, I'm supposed to work on that libuv project, but instead I've been working on Dream :P)
        AnthonBerg 6y ago
        1 part thanks to 1 part kudos. Full glass. For you! This is pretty cool work you're doing!
runawaybottle 6y ago
The creator of React was inspired by ocaml and made Reason I believe. https://reasonml.github.io/reason-react/ https://reasonml.github.io/reason-react/ Maybe we should re-explore this guys ideas because he obviously was on to something. The above examples look elegant but I still need to see those real world hairy components to truly judge it.
- scns 6y ago
  React was originally written in StandardML.
- desert_boi 6y ago
  https://overreacted.io/algebraic-effects-for-the-rest-of-us/ https://overreacted.io/algebraic-effects-for-the-rest-of-us/ shows how OCaml's influence is part of hooks too.

anaganisk 6y ago

True but also we end re-inventing wheel as the project grows. After someone we will endup with react built on Dream. All frameworks were born for a reason right?

AnthonBerg 6y ago
I'm hoping, praying, and betting that powerful, sound, and elegant type systems will capture and integrate a lot of the boiling-plate frameworkery. Reinventing less and less of the wheel every cycle into oblivion.
- FractalHQ 6y ago
  What’s wrong with Typescript...? Or even JSdoc. All this for what? Elegance and productivity? Svelte and typescript seem significantly faster to read and write than all the code I’ve seen from all this. And can even leverage the JS ecosystem. I feel like I’m missing the point of all this oCaml stuff, but I would like to understand the appeal.
  - antron-prime 6y ago
    AFAICT all of these are client-side frameworks. Dream is a server-side framework. I currently write my server with Dream and use regular JS React on the client. If you glance at most of Dream's examples that serve an interactive client, you will see that they serve JavaScript: https://github.com/aantron/dream/tree/master/example/k-websocket#k-websocket https://github.com/aantron/dream/tree/master/example/k-webso... You can use anything you want for the client, and I use the JS ecosystem heavily in my own usage. There are several full-stack OCaml examples, but that's entirely optional: https://github.com/aantron/dream/tree/master/example#full-stack https://github.com/aantron/dream/tree/master/example#full-st... As for server-side comparisons, OCaml is much easier for me to work with than, for example, TypeScript for many reasons. The first is that I can compile several hundred OCaml files, in the rare case of a full rebuild, in less time than running tsc incrementally on a small project, resulting in a much better iteration experience.
  - AnthonBerg 6y ago
    Typescript is indeed a step in this same direction!, as I see it. Underneath, Typescript has a goopier type system than OCaml. Formally speaking. Therefore Typescript ends up being less consistent and a less efficient tool for thought ... for me personally. That's the part underneath. On the surface we can use any syntax we care to. The Rescript language, formerly known as ReasonML, is a JavaScript-style syntax frontend for the OCaml compiler, plus a backend that compiles to quite readable and fast JavaScript: https://rescript-lang.org/ https://rescript-lang.org/ The end result is a very readable language that feels comfortable. We can quickly write robust programs in it. (There's more inherent robustness than in TypeScript!) It also interoperates very elegantly with the JS ecosystem and runs on JavaScript runtimes. OCaml code and ReScript language can be transpiled to each other, so depending on how Dream talks to the external world – i.e. what's the shape of the system call interface at the end of Dream's world? - then maybe Dream the OCaml web framework can be used as a JavaScript web framework and run on Node.js. Which is interesting and I want to understand now that I know to ask the question – thanks!
    - antron-prime 6y ago
      Dream doesn't have much of a system call dependency footprint itself. It's basically just a convention for plugging request -> response functions into a web server. Some of its native dependencies will have to be replaced by Node equivalents. Soon after that, it would be portable to Node. There is already work underway to port Dream to Mirage, to run in unikernels: https://github.com/aantron/dream/pull/22 https://github.com/aantron/dream/pull/22 Lwt, Dream's promise library, is itself getting ported to run on top of libuv: https://github.com/ocsigen/lwt/issues/813 https://github.com/ocsigen/lwt/issues/813 libuv is, of course, the I/O library that powers Node, so it might be practical to run Dream as a native node module very soon after doing this. (As an aside, I'm supposed to work on that libuv project, but instead I've been working on Dream :P)
      - AnthonBerg 6y ago
        1 part thanks to 1 part kudos. Full glass. For you! This is pretty cool work you're doing!

runawaybottle 6y ago

The creator of React was inspired by ocaml and made Reason I believe. https://reasonml.github.io/reason-react/ https://reasonml.github.io/reason-react/ Maybe we should re-explore this guys ideas because he obviously was on to something. The above examples look elegant but I still need to see those real world hairy components to truly judge it.

scns 6y ago
React was originally written in StandardML.
desert_boi 6y ago
https://overreacted.io/algebraic-effects-for-the-rest-of-us/ https://overreacted.io/algebraic-effects-for-the-rest-of-us/ shows how OCaml's influence is part of hooks too.