5 ms·

Deploying a ReasonML React app with Docker

137 points by anirudhmurali 9y ago

tuananh 9y ago
since we use bs to compile, shouldn't we use a node image to compile and then copy them over to runtime image later?
- alberteinstein 9y ago
  True, optimising with a multi-stage build after `yarn build` should do it.
anirudhmurali 9y ago
Hi HN, here's the Dockerfile: https://gist.github.com/anirudhmurali/fee0181957bd9bcc9d5846a1045923aa https://gist.github.com/anirudhmurali/fee0181957bd9bcc9d5846...
- vog 9y ago
  Thanks for the link, but why isn't it part of the article?
  - anirudhmurali 9y ago
    It is, but as in image form. I'll link this there.
azr79 9y ago
What can ReasonML do that TypeScript can't?
- tango12 9y ago
  Prevent null bugs. Typescript values can be null. A pure reason program will never have null bugs. https://reasonml.github.io/docs/en/type.html https://reasonml.github.io/docs/en/type.html
  - billwashere 9y ago
    In case anyone didn't know, since Typescript 2 there is a compiler option to enable strict null checking. https://blog.mariusschulz.com/2016/09/27/typescript-2-0-non-nullable-types https://blog.mariusschulz.com/2016/09/27/typescript-2-0-non-...
    - realharo 9y ago
      Only since 2.7 (very recently) can you actually enforce initialization of class properties: https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-7.html#strict-class-initialization https://www.typescriptlang.org/docs/handbook/release-notes/t...
      - Rapzid 9y ago
        I was just wondering about this today; thx for the link! Not sure how I missed it.
        realharo 9y ago
        Unfortunately, libraries such as React have their own component lifecycle management, which doesn't play well with this (https://reactjs.org/blog/2015/12/18/react-components-elements-and-instances.html https://reactjs.org/blog/2015/12/18/react-components-element...). This is also a bit of a pain point on Android with Java @NonNull annotations or when using Kotlin.
        Rapzid 9y ago
        Yeah... It would honestly be cool to have a TypeScript native React(as crazy as that sounds). There are some really great projects out there killing it like Nest, MobX, TypeORM, etc.. The React typings have come a long way though. I do quite a bit of TypeScript for the server though(less context switching and is mostly GoodEnough™) so still handy.
        9y ago
- napa15 9y ago
  compile quickly
- fleetfox 9y ago
  If you look at language itself many things. It's different paradigm.
- TuringTest 9y ago
  Pattern matching with a sane syntax. https://reasonml.github.io/docs/en/pattern-matching.html https://reasonml.github.io/docs/en/pattern-matching.html
- andreypopp 9y ago
  Full type inference, pattern matching with exhaustivity checker, modules, abstract types, ... But to be honest, it's not very useful to do checklist-style comparisons — writing OCaml/Reason code is a completely different experience. For me it results in less worry about how my code would sustain under refactorings — this is one of the reasons I feel more productive with it rather than with TypeScript or Flow or (of course!) plain JS. I can start writing code and don't worry about getting everything right upfront — refactorings are cheap.
- jordwalke 9y ago
  Hi, I work on Reason: To add to other comments: One thing that ReasonML can do that TypeScript cannot do, is take advantage of the world-class OCaml compiler to generate very fast native executables. If you learn Reason, then you are also a "native developer" in a sense.
- bobbby 9y ago
  TypeScript has to handle every JavaScript quirk, it puts structure in place to help mitigate many issues. ReasonML breaks from full compatibility, it can pick and choose JavaScript features to compromise between familiarity and functionality. At the other extreme you have Elm, which has a similar background but won't compromise so can offer a clean break from JavaScript.
  - cies 9y ago
    > ReasonML breaks from full compatibility It promises zero compatibility code wise, but very easy interop (FFI) with JS land!
- gladimdim 9y ago
  I have replied to this question on SO [1], here is quote: In a large application you will need a lot of features, which are provided by default in ReasonML: strict types, runtime validation if you encode/decode JSON, fast compilation time, immutable data. In TypeScript you will have to add: 1. ImmutableJS + its typings. 2. Runtime validators like json-schema + its typings. Then you will have to write types in TypeScript, and also defined a schema in json-schemas. They can become out of sync very soon. 3. Some crazy hacks to tell the difference if variable is of specific type (like in official docs of TS: https://www.typescriptlang.org/docs/handbook/advanced-types.html https://www.typescriptlang.org/docs/handbook/advanced-types...., Paragraph "User-Defined Type Guards"). This checks are done using side effects like a.swim !== undefined. In 6 months this 'if' statement will contain more and more checks. 4. You are lucky if a package you use has official and maintained type definitions. Or you will end up with custom typings. 5. If you develop hybrid app in JS + TS, then TS Compiler cannot create a bundled final d.ts file which you can import in other parts of your project. You will have to write separate d.ts files, which are bundled by tools like dts-bundle. If you have everything in TS, then this issue is not applicable. 6. Large apps take a lot of time to be compiled by TypeScript. With ReasonML: 1. Immutable data is in the language. 2. Runtime validators are present (bs-json has them by default). 3. Pattern matching saves you from these crazy checks. 4. You are lucky if npm package you want to use has BuckleScript bindings. 5. N/A. 6. ReasonML compilation is very fast. 1: https://stackoverflow.com/questions/46147250/reasonml-vs-typescript/47944310#47944310 https://stackoverflow.com/questions/46147250/reasonml-vs-typ...
- dsiegel2275 9y ago
  In my opinion one of the most useful features is first-class support for algebraic data types. Using records and variants ('sum' and 'product' types) in Reason one can be much more expressive in terms of how program state and other constraints are defined. One can get some of the same benefits of sum types in TypeScript using discriminated unions - but the syntax is cumbersome and requires boilerplate as compared to Reason.
Kwastie 9y ago
With pure Reason (No JS bindings) it should be possible to skip Node / Bucklescript on the server and compile straight to binary. This should be possible with something like bsb-native (https://github.com/bsansouci/bsb-native https://github.com/bsansouci/bsb-native) I haven't tried this because I don't have a pure Reason project
- Drup 9y ago
  > This should be possible with something like bsb-native (https://github.com/bsansouci/bsb-native https://github.com/bsansouci/bsb-native) Why not just use the real OCaml/Reason compiler ... ?
  - jordwalke 9y ago
    Reason is supported on every major version of the native OCaml compiler (currently versions 4.02.3 up to 4.06).
    - Drup 9y ago
      I know, hence my question! Why go through bs (which is locked to an old version of OCaml) to distribute executables, when you can use the normal compiler and enjoy the latest improvements?
      - jordwalke 9y ago
        I don’t mean to ignore your observation - it is valid. Bsb is a build system that works with a specific form of packages. What you suggest could work too. The only (small?) challenge is that people have bsb JS projects, and they aren’t configured for jbuilder/Dune etc. Because of JavaScript’s immense popularity, the largest number of people will start with whatever build tools integrate well with the JavaScript ecosystem and work from there. This plays out quite predictably. Just as an example, the most important thing to web developers is that each Reason input file becomes a commonJS (or es6) module. That allows integrating your Reason React app with existing web apps easily. So since people start with whatever tools integrate well with the JS ecosystem, they then reach for the easiest tool available to adopt native compilation.
jmcomets 9y ago
Unrelated, but does anyone know what font/colorscheme are used in the screenshots? I find it very slick for code presentation.
- anirudhmurali 9y ago
  Haha, it's here: https://carbon.now.sh/ https://carbon.now.sh/
theptip 9y ago
One annoying thing you'll need to add before this is production-ready is configurable environment config, so that you can deploy the same container for your staging vs. production version of the app. I use a `patch.sh` as the ENTRYPOINT, which says something like echo $API_URL >> /usr/local/nginx/html/config.js echo $OTHER_CONFIG > /usr/local/nginx/html/config.js ... exec nginx Though there may be other ways to achieve this as well.

137 points by anirudhmurali 9y ago

tuananh 9y ago

since we use bs to compile, shouldn't we use a node image to compile and then copy them over to runtime image later?

alberteinstein 9y ago
True, optimising with a multi-stage build after `yarn build` should do it.

anirudhmurali 9y ago

Hi HN, here's the Dockerfile: https://gist.github.com/anirudhmurali/fee0181957bd9bcc9d5846a1045923aa https://gist.github.com/anirudhmurali/fee0181957bd9bcc9d5846...

vog 9y ago
Thanks for the link, but why isn't it part of the article?
- anirudhmurali 9y ago
  It is, but as in image form. I'll link this there.

azr79 9y ago

What can ReasonML do that TypeScript can't?

tango12 9y ago
Prevent null bugs. Typescript values can be null. A pure reason program will never have null bugs. https://reasonml.github.io/docs/en/type.html https://reasonml.github.io/docs/en/type.html
- billwashere 9y ago
  In case anyone didn't know, since Typescript 2 there is a compiler option to enable strict null checking. https://blog.mariusschulz.com/2016/09/27/typescript-2-0-non-nullable-types https://blog.mariusschulz.com/2016/09/27/typescript-2-0-non-...
  - realharo 9y ago
    Only since 2.7 (very recently) can you actually enforce initialization of class properties: https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-7.html#strict-class-initialization https://www.typescriptlang.org/docs/handbook/release-notes/t...
    - Rapzid 9y ago
      I was just wondering about this today; thx for the link! Not sure how I missed it.
      - realharo 9y ago
        Unfortunately, libraries such as React have their own component lifecycle management, which doesn't play well with this (https://reactjs.org/blog/2015/12/18/react-components-elements-and-instances.html https://reactjs.org/blog/2015/12/18/react-components-element...). This is also a bit of a pain point on Android with Java @NonNull annotations or when using Kotlin.
        Rapzid 9y ago
        Yeah... It would honestly be cool to have a TypeScript native React(as crazy as that sounds). There are some really great projects out there killing it like Nest, MobX, TypeORM, etc.. The React typings have come a long way though. I do quite a bit of TypeScript for the server though(less context switching and is mostly GoodEnough™) so still handy.
        9y ago
napa15 9y ago
compile quickly
fleetfox 9y ago
If you look at language itself many things. It's different paradigm.
TuringTest 9y ago
Pattern matching with a sane syntax. https://reasonml.github.io/docs/en/pattern-matching.html https://reasonml.github.io/docs/en/pattern-matching.html
andreypopp 9y ago
Full type inference, pattern matching with exhaustivity checker, modules, abstract types, ... But to be honest, it's not very useful to do checklist-style comparisons — writing OCaml/Reason code is a completely different experience. For me it results in less worry about how my code would sustain under refactorings — this is one of the reasons I feel more productive with it rather than with TypeScript or Flow or (of course!) plain JS. I can start writing code and don't worry about getting everything right upfront — refactorings are cheap.
jordwalke 9y ago
Hi, I work on Reason: To add to other comments: One thing that ReasonML can do that TypeScript cannot do, is take advantage of the world-class OCaml compiler to generate very fast native executables. If you learn Reason, then you are also a "native developer" in a sense.
bobbby 9y ago
TypeScript has to handle every JavaScript quirk, it puts structure in place to help mitigate many issues. ReasonML breaks from full compatibility, it can pick and choose JavaScript features to compromise between familiarity and functionality. At the other extreme you have Elm, which has a similar background but won't compromise so can offer a clean break from JavaScript.
- cies 9y ago
  > ReasonML breaks from full compatibility It promises zero compatibility code wise, but very easy interop (FFI) with JS land!
gladimdim 9y ago
I have replied to this question on SO [1], here is quote: In a large application you will need a lot of features, which are provided by default in ReasonML: strict types, runtime validation if you encode/decode JSON, fast compilation time, immutable data. In TypeScript you will have to add: 1. ImmutableJS + its typings. 2. Runtime validators like json-schema + its typings. Then you will have to write types in TypeScript, and also defined a schema in json-schemas. They can become out of sync very soon. 3. Some crazy hacks to tell the difference if variable is of specific type (like in official docs of TS: https://www.typescriptlang.org/docs/handbook/advanced-types.html https://www.typescriptlang.org/docs/handbook/advanced-types...., Paragraph "User-Defined Type Guards"). This checks are done using side effects like a.swim !== undefined. In 6 months this 'if' statement will contain more and more checks. 4. You are lucky if a package you use has official and maintained type definitions. Or you will end up with custom typings. 5. If you develop hybrid app in JS + TS, then TS Compiler cannot create a bundled final d.ts file which you can import in other parts of your project. You will have to write separate d.ts files, which are bundled by tools like dts-bundle. If you have everything in TS, then this issue is not applicable. 6. Large apps take a lot of time to be compiled by TypeScript. With ReasonML: 1. Immutable data is in the language. 2. Runtime validators are present (bs-json has them by default). 3. Pattern matching saves you from these crazy checks. 4. You are lucky if npm package you want to use has BuckleScript bindings. 5. N/A. 6. ReasonML compilation is very fast. 1: https://stackoverflow.com/questions/46147250/reasonml-vs-typescript/47944310#47944310 https://stackoverflow.com/questions/46147250/reasonml-vs-typ...
dsiegel2275 9y ago
In my opinion one of the most useful features is first-class support for algebraic data types. Using records and variants ('sum' and 'product' types) in Reason one can be much more expressive in terms of how program state and other constraints are defined. One can get some of the same benefits of sum types in TypeScript using discriminated unions - but the syntax is cumbersome and requires boilerplate as compared to Reason.

Kwastie 9y ago

With pure Reason (No JS bindings) it should be possible to skip Node / Bucklescript on the server and compile straight to binary. This should be possible with something like bsb-native (https://github.com/bsansouci/bsb-native https://github.com/bsansouci/bsb-native) I haven't tried this because I don't have a pure Reason project

Drup 9y ago
> This should be possible with something like bsb-native (https://github.com/bsansouci/bsb-native https://github.com/bsansouci/bsb-native) Why not just use the real OCaml/Reason compiler ... ?
- jordwalke 9y ago
  Reason is supported on every major version of the native OCaml compiler (currently versions 4.02.3 up to 4.06).
  - Drup 9y ago
    I know, hence my question! Why go through bs (which is locked to an old version of OCaml) to distribute executables, when you can use the normal compiler and enjoy the latest improvements?
    - jordwalke 9y ago
      I don’t mean to ignore your observation - it is valid. Bsb is a build system that works with a specific form of packages. What you suggest could work too. The only (small?) challenge is that people have bsb JS projects, and they aren’t configured for jbuilder/Dune etc. Because of JavaScript’s immense popularity, the largest number of people will start with whatever build tools integrate well with the JavaScript ecosystem and work from there. This plays out quite predictably. Just as an example, the most important thing to web developers is that each Reason input file becomes a commonJS (or es6) module. That allows integrating your Reason React app with existing web apps easily. So since people start with whatever tools integrate well with the JS ecosystem, they then reach for the easiest tool available to adopt native compilation.

jmcomets 9y ago

Unrelated, but does anyone know what font/colorscheme are used in the screenshots? I find it very slick for code presentation.

anirudhmurali 9y ago
Haha, it's here: https://carbon.now.sh/ https://carbon.now.sh/

theptip 9y ago

One annoying thing you'll need to add before this is production-ready is configurable environment config, so that you can deploy the same container for your staging vs. production version of the app. I use a `patch.sh` as the ENTRYPOINT, which says something like echo $API_URL >> /usr/local/nginx/html/config.js echo $OTHER_CONFIG > /usr/local/nginx/html/config.js ... exec nginx Though there may be other ways to achieve this as well.