Best to ask @grych 
As you can see from the thread though, he’s been working very hard on it and I can’t imagine it being far off stable 
2 Likes
cough Posts about overbots | Hyperglot Programmer
That is using my Bucklescript-Tea library, which brings the Elm-style programming to Bucklescript (which I quite like), most of the code is directly translatable from the equivalent elm code too, just copy it over and add a few lets and order the functions better and such.
Bucklescript also has bindings to React and a dozen other things already too.
In addition if you don’t like the ocaml’y/elm’y syntax, there is ReasonML, which is a text preprocessor on top of OCaml (and thus Bucklescript) that has a more javascript’y feel, but it otherwise the same code and style, and it is included in Bucklescript so you just .re files and it should ‘just work’ as I know (I’ve not tested it, I like OCaml’s syntax).
Biggest things, it is type safe, like elm, it is immutable, like elm, it has a significantly powerful type system, unlike elm (elm lacks a LOT of type abilities, it may get them later, but it lacks them now, I was unable to represent certain things in Elm when I used it, which is when I started looking at purescript and came across bucklescript instead), etc… These all catch huge classes of bugs so they just categorically cannot happen, the only real bugs you will have left are just flipped comparison signs or putting a 1 instead of a 2 or things like that, and even those can be caught if you type things more. ^.^
Well my Bucklescript-Tea project emulates TEA’s interface for JSON, however Bucklescript has a built in way that is a lot more simple (though less ‘descriptable’) and there are OCaml libraries that can automagically generate encoding and decoding functions for effecitvely free by just annotating it after bringing in the library and ppx (which can be ‘interesting’ to bring in, but once brought in you never have to think about it again) so you could use it like:
type model = {
a : int;
b : blahSpecialType;
c : bringInMoreTypes;
} [@@deriving yojson]
Which would generate functions like:
var yojson_of_model : model -> yojson
var model_of_yojson : yojson -> model
PPX’s in OCAML are like macro’s in elixir, it is best to avoid them if you can, but they are there and are wonderful if you really really need them.
I actually quite like the Elm’y JSON declarative way though, but OCaml/Bucklescript has options, unlike Elm. ^.^
/me should probably move these last 2 posts back to bucklescript… >.> Maybe we should make a ‘comparison’ thread?
1 Like
I’m using it, so… If he does not continue it, I would. Drab is a great idea. ^.^
2 Likes
Would be great to see you get on the core team for it 
Then you could both write a book on using it with Phoenix in interesting, weird and wonderful ways
2 Likes
I am going to mention you in my Testament then!
1 Like
I think more than comparison your idea to give examples its better, hope one day do a full SPA example with Phoenix can be amazing, I think I need know more about OCaml to understand completly the concept of Bucklescript ^^
Well with using bucklescript-tea you can make comparison projects between elm and ocaml ‘almost’ word-for-word identical, so it is easy to make such comparisons. The speed should be on par with each other for the vdom, though bucklescript’s processing should be a lot faster (elm uses a LOT of thunks) but that is not an issue unless you are processing audio waveforms or something. Elm was designed off of both OCaml and Haskell and the author states that still on occasion, usually comparing the typing to OCaml features (a recent example from this morning is his comparing Elm’s and OCaml’s recursive values at Recursive values in Elm · GitHub where Elm’s has a tendency to crash at runtime and he’s trying to fix it, potentially by copying how OCaml does it as one possibility), but Elm is only a strict subset of OCaml. Everything Elm’s type system can do OCaml can do, however OCaml can represent a LOT more types than Elm (or Haskell, or SML, or many others, OCaml has one of the strongest typing systems in the world). I am still trying to push Elm forward though, it is an interesting introduction into the functional world.
1 Like
Well after you show me all the disadvantages from Elm (in certain way), I just keep waiting for more examples of Bucklescript, my project in mind I will use a spa solution, so I keep waiting for it :D, actually lack a lot of documentation/examples (just thoughts)
Plenty of documentation on bucklescript, look at the entire huge OCaml programming tutorials online, the books released, and tons and tons more. For Bucklescript specific (which is just a build system) look at its manual page, not much else needs to be known about it. For my specific bucklescript-tea library, well, I’m making examples (I linked my blog before as one) and as for documentation I accept PR’s, but otherwise the docs are the same as elm’s, I copied its API almost precisely. ^.^
Is there a benchmark for it? JS from bucklescript runs faster than that from Elm. If there is, show me the code.
Some of my colleagues use yarn instead of npm, because they think npm is …
I think ports are quite straightforward.[quote=“OvermindDL1, post:98, topic:140”]
It has a significant existing ecosystem of type-safe, fast, well optimized OCaml code,
[/quote]
Why do you think it helps a lot for a frontend framework/language to have a strong backend support? What do you think of ElixirScript?
Remark
I am into Elixir/Erlang for its concurrency and OTP, Haskell for its simplicity and purity, Elm for Haskell and TEA. The reason for Ocaml is just not sufficient: “OCaml is an industrial strength programming language supporting functional, imperative and object-oriented styles”, for its ecosystem? what about java and c#, for its versatility? what about c++? for its industrial strength? what about “let it crash” in erlang or rust? for fun? what about scratch, processing or haskell?
Compiling faster to faster code is not a reason for me and most people I know to learn a new language, simply because we are not working on such a demanding task except for those doing scientific experiments where a 0.1% improvement may be a breakthrough.
If not Ocaml, why Bucklescript?
Mmm, I had one when I first started messing with it but not seeing it on my website, think my bucklescript testing area overwrote it. I could remake it. The main issue is that Elm does not have a lot of optimization passes that the ocaml compiler has so it was just not doing a lot of simple folding and inlining and such.
Cool, well yarn uses NPM so that is already set.
As do I, but they do not represent certain callback style things. I think the current style of ports, whether in or out but not both is quite wrong, if ports were just an exposed elm Task (as many many people are pushing for) then it would handle all the cases with ease.
Existing packages can greatly save time, especially if they are well tested and type safe. Elm could grow to that in time but OCaml has a 30 year head start on it with libraries for about anything. You can use an library that does not use native code in your javascript project, and even the ones with native code (a relatively small amount) Bucklescript has a system to allow you to put in your own ‘native code’ instead.
So by great tooling support it is indeed significantly better. Better libraries, better tools, larger and well tested ecosystem, etc…
They all have different purposes indeed. The BEAM/Elixir/Erlang/lfe/etc is fantastic for robustness across many servers and vast scaling. It, however, sucks for, say, parsing, or text munging, even something like Python blows away the BEAM in most text processing. Use the right language for the right task. ^.^
Haskell I’d call anything but simple, it has so many extensions and work-arounds due to limitations in its type system, in addition to taking as long or longer than C++ to compile for anything of significant size, HKT or typeclass usage, and etc, that it makes it hard to be productive in it.
C++ is a bit more… verbose in its implementations, there are some front-end libraries for it including you can compile it to javascript straight via emscripten (and now webassembly whoo!), but the compiled code is basically a blob of low level assembly, hard to introspect. In addition C++'s design still has what I consider the huge problem of allowing null’s in any pointer. I do however quite enjoy C++, but even now I’d say that Rust does better than C++ in most tasks C++ is used for now (not quite ‘all’ yet, but getting close).
As for Java and C#, they compile to even worse javascript than C++ does via emscripten (worse as in slower, larger, although ‘slightly’ more readable, but not by much).
Scratch, eh, it would be hard to get a lot of the work I do to get done in it, ditto with processing, and for Haskell the turn-around times would be fairly huge enough that my productivity would be shot.
OCaml I would not even choose if it compiled to fairly unreadable code, like jsoo does with ocaml->javascript or even compiling ocaml to webassembly, I’d rather use something like typescript. However bucklescript I choose because the output is readable, so I know how it will interact with everything else, it is easily debuggable in the browser (important because I tend to do a lot of math at work), it compiles fast so I’m not sitting around twiddling my thumbs waiting for a file to compile before I can test it (there is a plugin that can even hot reload individual modules so you do not even need to reload a whole page), and it is a safe language that is fully expressive (an example is it can represent anything that Haskell can, just as safe as Haskell can, and can represent ‘more’ than Haskell can, while still remaining as safe, and is significantly faster to compile).
Oh absolutely not, I whole-heartedly agree. I try to learn near about every language that I come across, even if they are slow compiling. However when I am trying to get Real Work done, stuff I get paid for, I want languages that bring my productivity to the max, that includes having a great runtime, is small enough for deployment, is fast enough to never need to worry about causing issues, will not be questioned by the bosses, has a great type system that catches 90% of the bugs that I’d make otherwise (looking at elixir lacking this…), etc… OCaml is thus to me a much better front-end language thanks to the tool support it now has (Bucklescript is a much better backend plugin for me than JSOO is) and my productivity has seen a corresponding boost as well. Combined with that I can write OCaml programs that run on the server via a BEAM Port I can write some of the same code on both sides with ease, without installing extra runtimes on the server (no node).
So yes, I entirely agree that Compiling faster to faster code is not a reason for me and most people I know to learn a new language and I entirely encourage someone to learn elm, it has a fantastic style to it if you can put up with its limitations! Just for getting real work done I want what I can be most productive in, and spending two days writing ports just to interact with some javascript library that I have no choice in compared to spending 5 minutes writing properly typed externals in OCaml is a huge difference when I am getting paid to “Get Stuff Done Now”.
Huh? What are you talking about? OCaml is the language, Bucklescript is a plugin for the compiler. Just like JSOO. The OCaml compiler is fully pluggable, you can make PP plugins to make new languages that use the OCaml compiler, or you can make PPX plugins that can transform AST to AST anywhere in the pipeline. Bucklescript is just a plugin (well a bit more technically, but it is this regardless) that takes the AST and writes out javascript and stops the pipeline. JSOO is a PPX (older form of it technically) that takes much lower level AST and writes out much lower level unreadable javascript. There are ones that can output OCaml to webassembly. There are ones that can output OCaml to the Android NDK. Etc… etc… Bucklescript is just ‘yet another’ plugin for the OCaml compiler, so I’m not sure what you are asking with this question?
2 Likes
2 Likes
[quote]
People often ask me if I can point them to an open-source Elm Single Page Application so they can peruse its code.
Ilias van Peer linked me to the Realworld project, which seemed perfect for this. They provide a back-end API, static markup, styles, and a spec, and you build a SPA front-end for it using your technology of choice.
Here’s the result. I had a ton of fun building it!
4,000 lines of delicious Elm single page application goodness 
Fair warning: This is not a gentle introduction to Elm. I built this to be something I’d like to maintain, and did not hold back. This is how I’d build this application with the full power of Elm at my fingertips.[/quote]
1 Like
Frontend Masters has a course on Elm by Richard Feldman. It looks pretty good so far. I wasn’t sure how I would like a recorded live session but it’s not bad at all. Beats waiting for Richard’s book from Manning. The book looks to be taking some time.
and he has a recorded workshop there as well:
1 Like
Why do some of the Elm advocats, even though they are Elm advocats say something like “you can replace some of your JS code with Elm” instead of recommending a 100 per cent Elm approach?
Or is this just to say you shouldn’t replace all of your existing project’s JS code with Elm to not be overwhelmed with rewriting code, and then it’s fine to go 100 per cent Elm on a new project?
I think it’s about gradually migrating existing stuff, as you already said, this makes changing much easier.
1 Like
Another issue might be that is takes time to adopt the Elm mindset, immutability, and TEA interactivity model if you are coming from a (primarily) JavaScript background.
Trying to do an entire full-featured application may become an unending stream of “how do I do this or that in Elm” challenges - possibly creating a sense of being “too much of a bother to stick with it”. Ideally you would also want to delay the issue of JavaScript interop until you have a solid grasp of the role that commands and subscriptions play in TEA (as well as encoders and decoders). So the “first venture” should not only be a relatively small part but also as independent as possible.
3 Likes
There is a lot of truth to this. I’m in the process of launching my first production app in Elm, and…well…the struggle is real 
What helped me get through it was 1) zealot-like faith in ML languages, and 2) the experience of refactoring a pile of hastily cobbled-together garbage into tight, readable, elegant, fast production code…in a way that can’t be done in imperative languages. Once you experience that, the pain becomes much more bearable.
So basically you don’t really “get” Elm until you’ve written ~5,000 lines of code, which is a high barrier to entry compared with the instant gratification that imperative code gives you. I try my best to convince my fellow developers of this, but for the immediate future, I think this will be a language for the adventurous
2 Likes
Sadly, though, Elm is not an ML style language, it is a hindley-milner language, more similar to Haskell than an ML style language. ^.^;
Indeed! This is all what languages with fantastic typing systems are all about! ^.^
2 Likes
