At crossroads while starting to learn modern web UI development

#1

I am a veteran backend developer. I’ve spent most of my time during the past decade working on Erlang and Elixir projects.

Recently (for the past 3 months) I’ve been learning OCaml and now I feel quite comfortable with it, to the point where it’s my new favourite language.

I’m working on a project which will be a mix of:

  1. OCaml native at the backend for doing the heavy lifting of the business logic. I’m quite “ready” with this part, or at least at the stage where it’s usable and ready to start integration with the other parts.
  2. Erlang/Elixir as orchestration and middleware layer. Mostly because I’m familiar with it and this way will be the easiest for me to provide things like websockets etc.
  3. Bucklescript/ReasonML on the frontend with possible sharing of some libraries using js_of_ocaml (already able to compile them and do some simple tests to check that they work in the browser).

Now I’m a bit lost on how to continue.

I “know” some JavaScript and have worked on relatively big projects ~ 10 years ago when Ext JS was big (now it’s called Sencha). Also, some years ago I played with Mithril.js and quite liked it (but since have forgotten it). But that’s it, I haven’t done “modern JavaScript” and I don’t know how to continue.

The basic tutorials and examples are quite easy for me, as I know OCaml and don’t hit the wall that I presume most of the newbies are hitting (coming from JS land). So I feel reasonably good if I have to write just “vanilla js” that does simple things.

But I have no idea what’s going on when I try to read tutorials about Reason React, as they are written with the intention to target React/JS developers and I don’t know React.

So I have some random questions, and also I’ll very much appreciate “general advise” on what to do.

  1. Do I have to learn/use React. Of course, I know that the answer is “no” as everything is possible, but still, will I have hard time if don’t use react? I have nothing against it, just want to know my options and not waste my time with other things if they are not “practical” with Reason/Bucklescript.

  2. Can I learn directly through OCaml/Reason or will I have to read a lot about JavaScript? Of course, I can understand JavaScript syntax, but obviously, I feel a lot better in the OCaml type system. In general, can you recommend resources to read in my situation?

  3. By reading comparisons of JS frameworks, I quite like EmberJS, so how hard would it be to use it and what tradeoffs do I make if I go that route?

  4. What do I lose if I decide to use the OCaml syntax?

#2
  1. It’s definitely possible to not use React. I’m planning to go that route soon using no frameworks with bs-webapi but binding to other JS frameworks should be easy.
  2. Really depends on your choice of tech. It should be possible to not need to understand JS in detail though.
  3. Do you mean using ember from bucklescript or replacing it with a pure JS frontend? I’m not sure how to answer this question yet.
  4. Not much. Reason is, quite literally, just a syntax transform.

Have you looked at a full stack OCaml option? Ocsigen has a comprehensive framework called Eliom that lets you build both backend and frontend in a single codebase, which is really nice to share data structures (frontend is compiled automatically using js_of_ocaml). It would however mean side-stepping the ReasonML/Bucklescript community, as nobody here uses it. There should be plenty of support from the OCaml community though.

#3

Yes, I mean using ember from bucklescript

I’ve been part of the OCaml community for the past months and nobody really talks about it. Maybe I should just ask, but this option seems really unpopular.

#4

I’m also a backend dev focused on Elixir/Phoenix/Ecto and a relative newbie to JS… I went through this same thought pattern a few months ago so here’s my thoughts:

  1. I’d say you don’t have to learn/use React but I found that to be the easiest path. ReasonReact is the most “supported” path with the most code examples for common patterns you’ll find in blog posts and Github. The official React guides are excellent and with the functional experience from Elixir already in place it didn’t take a long time to grok… Finally of course the ReactJS ecosystem is HUGE and you can fairly easily write ReasonReact wrappers around ReactJS components if you like. Another option is Bucklescript-TEA if you like the Elmish pattern.
  2. I learned directly through ReasonML ignoring JS as much as possible but if you need to write new bindings to JS libraries (externals) you’ll need some good JS skills. I’m not writing bindings so I’ve been able to get away with minimal JS study.
  3. I wanted to use Vue.js with ReasonML initially, since I had experience with it already. There are some incomplete/out-of-date bindings for Vue… but quickly came to the realization that was “going against the grain” too much. I wasn’t skilled enough to “go it alone” updating the bindings so just decided to go with the flow and learn ReactJS then ReasonReact. Now I really like React as it feels more “functional” and Vue just feels too “mutable” to me at this point. I think with EmberJS you will run into the exact same thing as I did… I am not aware of anyone using ReasonML with EmberJS so you would be going it alone and writing a lot of bindings.
  4. As spyder said, it’s just a syntax transform so I think you can use whatever you like.

Just because I’m curious and not being critical at all… why did you want to put the “heavy lifting” backend in OCaml calling it as ports instead of writing the whole backend in Elixir? Did you need more raw single-threaded performance? Prefer the awesome type inference of OCaml to the dynamic nature of Elixir? For my app, I found Elixir to be very fast (compared to something like Ruby) and easy to spawn concurrency when needed to use all my cores efficiently… which was more than enough. Of course it will work great as an orchestration/middleware layer if that’s what you want… just curious.

#5

Yes, and yes. OCaml is now my favourite language by a long shot. Although I have a very extensive Erlang/Elixir experience, I am amazed by the OCaml experience. Of course I can’t deny that BEAM is (much) better than anything in existence for writing messaging, orchestration and concurrent servers in general.

But for “general purpose” programming, OCaml shines too brightly for me to be able to not write in it when I can afford it.

Also, I need quite a lot of raw performance. My software will do lots of text parsing, indexing, searching, math etc. and something like Elixir will probably be too slow for it.

#6

Yep, makes total sense in apps with those requirements. I’m doing ETL and Elixir’s text processing speed is more than sufficient plus needing the awesome Ecto database library extensively to reach out to PgSQL. But if I needed hardcore number crunching would probably reach out to a cmd, port, or NIF. I think you can write NIFs in OCaml but it’s not as common as C, C++, or Rust to do so. Seems like it would be safe though with less risk of crashing the BEAM than C/C++.

Best of luck with your app!

#7

The project doesn’t seem to be stagnant, so someone uses it :sweat_smile: Maybe if you ask around you’ll find where the users hang out and get help with questions :thinking: