Joining in on the LiveView hype-train! 
4 Likes
Yes, for the front-end. There are two OCaml projects for the front-end, jsoo (javascript-of-ocaml) is a new ocaml backend plugin for the ocaml compiler that outputs javascript instead of machine code, itâs very low level and ugly but fast and it can compile projects that are not open source. The other is bucklescript (or whatever itâs called now) which is an ocaml compiler plugin in the middle of the compilation process (where types still exist and many optimizations are not done yet) so it output javascript code that looks a whole whole lot like the source ocaml code (makes debugging much nicer if you ever need to) and has a lot of built-in PPXâs to make web work nice.
In addition there are other front-end languages (ocaml is a very pluggable compiler) that you can use on either of those as well, like ReasonML, which is basically OCaml with a javascript-ish syntax (but itâs still fully typed ocaml, itâs fluff but nice for JS users).
Bucklescriptâs (and ReasonMLâs by default) ecosystems are built on npm, tons of libraries. jsoo is built on the normal OCaml ecosystem, less easy to bind with existing javascript libraries but it has the full power of ocaml at its disposal. Both have web pages where you can play around with them. ^.^
Liveview is nice, but it wasnât the first by far. Even just in the erlang world nitrogen/n2o was the first of that style, but it existed in other languages long before, like the oldest I can think of is the Wt web framework for C++ that does the same from the late 90âs. It wasnât even in the first in Elixir, that would probably be Drab if you donât count erlang libaries like nitrogen/n2o, lol.
3 Likes
Mint is pretty cool.
3 Likes
Adding to those already mentioned by others above, Kotlin Multiplatform Mobile.
2 Likes
Rust certainly sounds interesting
2 Likes
Elixir Phoenix, especially with LiveView. Doing project in this was super fun.
2 Likes
Basically simple management-like webapp that would require writing some JS, but I tried LiveView and it could do all the feature like real-time search, filters, auto updating dropdowns in forms etc.
3 Likes
yes LiveView. im waiting for them to add tailwind option --tailwind or another flexible option based on this PR
5 Likes
I am trying svelte and sapper.
It is an amazing idea how to build frontend in a more traditional fashion.
2 Likes
Could you post more about your experience please Adam - I for one would be very curious in how you get on 
1 Like
@OvermindDL1 What are OCamlâs PPX thingies? Like the Lisp DSLs you can write by using metaprogramming, or are they something that converts OCaml to something else (so the other way around)?
2 Likes
@dimitarvp OCamlâs compiler is âpluggableâ, in short:
- PP - Preprocessor, like this is what ReasonML is, it just takes input source, converts it to OCaml, then feeds it to the rest of the compiler. OCaml has a surprising number of PPâs.
- PPX - These plug âinâ to some or multiple of the middle stages of the compiler. They work on the AST of that stage of the compiler (which does mean you have to update on new compiler versions, however thereâs a library that abstracts that out so you work transparently on basically all versions of whatever minimum feature set you want). Depending on the stage(s) you hook in to the AST have varying levels of information, like higher stages are typed and contains attributes that you can work on, lower stages tend to be less (or none in the case of right before sending to the backend, itâs all integers at that level, basically assembly in AST form) typed but you can put in interesting optimization things then.
- Backend - This is what consumes âsomeâ of the above-mentioned stages to output a final object. The mainline OCaml compiler comes with two, a super easy to debug bytecode compiler that is run via the OCaml bytecode interpreter, and a native code compiler that outputs native code with nothing else needed (fastest optimizing compiler out!), both of those consume the last AST stage.
json_of_ocamlis another backend that consumes the last AST stage and output very machiney-looking unreadable but fast javascript. Bucklescript or whatever itâs called now hooks a more middle AST level to generate javascript that looks like the source OCaml but type safe (thus it relies on the javascript JIT a whole lot more, but that works well anyway). And there are others, like there is an OCaml backend that hooks somewhere in the middle to output BEAM/Erlang code!
Rustâs proc-macroâs are like OCamlâs PPXâs (except less powerful as they hook the very very early tokenstream instead of multiple possible AST tiers).
EDIT: But there are a lot of PPXâs in existence that add all kinds of really cool and interesting features (like proc-macroâs for Rust), everything from erlang-style bitstream handling to elixir-like compile-time source macroâs to rust-serde-like serialization/deserialization engines and more, itâs really cool.
3 Likes
I like it too! With Erlang I feel good.
Am I tired of endless additions to Java, there are even claims to Rust - in my opinion, if there were fewer language constructions there, it would be better for the language.
3 Likes
I agree Rust can be verbose and it definitely gives me PTSD flashbacks to Java sometimes â but the compiler and all dev tooling are the best Iâve ever seen in my life and that alone makes developing in the rather clunky syntax and puzzling mechanics like partial moves, circular borrowing and polymorphic trait return values much more tolerable.
I miss working with Rust every day. I love Elixir to tears but its dev tooling is sadly very behind. But then again, almost every language out there is very behind Rustâs dev tooling.
3 Likes
I think things like async were rushed a little bit, but overall the vast majority of features in the language are rather necessary. The few that arenât necessary, such as ?, have such an overwhelmingly nice usability thing that itâs worth having them, however I donât actually think thatâs the case for ? as Rust has an RFC to get postfix macroâs in, which would have made it so ? could just have just been a postfix macro instead of a language construct.
However, Rustâs syntax can change, unlike almost every other language, on itâs every-3-year version scheme. Since you can link mismatched syntax files without issue it allows for a very easy upgrade path as the language may add, or indeed even remove, syntax features. 
2 Likes
Sadly their 2021 edition seems extremely underwhelming. Zero risks, zero tries to reduce verbosiveness, zero tries to bring other constructs natively. 
2 Likes
Yeah I had the same thought⊠Maybe just a pandemic lull is what Iâm hoping.
EDIT: Then again maybe it means the syntax is pretty âfinishedâ too? Which is a good target.
1 Like
If itâs finished then ouch. Rustâs syntax leaves a lot to be desired. I mean OK, once you figure it out it does make sense â I mean stuff like the where T: Trait1+Trait2+Trait3 and the lifetime annotations â but itâs still a fairly high barrier to entry.
Sigh. I guess when I put my life in order (pretty soon now, I hope; it has been a tough battle for 1-2 years but things are finally falling in place lately) and have some free time and here and there Iâll just start learning both Rust and OCaml intensely because I definitely like OCamlâs syntax more. I want to get to a strong mid level with them (I am not keen on getting to the advanced levels yet though).
3 Likes
⊠that stuff was always clear to me⊠^.^;
But then again I know haskell and a good bit of idris, and this looks tame in comparison, lol.
But still, itâs very succinct and gives a lot of information for what is typed, it would be hard to do it better.
Like in OCaml, the equivalent to Rust impl traits would be OCamlâs higher typed modules, which are a whooooole lot more verbose in comparison, to a huge degree at times. Rust is actually very clear and simple here, it learned a lot from the predecessor languages.
3 Likes