7 ms·

Dream – Tidy Web Framework for OCaml and ReasonML

136 points by yawaramin 6y ago

swuecho 6y ago
finally, some ocaml project has good document!
asplake 6y ago
That page doesn’t link to the examples in GitHub whose README [1] is unexpectedly informative, having its own roadmap. Anyone using this in anger? [1] https://github.com/aantron/dream/tree/master/example#readme https://github.com/aantron/dream/tree/master/example#readme
- antron-prime 6y ago
  Probably nobody using this in the community yet, as the project is not yet released (or deliberately announced). I have some code built against an earlier version of it, but there have been so many changes during development, that the web app that spawned Dream needs to be adapted :)
  - asplake 6y ago
    I’ve been looking for something like this to tempt me away from Flask and get me using an ML-derived language. Best of luck with it!
d3nj4l 6y ago
Really exciting to watch the developments in OCaml/Reason web frameworks/libraries. I love the language and wish I could use it instead of Ruby for my personal projects at least. Others that have caught my interest are: Sihl: https://github.com/oxidizing/sihl https://github.com/oxidizing/sihl ReWeb: https://github.com/yawaramin/re-web/ https://github.com/yawaramin/re-web/ Of course, if you're interested in OCaml/Reason and don't know about Revery you're missing out.
- antron-prime 6y ago
  As follow-on work to Dream, I'd like to take a very hard look at how we do JSON server-side, to really make it much easier. Although this is partially solved by using GraphQL more :) Ideally, in the end, we will have a very fluent server programming experience. Same goes for SQL prepared statements. I'd like to decrease the amount of boilerplate somewhat, hopefully without resorting to preprocessing. This is part of the reason I didn't add too many helpers for either JSON or SQL to Dream yet - there seems to be considerable room for improvement here.
- csbartus 6y ago
  See also Opium (vs. Dream): https://discuss.ocaml.org/t/excited-about-dream-web-framework/7605/6 https://discuss.ocaml.org/t/excited-about-dream-web-framewor...
  - antron-prime 6y ago
    You may have meant this post: https://discuss.ocaml.org/t/excited-about-dream-web-framework/7605/21 https://discuss.ocaml.org/t/excited-about-dream-web-framewor... or another in that thread, as the specific one linked doesn't compare Dream with Opium! Opium itself is found here: https://github.com/rgrinberg/opium https://github.com/rgrinberg/opium
csbartus 6y ago
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.
cassepipe 6y ago
As an aside I just discovered that Reason (alternative syntax for Ocaml) had been forked by the Bucklescript (Ocaml/Reason to JS compiler) team. The fork is called Rescript and is aims at being a new language and to part with Ocaml. Rescript is also the new name of Bucklescript (compiler) btw. If you don't get any of this, I don't blame you. Here's a thorough explanation of this mess : https://ersin-akinci.medium.com/confused-about-rescript-rescript-reason-reasonml-and-bucklescript-explained-ab4230555230 https://ersin-akinci.medium.com/confused-about-rescript-resc... The confusing part is that some people decided to name a whole ecosystem project with a name that reads like it's a language (ReasonML) and some other had the wonderful idea to name a compiler that also reads like it's a language (Bucklescript) but to make it more simple they changed the name to... Rescript, but wait now it's also the name of the language. Oh and also Reason calls itself a programming language (when it's just an alternate syntax). Brilliant.
- antron-prime 6y ago
  ...and just to make it slightly more confusing, ReScript changed the ReasonML language somewhat, prompting another fork, Melange, which sticks with ReasonML. In any case, Dream has examples showing full-stack (OCaml client+server) usage with both ReScript and Melange: - ReScript: https://github.com/aantron/dream/tree/master/example/w-fullstack-rescript#files https://github.com/aantron/dream/tree/master/example/w-fulls... - Melange: https://github.com/aantron/dream/tree/master/example/r-fullstack-melange#files https://github.com/aantron/dream/tree/master/example/r-fulls... For good measure, there is also an example with the other OCaml-to-JS compiler... - Js_of_ocaml: https://github.com/aantron/dream/tree/master/example/w-fullstack-jsoo#files https://github.com/aantron/dream/tree/master/example/w-fulls...
  - cassepipe 6y ago
    Oh I did not know about Melange, thanks I am so glad somebody made the effort of porting supporting latest reason syntax !
  - nerdponx 6y ago
    Anecdote: I was all ready to start learning Reason/Rescript, and then I saw the confusing stew of renames and forks. I changed my mind, and I don't plan on touching it until something settles out. As an outsider with respect to the community, I can't think of a bigger impediment to adoption than a scenario like this. Apart from something catastrophic like a BDFL ghosting or going closed source.
JediPig 6y ago
Unpopular opinion, I seen the results of the frameworks from reasonml. The eco system, no company will want to take the risk of using. Before saying "onivim" is using it, its fast. I have the nightly of onivim2 and st4. Sublime beats the crap out of it, and onivim2 is starting to show slowness in the UI. VSCode is faster than onivm2, yet it suppose to use reasonml. My advice, never bet your future and company on this fragmented framework.
teyc 6y ago
The documentation is stellar and it makes Dream looks accessible even for a non-ML'er like myself. I also liked how you introduced HTML through preprocessing. I wish F# would take a similar approach. Nothing seems to come close. OCaml on Windows seem to only run under Msys or cygwin. Do most OCaml devs develop on Linux?
- yawaramin 6y ago
  OCaml actually runs natively on Windows, it's just that for development some Unix-like environment is needed, because many packages have a habit of accidentally pulling in and using convenient Unix-isms like bash and grep. Nowadays WSL is used by many, and it works great. But the toolchain can produce applications that run on Windows without any special support, and people have been shipping OCaml apps on Windows for a long time. E.g. the Unison file sync utility, the MLDonkey file share program.
- antron-prime 6y ago
  I do everything under WSL on Windows. So, still effectively Linux :) As for Cygwin, that was my choice for a long time when I started with OCaml. For building fully-native Windows apps, I've used https://fdopen.github.io/opam-repository-mingw/installation/ https://fdopen.github.io/opam-repository-mingw/installation/. However, it still requires a Cygwin environment to run in, because, as yawaramin mentioned, much of the OCaml ecosystem assumes Linux-like tools during build. So, effectively, the Windows setup looks a bit like cross-compilation, where your build environment is Cygwin, but the output is non-Cygwin full-native Windows binaries. The compiler itself and core tools like Dune don't assume Linux tools and are portable. It's many of the packages among the rest of what is there that trigger the Linux tools dependency.

136 points by yawaramin 6y ago

finally, some ocaml project has good document!

That page doesn’t link to the examples in GitHub whose README [1] is unexpectedly informative, having its own roadmap. Anyone using this in anger? [1] https://github.com/aantron/dream/tree/master/example#readme https://github.com/aantron/dream/tree/master/example#readme

antron-prime 6y ago
Probably nobody using this in the community yet, as the project is not yet released (or deliberately announced). I have some code built against an earlier version of it, but there have been so many changes during development, that the web app that spawned Dream needs to be adapted :)
- asplake 6y ago
  I’ve been looking for something like this to tempt me away from Flask and get me using an ML-derived language. Best of luck with it!

d3nj4l 6y ago

Really exciting to watch the developments in OCaml/Reason web frameworks/libraries. I love the language and wish I could use it instead of Ruby for my personal projects at least. Others that have caught my interest are: Sihl: https://github.com/oxidizing/sihl https://github.com/oxidizing/sihl ReWeb: https://github.com/yawaramin/re-web/ https://github.com/yawaramin/re-web/ Of course, if you're interested in OCaml/Reason and don't know about Revery you're missing out.

antron-prime 6y ago
As follow-on work to Dream, I'd like to take a very hard look at how we do JSON server-side, to really make it much easier. Although this is partially solved by using GraphQL more :) Ideally, in the end, we will have a very fluent server programming experience. Same goes for SQL prepared statements. I'd like to decrease the amount of boilerplate somewhat, hopefully without resorting to preprocessing. This is part of the reason I didn't add too many helpers for either JSON or SQL to Dream yet - there seems to be considerable room for improvement here.
csbartus 6y ago
See also Opium (vs. Dream): https://discuss.ocaml.org/t/excited-about-dream-web-framework/7605/6 https://discuss.ocaml.org/t/excited-about-dream-web-framewor...
- antron-prime 6y ago
  You may have meant this post: https://discuss.ocaml.org/t/excited-about-dream-web-framework/7605/21 https://discuss.ocaml.org/t/excited-about-dream-web-framewor... or another in that thread, as the specific one linked doesn't compare Dream with Opium! Opium itself is found here: https://github.com/rgrinberg/opium https://github.com/rgrinberg/opium

csbartus 6y ago

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.

cassepipe 6y ago

As an aside I just discovered that Reason (alternative syntax for Ocaml) had been forked by the Bucklescript (Ocaml/Reason to JS compiler) team. The fork is called Rescript and is aims at being a new language and to part with Ocaml. Rescript is also the new name of Bucklescript (compiler) btw. If you don't get any of this, I don't blame you. Here's a thorough explanation of this mess : https://ersin-akinci.medium.com/confused-about-rescript-rescript-reason-reasonml-and-bucklescript-explained-ab4230555230 https://ersin-akinci.medium.com/confused-about-rescript-resc... The confusing part is that some people decided to name a whole ecosystem project with a name that reads like it's a language (ReasonML) and some other had the wonderful idea to name a compiler that also reads like it's a language (Bucklescript) but to make it more simple they changed the name to... Rescript, but wait now it's also the name of the language. Oh and also Reason calls itself a programming language (when it's just an alternate syntax). Brilliant.

antron-prime 6y ago
...and just to make it slightly more confusing, ReScript changed the ReasonML language somewhat, prompting another fork, Melange, which sticks with ReasonML. In any case, Dream has examples showing full-stack (OCaml client+server) usage with both ReScript and Melange: - ReScript: https://github.com/aantron/dream/tree/master/example/w-fullstack-rescript#files https://github.com/aantron/dream/tree/master/example/w-fulls... - Melange: https://github.com/aantron/dream/tree/master/example/r-fullstack-melange#files https://github.com/aantron/dream/tree/master/example/r-fulls... For good measure, there is also an example with the other OCaml-to-JS compiler... - Js_of_ocaml: https://github.com/aantron/dream/tree/master/example/w-fullstack-jsoo#files https://github.com/aantron/dream/tree/master/example/w-fulls...
- cassepipe 6y ago
  Oh I did not know about Melange, thanks I am so glad somebody made the effort of porting supporting latest reason syntax !
- nerdponx 6y ago
  Anecdote: I was all ready to start learning Reason/Rescript, and then I saw the confusing stew of renames and forks. I changed my mind, and I don't plan on touching it until something settles out. As an outsider with respect to the community, I can't think of a bigger impediment to adoption than a scenario like this. Apart from something catastrophic like a BDFL ghosting or going closed source.

JediPig 6y ago

Unpopular opinion, I seen the results of the frameworks from reasonml. The eco system, no company will want to take the risk of using. Before saying "onivim" is using it, its fast. I have the nightly of onivim2 and st4. Sublime beats the crap out of it, and onivim2 is starting to show slowness in the UI. VSCode is faster than onivm2, yet it suppose to use reasonml. My advice, never bet your future and company on this fragmented framework.

teyc 6y ago

The documentation is stellar and it makes Dream looks accessible even for a non-ML'er like myself. I also liked how you introduced HTML through preprocessing. I wish F# would take a similar approach. Nothing seems to come close. OCaml on Windows seem to only run under Msys or cygwin. Do most OCaml devs develop on Linux?

yawaramin 6y ago
OCaml actually runs natively on Windows, it's just that for development some Unix-like environment is needed, because many packages have a habit of accidentally pulling in and using convenient Unix-isms like bash and grep. Nowadays WSL is used by many, and it works great. But the toolchain can produce applications that run on Windows without any special support, and people have been shipping OCaml apps on Windows for a long time. E.g. the Unison file sync utility, the MLDonkey file share program.
antron-prime 6y ago
I do everything under WSL on Windows. So, still effectively Linux :) As for Cygwin, that was my choice for a long time when I started with OCaml. For building fully-native Windows apps, I've used https://fdopen.github.io/opam-repository-mingw/installation/ https://fdopen.github.io/opam-repository-mingw/installation/. However, it still requires a Cygwin environment to run in, because, as yawaramin mentioned, much of the OCaml ecosystem assumes Linux-like tools during build. So, effectively, the Windows setup looks a bit like cross-compilation, where your build environment is Cygwin, but the output is non-Cygwin full-native Windows binaries. The compiler itself and core tools like Dune don't assume Linux tools and are portable. It's many of the packages among the rest of what is there that trigger the Linux tools dependency.