For smaller foot print it is good to have something with dead code elimination. (Clojurescript is king here) But I see that Elm is working on that …
https://github.com/elm-lang/elm-make/issues/85
1 Like
This thread started a little while ago and Bucklescript is under active development.
I don’t know what the current status is but playing with something a little larger than Hello world gave me quite a large JS bundle. AFAIK Bucklescript is really focused on performance so I would definitely try the latest release.
Also checkout @OvermindDL1’s code on Github and other posts about the subject in this thread…
1 Like
That’s great if it comes true. I got to say if there no need to play with Javascript Elm is still a very nice choice.
1 Like
Thanks for your recommendation. It’s been very helpful.
Bucklescript has no runtime, it does have a standard library but you are free to not use it if you want (and indeed it will not be included in the output if not used).
Bucklescript not only already does dead-code-elimination but also automatic inlining, closure optimizing and removal, etc… 
Bucklescript just uses the OCaml compiler, which has huge amounts of optimizations, hence why the code comes out so well, it has decades behind it, unlike elm and purescript and even clojurescript. ^.^
1 Like
I’m trying to port my Elm code to Bucklescript with your TEA. It’s amazing! As you said the OCaml compiler is so well optimized and the speed is breath taking! While using Elm it made me want to cry when it took so long to get compiled and Phoenix auto load more than once and I don’t really know if the version in my browser is the right one. But TEA itself is such a great architecture. Huge thanks for your work! Hope one day I will be able to write a PR for you.
Yeah I have a few projects in elm at work, well over 40s to compile, on every-little-change. Rewrote the big part in bucklescript a few weeks ago and compile time for it is <1s. ^.^
Do note, the code in my project is good but the build system I built was before bucklescripts awesome bsb existed, so do use bsb instead and just copy my code over. I’m planning a big code release of my OAK-TEA stuff soon as a standalone library to include once I finish overhauling some code. 
2 Likes
Looking forward to this immensely.
2 Likes
Thanks for telling me this. I should put your project in a sub directory of lib right?
Where are you going to release it? As far as I know there no package manager for Bucklescript or you are going to publish it on opam?
For now you can just grab the source files that you want to use from my bucklescript-testing repo and put it in your src directory like it is your own file.
Eh, ‘when it is finished’, work has me focusing on other things at the moment, but I’m hoping not too long.
And yes, Bucklescript has a package manager, it is baked into NPM and Bucklescript is not only fully NPM aware but it requires NPM as NPM ‘is’ its package manager, so installing my library once done will just be a normal npm install blah call.
I just found OCaml are under GPL with a special exception
“As a special exception to the GNU Library General Public License, you may link, statically or dynamically, a “work that uses the Library” with a publicly distributed version of the Library to produce an executable file containing portions of the Library, and distribute that executable file under terms of your choice, without any of the additional requirements listed in clause 6 of the GNU Library General Public License. By “a publicly distributed version of the Library”, we mean either the unmodified Library as distributed by Inria, or a modified version of the Library that is distributed under the conditions defined in clause 2 of the GNU Library General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU Library General Public License.”
Does it mean it’s totally OK to code with it and distribute/sell it without the disclose of my code as long as I don’t modify OCaml’s components?
That is only if you are using the OCaml runtime (which you do not with bucklescript anyway), but yes.
However, if you edit the OCaml runtime, those changes must be distributed if any release is made.
And pulled out my TEA api code into its own repo: https://github.com/OvermindDL1/bucklescript-tea
^.^
2 Likes
And posted my first introduction post for Bucklescript: http://blog.overminddl1.com/posts/why-use-bucklescript/
5 Likes
Nice blog post ODL1 
I much prefer
let add l r = l + r
to
function add(l, r) {
return l + r | 0;
}
1 Like
Hehe, hear hear. ^.^
Also, just cleaned up and posted the next article too: Setting up Bucklescript with Phoenix | Hyperglot Programmer
4 Likes
Loving this - you might want to update the heading ‘Adding Elm to Phoenix via brunch’ and the link to the elm doco. Unless you do need to install elm for bucklescript?
2 Likes
Nice
If you do a zero to hero tutorial on Bucklescript I may even give it a shot
3 Likes
*cough*, fixed. ^.^
I plan more things, next article will be on bucklescript-tea once Bucklescript does its new release (probably next week) since that will add remote bsb library support (which is what my library is). ^.^
3 Likes
I’m really enjoying your blog combined with Permanent Redirect (it’s right at my level I think).
I noticed that all of the javascript code uses var, whereas I am personally using let because of my scoping intuitions (I’ve only been doing javascript seriously for a little over a year now and love ES6). In this issue, they mention that they are handling the scoping well. Have you noticed any issues on any non-trivial code? There is also this other issue that mentions let and scoping as well in failing code. It’s a minor thing, but I’m still wanting to slowly start switching over to Bucklescript/TEA, since the more I see OCaml, the more I like the OO-ish Modules + Functional combination (much like I 
the BEAM(!)'s architecture on the backend with processes + functions).
1 Like
